Efficient bad block management for raw NAND-based non-volatile memory (NVM) devices

Abstract

A method for efficient bad block management of a raw negative AND (NAND) -based non-volatile memory (NVM) device is described. The method includes booting a system including the raw NAND-based NVM device. The method also includes transmitting a request, by a driver of the raw NAND-based NVM device, for a bad block table stored in a reserved block of the raw NAND-based NVM device. The method further includes directing, by a memory controller, the request for the bad block table to the raw NAND-based NVM device. The method also includes providing, by the raw NAND-based NVM device, the bad block table. Each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block.

Description

EFFICIENT BAD BLOCK MANAGEMENT FOR RAW NAND-BASED NON-VOLATILE MEMORY (NVM) DEVICESBACKGROUNDField

[0001] Aspects of the present disclosure relate to system bootup and, in particular, to a system and method for efficient bad block management for raw negative AND (NAND) -based non-volatile memory (NVM) devices. Background

[0002] Vehicle or automotive control systems may be subject to more stringent electrical operational requirements. This is because errors in such vehicle or automotive control systems may result in severe injury or death to humans occupying associated vehicles, as well as humans, animals, and property that may collide with such vehicles. Such stringent electrical operational requirements may address system redundancy, greater resistance to electrical and software faults, and improved monitoring of such systems, to name a few issues. This emphasis on stringent electrical operational specifications aligns with the automotive industry’s commitment to safety and reliability.

[0003] In modern automotive chipsets, an amount of time consumed during a bootup process (e.g., “boot time” ) is of importance. A boot time may refer to an amount of time for a device to become operable for running applications after a power ON trigger. In particular, the amount of time consumed during the bootup process is a key performance indicator (KPI) of these automotive chipsets. As a result, achieving a fast boot time for automotive chipsets has become a factor that directly impacts the ability to initiate early feature initializations. During bootup, a loader (e.g., file system / kernel / boot loader) identifies any bad blocks in a raw NAND-based non-volatile memory device. Unfortunately, the significant number of raw NAND page read commands performed for identifying whether a block is bad has a significant impact on boot KPIs. An efficient bad block management solution for raw NAND-based non-volatile memory (NVM) devices is desired.SUMMARY

[0004] A method for efficient bad block management of a raw negative AND (NAND) -based non-volatile memory (NVM) device is described. The method includes booting a system including the raw NAND-based NVM device. The method also includes transmitting a request, by a driver of the raw NAND-based NVM device, for a bad block table stored in a reserved block of the raw NAND-based NVM device. The method further includes directing, by a memory controller, the request for the bad block table to the raw NAND-based NVM device. The method also includes providing, by the raw NAND-based NVM device, the bad block table. Each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block.

[0005] A non-transitory computer-readable medium having program code recorded thereon for efficient bad block management of a raw negative AND (NAND) -based non-volatile memory (NVM) device is described. The program code is executed by a processor. The non-transitory computer-readable medium includes program code to boot a system including the raw NAND-based NVM device. The non-transitory computer-readable medium also includes program code to transmit a request, by a driver of the raw NAND-based NVM device, for a bad block table stored in a reserved block of the raw NAND-based NVM device. The non-transitory computer-readable medium further includes program code to direct, by a memory controller, the request for the bad block table to the raw NAND-based NVM device. The non-transitory computer-readable medium also includes program code to provide, by the raw NAND-based NVM device, the bad block table. Each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block.

[0006] This has outlined, broadly, the features and technical advantages of the present disclosure in order that the detailed description that follows may be better understood. Additional features and advantages of the present disclosure will be described below. It should be appreciated by those skilled in the art that this present disclosure may be readily utilized as a basis for modifying or designing other structures for conducting the same purposes of the present disclosure. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the teachings of the present disclosure as set forth in the appended claims. The novel features, which are believed to be characteristic of the present disclosure, both as to its organization and method of operation, together with further objects and advantages, will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] For a more complete understanding of the present disclosure, reference is now made to the following description taken in conjunction with the accompanying drawings.

[0008] FIGURE 1 illustrates an example implementation of a host system-on-chip (SoC) , which is configured for bad block management of raw negative AND (NAND) -based non-volatile memory (NVM) devices, in accordance with various aspects of the present disclosure.

[0009] FIGURE 2 illustrates an example of an automobile including systems having raw negative AND (NAND) -based non-volatile memory (NVM) devices configured for bad block management, in accordance with various aspects of the present disclosure.

[0010] FIGURE 3 is a block diagram illustrating an Automotive Safety Integrity Level (ASIL) data path having raw negative AND (NAND) -based non-volatile memory (NVM) devices configured for bad block management, in accordance with various aspects of the present disclosure.

[0011] FIGURE 4 is a block diagram illustrating good / bad block management for raw negative AND (NAND) -based non-volatile memory (NVM) , according to various aspects of the present disclosure.

[0012] FIGURES 5A and 5B are flowcharts illustrating good / bad block management for raw negative AND (NAND) -based non-volatile memory (NVM) , according to various aspects of the present disclosure.

[0013] FIGURE 6 is a process flow diagram illustrating a method for efficient bad block management of raw negative AND (NAND) -based non-volatile memory (NVM) devices, according to various aspects of the present disclosure.

[0014] FIGURE 7 is a block diagram showing an exemplary wireless communications system in which a configuration of the disclosure may be advantageously employed.

[0015] FIGURE 8 is a block diagram illustrating a design workstation used for circuit, layout, and logic design of a semiconductor component according to one configuration.DETAILED DESCRIPTION

[0016] The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. It will be apparent, however, to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0017] As described herein, the use of the term “and / or” is intended to represent an “inclusive OR, ” and the use of the term “or” is intended to represent an “exclusive OR. ” As described herein, the term “exemplary” used throughout this description means “serving as an example, instance, or illustration, ” and should not necessarily be construed as preferred or advantageous over other exemplary configurations. As described herein, the term “coupled” used throughout this description means “connected, whether directly or indirectly through intervening connections (e.g., a switch) , electrical, mechanical, or otherwise, ” and is not necessarily limited to physical connections. Additionally, the connections can be such that the objects are permanently connected or releasably connected. The connections can be through switches. As described herein, the term “proximate” used throughout this description means “adjacent, very near, next to, or close to. ” As described herein, the term “on” used throughout this description means “directly on” in some configurations, and “indirectly on”in other configurations. It will be understood that the term “layer” includes film and is not construed as indicating a vertical or horizontal thickness unless otherwise stated. As described, the term “substrate” may refer to a substrate of a diced wafer or may refer to a substrate of a wafer that is not diced.

[0018] Vehicle or automotive control systems may be subject to more stringent electrical operational requirements. This is because errors in such vehicle or automotive control systems may result in severe injury or death to humans occupying associated vehicles, as well as humans, animals, and property that may collide with such vehicles. Such stringent electrical operational requirements may address system redundancy, greater resistance to electrical and software faults, and improved monitoring of such systems, to name a few issues. This emphasis on stringent electrical operational specifications aligns with the automotive industry’s commitment to safety and reliability.

[0019] These automotive control systems may be implemented using an automotive chipset. In modern automotive chipsets, an amount of time consumed during a bootup process (e.g., “boot time” ) is of importance. In particular, the amount of time consumed during the bootup process is a key performance indicator (KPI) of these automotive chipsets. As a result, achieving a fast boot time for automotive chipsets has become a factor that directly impacts the ability to initiate early feature initializations. Unfortunately, initialization and management of non-volatile memory (NVM) devices during bootup of automotive chipsets significantly increases the boot time.

[0020] For example, during bootup, a loader (e.g., file system / kernel / boot loader) identifies any bad blocks in a raw negative AND (NAND) -based NVM device. For example, if the raw NAND-based NVM device has 4096 blocks, 4096 page read commands are issued by software (SW) . Unfortunately, the significant number of raw NAND page read commands performed for identifying whether a block is bad has a detrimental impact on the boot KPIs. Accordingly, an efficient bad block management solution for raw NAND-based NVM devices is desired.

[0021] Various aspects of the present disclosure are directed to an efficient process for managing bad blocks of raw NAND-based NVM devices. For example, a raw NAND-based NVM device can maintain spare pages in some memory blocks to maintain bad block information for all memory blocks of the raw NAND-based NVM device, which is referred to as a bad block table. According to various aspects of the present disclosure, at the host side, the host no longer maintains any bad block tables. Rather, the host is reconfigured to send commands (e.g., get / set feature commands) to read / update a bad block table. In particular, the entire operating system (OS) image is relieved of the duty from maintaining a bad block table. In some implementations, the raw NAND-based NVM devices maintain bad block information for each memory block of the respective raw NAND-based NVM device.

[0022] FIGURE 1 illustrates an example implementation of a host system-on-chip (SoC) 100, which is configured for bad block management of raw NAND-based non-volatile memory (NVM) devices, in accordance with various aspects of the present disclosure. Variables (e.g., neural signals and synaptic weights) , system parameters associated with a computational device (e.g., neural network with weights) , delays, frequency bin information, and task information may be stored in a memory block associated with a neural processing unit (NPU)  / network signal processor (NSP) 108, in a memory block associated with a CPU 102, in a memory block associated with a graphics processing unit (GPU) 104, in a memory block associated with a digital signal processor (DSP) 106, in a memory block 118, or may be distributed across multiple blocks. Instructions executed at the CPU 102 may be loaded from a program memory associated with the CPU 102 or may be loaded from a memory block 118.

[0023] The host SoC 100 includes processing blocks tailored to specific functions, such as a connectivity block 110. The connectivity block 110 may include sixth generation (6G) , connectivity fifth generation (5G) new radio (NR) connectivity, fourth generation long term evolution (4G LTE) connectivity, WI-FI connectivity, USB connectivity,  connectivity, Secure Digital (SD) connectivity, and the like, and a multimedia processor 112 that may, for example, detect and recognize gestures. In one implementation, the NPU / NSP 108 is implemented in the CPU 102, DSP 106, and / or GPU 104. The SoC 100 may also include a sensor processor 114, image signal processors (ISPs) 116, and / or navigation module 120, which may include a global positioning system.

[0024] The multi-core CPU 102, the GPU 104, the DSP 106, the NPU / NSP 108, and the multimedia processor 112 support various functions such as video, audio, graphics, gaming, artificial networks, and the like. The SoC 100 may be based on any architecture, such as a complex instruction set (CISC) architecture, an ARM, RISC-V (RISC-five) , or any reduced instruction set computing (RISC) architecture. Each processor core of the multi-core CPU 102 may be a RISC-V machine, an advanced RISC machine (ARM) , a microprocessor, or some other type of processor. The NPU / NSP 108 may be based on an ARM instruction set.

[0025] In aspects of the present disclosure, the instructions loaded into the CPU 102 may include code to boot a system including the raw NAND-based NVM device. The instructions loaded into the CPU 102 may also include code to transmit a request, by a driver of the raw NAND-based NVM device, for a bad block table stored in a reserved block of the raw NAND-based NVM device. The instructions loaded into the CPU 102 may further include code to direct, by a memory controller, the request for the bad block table to the raw NAND-based NVM device. The instructions loaded into the CPU 102 may also include code to providing, by the raw NAND-based NVM device, the bad block table. Each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block.

[0026] FIGURE 2 illustrates an example of an automobile including systems having raw NAND-based non-volatile memory (NVM) devices configured for bad block management, in accordance with various aspects of the present disclosure. The automobile 200 may be equipped with multiple imaging or sensing devices including, for example, cameras 202, 204, 206, 208, 212, 214, and sensors 216, 218. The automobile 200 may include sensors such as tire pressure or braking sensors as the sensors 216, 218. The automobile 200 may also include one or more antennas 210 for radio frequency reception, wireless communications, and / or radio navigation using a position location system, such as a global positioning system (GPS) . A central controller 220 may be coupled to each of the cameras 202, 204, 206, 208, 212, 214, sensors 216, 218 and antennas 210. The central controller 220 may configure and manage automated systems and / or driver assistance systems. In some implementations, the central controller 220 may be configured to operate as an engine control unit that manages the operation and performance of the engine, motor, motors, or other power systems in the automobile 200. In some instances, the central controller 220 may include a system-on-chip (SoC) , such as the SoC 100.

[0027] Robust data communication links are specified to support the large number of cameras deployed within the automobile 200. In some examples, 20-30 cameras may be deployed to support automation and driver assistance systems. Each camera may be capable of generating data at a rate of between 1-10 gigabits per second (GBps) resulting in aggregate data rates of up to 300 GBps.

[0028] FIGURE 3 is a block diagram illustrating an Automotive Safety Integrity Level (ASIL) data path having raw NAND-based non-volatile memory (NVM) devices configured for bad block management, in accordance with various aspects of the present disclosure. As shown in FIGURE 3, an automotive data path 300 includes a central processing unit (CPU) cluster 302. Although a single CPU cluster 302 is depicted for ease of explanation, the present disclosure is not so limited. The CPU cluster 302 includes a set of CPU cores 304 that work concurrently or in parallel to perform computational tasks via workloads distributed across the set of CPU cores 304. The set of CPU cores 304 are respectively interconnected such that each core may perform a portion of a task. Portions of a task may be assigned to each core of the CPU cores 304 by a scheduler (not illustrated) hosted by the CPU cluster 302. The CPU cluster 302 is coupled to a system-on-chip (SoC) interconnect 306.

[0029] The SoC interconnect 306 links various upstream components, such as the CPU cluster 302 and cache (not illustrated) to various downstream components. Additionally, the SoC interconnect 306 facilitates on-chip communications and transaction handling between the upstream components and downstream components on the automotive data path 300. The SoC interconnect 306 is coupled to computation engines 308. The computation engines 308 represent one or more logic structures on the automotive data path 300 that are downstream from the SoC interconnect 306.

[0030] The computation engines 308 may include functionally complex, area intensive logic structures on the path to dynamic random-access memory (DRAM) in an SoC. For example, the computation engines 308 may include compression engines, encryption engines, a last-level cache, and other computational or memory structures. Compression engines apply compression techniques to reduce the data footprint of data packets transmitted on the automotive data path 300, thus reducing bandwidth specified to transmit the data packets. Encryption engines implement cryptographic techniques to encrypt data packets. A last-level cache serves as high-capacity, low-latency memory storage for upstream components such as the CPU cluster 302. The computation engines 308 are coupled to a memory controller 310.

[0031] The memory controller 310 manages data flow between a DRAM 312 and upstream components on the automotive data path 300, such as the CPU cluster 302. The memory controller 310 coordinates memory access requests from the upstream components to reduce memory bandwidth and latency. The DRAM 312, coupled to the memory controller 310, serves as the primary volatile storage for the automotive data path 300, providing memory space for stored information. While smaller data packets and data packets specifying low access latency may be stored in a cache within the automotive data path 300, larger data packets and data packets specifying higher access latency may instead be stored in the DRAM 312 by the memory controller 310.

[0032] In FIGURE 3, each of the components in the automotive data path 300 may be rated as conforming to the highest safety integrity level, e.g., ASIL-D. For instance, ASIL-D may specify strict path protection across complex structures, such as the computation engines 308, the memory controller 310, and the DRAM 312. Similarly, other safety levels, such as ASIL-C, may also be associated with components in the automotive data path 300. Safety systems, the CPU cluster 302, and other critical systems may be tested upon bootup to ensure compliance with the safety specifications. Each of these components in the automotive data path 300 may be subject to in-system test mechanisms when powering on and powering off the vehicle and while operating the vehicle in the field.

[0033] Available automotive control systems may be implemented using an automotive chipset. In modern automotive chipsets, an amount of time consumed during a bootup process (e.g., “boot time” ) is of significant importance. In particular, the amount of time consumed during the bootup process is a key performance indicator (KPI) of these automotive chipsets. As a result, achieving a fast boot time for automotive chipsets has become a factor that directly impacts the ability to start early feature initializations. Unfortunately, initialization and management of non-volatile memory (NVM) devices during bootup of automotive chipsets significantly increases the boot time.

[0034] During bootup, a loader (e.g., file system / kernel / boot loader) identifies any bad blocks in a raw NAND-based NVM device, which involves a significant number of page read commands issued by software (SW) . For example, if the raw NAND-based device has 4096 blocks, 4096 page read commands are issued by the SW. This results in a substantial number of raw NAND page read commands simply to identify if a block is bad or not, which has a significant impact on boot KPIs. An efficient bad block management solution for raw NAND-based NVM devices is illustrated, for example, in FIGURE 4.

[0035] FIGURE 4 is a block diagram illustrating good / bad block management for raw NAND-based non-volatile memory (NVM) , according to various aspects of the present disclosure. According to an open NAND flash interface (ONFI) specification, a raw NAND-based device is a primary / boot storage device on mobile broadband (MBB) modem and telematics applications of an automotive system. The ONFI specification restricts operation of raw NAND-based devices performing read / write operations to good blocks, in which prior reading of the blocks is specified to determine the good blocks. Unfortunately, ONFI raw NAND-based devices do not have the resources to separately manage the good / bad blocks of raw NAND-based NVM devices.

[0036] FIGURE 4 illustrates a bad block table (BBT) for managing bad blocks of raw NAND-based NVM devices, according to various aspects of the present disclosure. According to various aspects of the present disclosure, at the host side, the host no longer maintains any bad block tables. In some implementations, a raw NAND-based NVM device 400 maintains bad block information for each memory block of the respective raw NAND-based NVM device 400. For example, the raw NAND-based NVM device 400 can maintain spare pages in some memory blocks to maintain bad block information for all memory blocks of the raw NAND-based NVM device 400, which is referred to as a bad block table (BBT) 420.

[0037] As shown in FIGURE 4, the BBT 420 of the raw NAND-based NVM device 400 is utilized for managing bad blocks because there is no firmware on ONFI raw NAND-based devices to manage bad blocks. In current solutions, bad block management is completely handled by host operating system (OS) images (e.g., multiple images) , in which each host OS image maintains its own bad blocks. In these current solutions, the boot software reads allocated blocks (e.g., first page in a memory block) to check whether the block is identified as good or bad.

[0038] As an example, considering fifteen (15) megabits per second (15 MB / s) as an average speed for a single four kilobyte (4k) page and an average number of blocks (e.g., 4096 blocks) , the total number of page reads are 4k for 4096 blocks, which equals sixteen (16) MB of data. Consequently, a total time spent reading pages to identify whether the block is bad is around one (1) second to read all 4k pages, one (1) in each block. In practice, an ONFI raw NAND-based controller / device performance is limited (e.g., around 23 MB / s) ; however, if a requested command is a single page read, software (SW) performance is further reduced (e.g., to significantly less than 15 MB / s) . Additionally, performance of any operation on a raw NAND device is strictly limited to the raw NAND blocks that are good (e.g., do not include the bad block signature) . Unfortunately, because conventional raw NAND devices do not maintain a bad block table (BBT) , each software access to a raw NAND device involves checking whether a block is bad by issuing a page read command. Performing this process at bootup is time consuming and detrimental to boot KPIs, which are very critical for automotive customers.

[0039] As shown in FIGURE 4, host software (SW) operating system (OS) image (s) 402 utilize the BBT 420 that is maintained in a reserved block of the raw NAND-based NVM device 400 for performing bad block management. In this example, the host SW OS images 402 include a primary bootloader (PBL) image 404, an extensible bootloader (XBL) image 406, a unified extensible firmware interface (UEFI) image 408, a high-level operating system (HLOS) image 410 and / or a modem peripheral subsystem (MPSS) image 412. According to various aspects of the present disclosure, the PBL image 404, the XBL image 406, the UEFI image 408, the HLOS image 410, and the MPSS image 412 utilize the BBT 420 for performing bad block management of an NVM 430 of the raw NAND-based NVM device 400.

[0040] In this example, the NVM 430 (e.g.., blocks B0, B1, …, B39) of the raw NAND-based NVM device 400 is divided into a PBL partition 440, an XBL partition 450, a UEFI partition 460, an HLOS partition 470, and an MPSS partition 480. Additionally, each block (e.g., B0, B1, …, B39) of the NVM 430 is represented by a corresponding bit in the BBT 420 f indicating whether a block is a good block or a bad block. For example, blocks B2, B11, B13, B17, B22, B27, B28, B31, and B38 are represented as bad blocks in the BBT 420 (e.g., a 1-bit represents a bad block, and a 0-bit represents a good block) .

[0041] The raw NAND-based NVM device 400 has an intelligence and memory to maintain data related to the device (e.g., manufacturer information, number of pages, blocks, logical unit numbers (LUNs) , voltage information, and the like) . During operation, this device data information is retrieved by issuing a read parameter page (ECh) command. Additionally, SET FEATURES (EFh) and GET FEATURES (EEh) are commands that set and get device features. For example, according to the ONFI specification, these commands use a one-byte feature address to determine which sub-feature parameters will be read or modified. For example, the SET FEATURES (EFh) command writes sub-feature parameters (P1–P4) to the specified feature address. According to various aspects of the present disclosure, a new sub command Bad Block Table (0x3) is proposed to write and read the BBT 420, as shown in Tables I and II. Table I –Feature Parameter Addresses Table II –Command Parameters

[0042] As shown in FIGURE 4, the raw NAND-based NVM device 400 maintains the BBT 420 in a reserved block to maintain bad block information for all memory blocks of the NVM 430. In this example, each bit in the BBT 420 represents whether or not a block of the NVM 430 is bad. If the block is bad, a respective bit is set to ‘1. ’ During operation, the SET FEATURES (EFh) and GET FEATURES (EEh) commands set and get the BBT 420. Additionally, factory marked blocks are initially marked as bad by the device vendor.

[0043] As shown in Table I, the SET FEATURES (EFh) and GET FEATURES (EEh) commands are utilized with the Bad Block Table sub-command (03h) to read / update the BBT 420. For example, the software issues the SET FEATURES (EFh) command with the sub-command (e.g., Bad Block Table) 03h to mark a block as bad at runtime. The software issues the GET FEATURES (EEh) command with the sub command (Bad Block Table) 03h to get the complete bad block table. Using this command retrieves the BBT 420 of the raw NAND-based NVM device 400. In particular, this single command retrieves the BBT 420. As shown in Table II, parameters P1 to P4 are non-applicable (NA) for the GET FEATURES (EEh) command. Additionally, the command data (BBT) can copy the BBT 420 to a data buffer of one of the host SW OS images 402.

[0044] FIGURES 5A and 5B are flowcharts illustrating good / bad block management for raw NAND-based non-volatile memory (NVM) , according to various aspects of the present disclosure. FIGURE 5A is a flowchart illustrating a bad block table read process 500, according to various aspects of the present disclosure. FIGURE 5B is a flowchart illustrating a bad block marking process 550.

[0045] As shown in FIGURE 5A, the bad block table read process 500 begins at block 502, in which a NAND driver frames a GET FEATURES command with a bad block table subcommand during bootup. In this example, block 502 triggers a read bad block request at step 1. At block 510, the NAND driver sends the GET FEATURES (bad block table) sub-command to a NAND controller. Block 510 triggers issuance of a GET FEATURES command for the Bad Block Table. At block 520, the NAND controller sends the GET FEATURES command for the Bad Block Table to the raw NAND-based NVM device. In this example, block 520 triggers issuance of a GET FEATURES command for the Bad Block Table to the raw NAND-based NVM device to initialize the BBT 420 in a reserved block of the raw NAND-based NVM device. For example, as shown in FIGURE 4, initialization of the BBT 420 includes factory marked blocks that are initially marked as bad by the device vendor (e.g., bad block B2) .

[0046] At block 530, the raw NAND-based NVM device executes the GET FEATURES command for the Bad Block Table and returns the bad block table. Block 530 triggers a return of the Bad Block Table to the NAND controller at step 4. At step 5, the Bad Block Table is returned to the NAND driver. At step 6, the bad block table is returned to the host software. For example, as shown in FIGURE 4, the BBT 420 is returned to a requesting one of the PBL image 404, the XBL image 406, the UEFI image 408, the HLOS image 410, or the MPSS image 412. In this example, the requesting one of the host SW OS images 402 utilizes the BBT 420 for performing bad block management of the NVM 430 of the raw NAND-based NVM device 400.

[0047] An open NAND flash interface (ONFI) raw NAND device is a primary / boot storage device on mobile broadband (MBB) modem and telematics applications of an automotive system. In practice, a boot time (bootup process) is a key performance indicator (KPI) having significant importance for automotive customers. Unfortunately, ONFI raw NAND devices do not have firmware to manage the non-volatile memory (NVM) devices. For example, as shown in FIGURE 4, a layout of the raw NAND-based NVM device 400 may be implemented with an eight (8) gigabyte (GB) density (e.g., two (2) four (4) GB stacks) . An architecture associated with the raw NAND-based NVM device 400 may be composed of an eight (8) -bit width input / output (IO) bus having a predetermined page size (e.g., 4K+256 bytes) and a predetermined block size (e.g., 256K+16K bytes) to provide a predetermined device size (e.g., 8 GB, 4096 blocks) .

[0048] FIGURE 5B is a flowchart illustrating a bad block marking process 550, according to various aspects of the present disclosure. As noted, operation of the raw NAND-based NVM device 400 limits read / write operations to performance on good blocks, which specify reading of the blocks to determine the good blocks. For example, to check if a block is bad, existing code reads the first page of the block, at a fixed offset / byte, to determine whether a bad block signature is detected. In this example, if the first page of the block, at a fixed offset / byte, does not contain a predetermined good block value (e.g., 0xFF) , then the block is considered a bad block. In practice, bad blocks that are identified at a factory are marked as bad blocks by a device vendor. Additionally, if a block goes bad at runtime, software (SW) explicitly marks the block as bad by writing a bad block marker in the first page at the fixed page offset.

[0049] The bad block marking process 550 begins at block 560, in which the SW file system identifies a bad block at runtime (e.g., from an error returned by a raw NAND-based NVM device) . At block 562, the file system invokes a NAND driver to mark the block as a bad block in the bad block table. At block 564, the NAND driver frames a SET FEATURES command with a sub-command 0x3 (Bad Block Table) , in which the parameters P1 to P4 are set with a block number of the bad block. At block 566, the NAND driver triggers the SET FEATURES command to the NAND controller. At block 568, the raw NAND-based NVM device updates the block as a bad block in the Bad Block Table, such as the BBT 420 shown in FIGURE 4.

[0050] Various aspects of the present disclosure are directed to a bad block table (BBT) sub-command, which is utilized using SET / GET FEATURES commands that are incorporated into the ONFI specifications. According to various aspects of the present disclosure, at the host side, the host no longer maintains any bad block tables. Rather, the host is reconfigured to send commands (e.g., SET / GET FEATURES commands) to read / update a bad block table. In particular, the entire operating system (OS) image is relieved of the duty of maintaining a bad block table.

[0051] In some implementations, the disclosed bad block management solution reads an entirety of the bad blocks information from a reduced number of pages (e.g., 1 or 2 eight kb (8K) pages) in a reduced amount of time (e.g., 0.5 milliseconds (ms) ) . This disclosed bad block management solution provides a substantial boot key performance indicator (KPI) improvement substantially reducing a boot time (e.g., boot KPI in 800 ms to 1 second) on raw NAND-based memory device targets. Additionally, the disclosed bad block management solution simplifies bad block management by utilizing a single page to store bad block information about an entire raw NAND-based memory device. A process for efficient bad block management of raw NAND-based non-volatile memory devices is illustrated, for example, in FIGURE 6.

[0052] FIGURE 6 is a process flow diagram illustrating a method 600 for efficient bad block management of raw NAND-based non-volatile memory (NVM) devices, according to various aspects of the present disclosure. At block 602, a system including the raw NAND-based NVM device is booted. For example, as shown in FIGURE 5A, the bad block table read process 500 begins at block 502, in which a NAND driver frames a GET FEATURES command with a bad block table subcommand during bootup. In this example, block 502 triggers a read bad block request at step 1.

[0053] At block 602, a request is transmitted by a driver of the raw NAND-based NVM device for a bad block table stored in a reserved block of the raw NAND-based NVM device. For example, as shown in FIGURE 5A, at block 510, the NAND driver sends the GET FEATURES (bad block table) sub-command to a NAND controller. Block 510 triggers issuance of a GET FEATURES command for the Bad Block Table.

[0054] At block 606, a memory controller directs the request for the bad block table to the raw NAND-based NVM device. For example, as shown in FIGURE 5A, at block 520, the NAND controller sends the GET FEATURES command for the Bad Block Table to the raw NAND-based NVM device. In this example, block 520 triggers issuance of a GET FEATURES command for the Bad Block Table to the raw NAND-based NVM device to initialize the BBT 420 in a reserved block of the raw NAND-based NVM device. For example, as shown in FIGURE 4, initialization of the BBT 420 includes factory marked blocks that are initially marked as bad by the device vendor (e.g., bad block B2) .

[0055] At block 608, the raw NAND-based NVM device provides the bad block table, in which each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block. For example, as shown in FIGURE 5A, at block 530, the raw NAND-based NVM device executes the GET FEATURES command for the Bad Block Table and returns the bad block table. Block 530 triggers a return of the Bad Block Table to the NAND controller at step 4. At step 5, the Bad Block Table is returned to the NAND driver. At step 6, the bad block table is returned to the host software.

[0056] In some aspects, the method 600 may be performed by the SoC 100 (FIGURE 1) . That is, each of the elements of method 600 may, for example, but without limitation, be performed by the SoC 100 or one or more processors (e.g., CPU 102 and / or NPU 130) and / or other components included therein.

[0057] FIGURE 7 is a block diagram showing an exemplary wireless communications system 700 in which an aspect of the disclosure may be advantageously employed. For purposes of illustration, FIGURE 7 shows three remote units 720, 730, and 750, and two base stations 740. It will be recognized that wireless communications systems may have many more remote units and base stations. Remote units 720, 730, and 750 include IC devices 725A, 725C, and 725B that include the disclosed bad block management. It will be recognized that other devices may also include the disclosed bad block management, such as the base stations, switching devices, and network equipment. FIGURE 7 shows forward link signals 780 from the base stations 740 to the remote units 720, 730, and 750, and reverse link signals 790 from the remote units 720, 730, and 750 to base stations 740.

[0058] In FIGURE 7, remote unit 720 is shown as a mobile telephone, remote unit 730 is shown as a portable computer, and remote unit 750 is shown as a fixed location remote unit in a wireless local loop system. For example, the remote units may be a mobile phone, a hand-held personal communications systems (PCS) unit, a portable data unit, such as a personal data assistant, a GPS enabled device, a navigation device, a set top box, a music player, a video player, an entertainment unit, a fixed location data unit, such as meter reading equipment, or other device that stores or retrieves data or computer instructions, or combinations thereof. Although FIGURE 7 illustrates remote units according to aspects of the present disclosure, the disclosure is not limited to these exemplary illustrated units. Aspects of the present disclosure may be suitably employed in many devices, which include the bad block management.

[0059] FIGURE 8 is a block diagram illustrating a design workstation used for circuit, layout, and logic design of a semiconductor component, such as that of the bad block management technique in raw NAND-based non-volatile memory (NVM) devices disclosed above. A design workstation 800 includes a hard disk 801 containing operating system software, support files, and design software such as Cadence or OrCAD. The design workstation 800 also includes a display 802 to facilitate design of a circuit 810 or an integrated circuit (IC) component 812 such as the disclosed bad block management technique. A storage medium 804 is provided for tangibly storing the design of the circuit 810 or the IC component 812 (e.g., the raw NAND-based memory configured with the disclosed bad block management) . The design of the circuit 810 or the IC component 812 may be stored on the storage medium 804 in a file format such as GDSII or GERBER. The storage medium 804 may be a CD-ROM, DVD, hard disk, flash memory, or other appropriate device. Furthermore, the design workstation 800 includes a drive apparatus 803 for accepting input from or writing output to the storage medium 804.

[0060] Data recorded on the storage medium 804 may specify logic circuit configurations, pattern data for photolithography masks, or mask pattern data for serial write tools such as electron beam lithography. The data may further include logic verification data such as timing diagrams or net circuits associated with logic simulations. Providing data on the storage medium 804 facilitates the design of the circuit 810 or the IC component 812 by decreasing the number of processes for designing semiconductor wafers.

[0061] Implementation examples are described in the following numbered clauses: 1. A method for efficient bad block management of a raw negative AND  (NAND) -based non-volatile memory (NVM) device, the method comprising: booting a system including the raw NAND-based NVM device; transmitting a request, by a driver of the raw NAND-based NVM device, for a  bad block table stored in a reserved block of the raw NAND-based NVM device; directing, by a memory controller, the request for the bad block table to the raw  NAND-based NVM device; and providing, by the raw NAND-based NVM device, the bad block table, in which  each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block. 2. The method of claim 1, further comprising initializing the bad block  table in the reserved block of the raw NAND-based NVM device according to factory marked bad blocks by a device vendor. 3. The method of any of clauses 1 or 2, further comprising updating each  block in the bad block table corresponding to the memory block of the raw NAND-based NVM device to identify whether the memory block is marked as the bad block or the good block. 4. The method of any of clauses 1-3, in which each bit in the bad block  table indicates whether a block of the raw NAND-based NVM device is bad or good. 5. The method of any of clauses 1-4, in which booting the system  comprises issuing, by a host software (SW) operating system (OS) image, the request for the bad block table. 6. The method of clause 5, in which the SW OS image comprises a primary  bootloader (PBL) image, an extensible bootloader (XBL) image, a unified extensible firmware interface (UEFI) image, a modem peripheral subsystem (MPSS) image, and / or a high-level operating system (HLOS) image. 7. The method of any of clauses 1-6, further comprising: identifying the bad block at runtime; and invoking the driver of the raw NAND-based NVM device to mark the bad block. 8. The method of clause 7, further comprising: framing, by the driver of the raw NAND-based NVM device, a bad block table  sub-command, including a block number of the bad block; and triggering the bad block table sub-command to the memory controller of the raw  NAND-based NVM device. 9. The method of clause 8, further comprising updating, by the raw NAND- based NVM device, the bad block table according to the block number of the bad block. 10. The method of clause 7, in which identifying the bad block comprises: accessing, by a software (SW) file system, a block of the raw NAND-based  NVM device; receiving, by the SW file system, an error from the raw NAND-based NVM  device; and detecting the block of the raw NAND-based NVM device as the bad block. 11. A non-transitory computer-readable medium having program code  recorded thereon for efficient bad block management of a raw negative AND (NAND) -based non-volatile memory (NVM) device, the program code being executed by a processor and comprising: program code to boot a system including the raw NAND-based NVM device; program code to transmit a request, by a driver of the raw NAND-based NVM  device, for a bad block table stored in a reserved block of the raw NAND-based NVM device; program code to direct, by a memory controller, the request for the bad block  table to the raw NAND-based NVM device; and program code to provide, by the raw NAND-based NVM device, the bad block  table, in which each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block. 12. The non-transitory computer-readable medium of clause 11, further  comprising program code to initialize the bad block table in the reserved block of the raw NAND-based NVM device according to factory marked bad blocks by a device vendor. 13. The non-transitory computer-readable medium of any of clauses 11 or  12, further comprising program code to update each block in the bad block table corresponding to the memory block of the raw NAND-based NVM device to identify whether the memory block is marked as the bad block or the good block. 14. The non-transitory computer-readable medium of claim 11, in which  each bit in the bad block table indicates whether a block of the raw NAND-based NVM device is bad or good. 15. The non-transitory computer-readable medium of any of clauses 11-14,  in which the program code to boot the system comprises program code to issue, by a host software (SW) operating system (OS) image, the request for the bad block table. 16. The non-transitory computer-readable medium of clause 15, in which the  SW OS image comprises a primary bootloader (PBL) image, an extensible bootloader (XBL) image, a unified extensible firmware interface (UEFI) image, a modem peripheral subsystem (MPSS) image, and / or a high-level operating system (HLOS) image. 17. The non-transitory computer-readable medium of any of clauses 11-16,  further comprising: program code to identify the bad block at runtime; and program code to invoke the driver of the raw NAND-based NVM device to  mark the bad block. 18. The non-transitory computer-readable medium of clause 17, further  comprising: program code to frame, by the driver of the raw NAND-based NVM device, a  bad block table sub-command, including a block number of the bad block; and program code to trigger the bad block table sub-command to the memory  controller of the raw NAND-based NVM device. 19. The non-transitory computer-readable medium of clause 18, further  comprising program code to update, by the raw NAND-based NVM device, the bad block table according to the block number of the bad block. 20. The non-transitory computer-readable medium of clause 17, in which the  program code to identify the bad block comprises: program code to access, by a software (SW) file system, a block of the raw  NAND-based NVM device; program code to receive, by the SW file system, an error from the raw NAND- based NVM device; and program code to detect the block of the raw NAND-based NVM device as the  bad block.

[0062] For a firmware and / or software implementation, the methodologies may be implemented with modules (e.g., procedures, functions, etc. ) that perform the functions described herein. A machine-readable medium tangibly embodying instructions may be used in implementing the methodologies described herein. For example, software codes may be stored in a memory and executed by a processor unit. Memory may be implemented within the processor unit or external to the processor unit. As used herein, the term “memory” refers to types of long term, short term, volatile, nonvolatile, or other memory and is not limited to a particular type of memory or number of memories, or type of media upon which memory is stored.

[0063] If implemented in firmware and / or software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium. Examples include computer-readable media encoded with a data structure and computer-readable media encoded with a computer program. Computer-readable media includes physical computer storage media. A storage medium may be an available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, include compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk and  disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0064] In addition to storage on a non-transitory computer-readable medium, instructions and / or data may be provided as signals on transmission media included in a communications apparatus. For example, a communications apparatus may include a transceiver having signals indicative of instructions and data. The instructions and data are configured to cause one or more processors to implement the functions outlined in the claims.

[0065] Although the present disclosure and its advantages have been described in detail, various changes, substitutions, and alterations can be made herein without departing from the technology of the disclosure as defined by the appended claims. For example, relational terms, such as “above” and “below” are used with respect to a substrate or electronic device. Of course, if the substrate or electronic device is inverted, above becomes below, and vice versa. Additionally, if oriented sideways, above, and below may refer to sides of a substrate or electronic device. Moreover, the scope of the present application is not intended to be limited to the configurations of the process, machine, manufacture, composition of matter, means, methods, and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform the same function or achieve the same result as the corresponding configurations described herein may be utilized according to the present disclosure. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

[0066] Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0067] The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0068] The steps of a method or algorithm described in connection with the disclosure may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

[0069] The previous description of the disclosure is provided 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 may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1.A method for efficient bad block management of a raw negative AND (NAND) -based non-volatile memory (NVM) device, the method comprising:booting a system including the raw NAND-based NVM device;transmitting a request, by a driver of the raw NAND-based NVM device, for a bad block table stored in a reserved block of the raw NAND-based NVM device;directing, by a memory controller, the request for the bad block table to the raw NAND-based NVM device; andproviding, by the raw NAND-based NVM device, the bad block table, in which each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block.2.The method of claim 1, further comprising initializing the bad block table in the reserved block of the raw NAND-based NVM device according to factory marked bad blocks by a device vendor.3.The method of claim 1, further comprising updating each block in the bad block table corresponding to the memory block of the raw NAND-based NVM device to identify whether the memory block is marked as the bad block or the good block.4.The method of claim 1, in which each bit in the bad block table indicates whether a block of the raw NAND-based NVM device is bad or good.5.The method of claim 1, in which booting the system comprises issuing, by a host software (SW) operating system (OS) image, the request for the bad block table.6.The method of claim 5, in which the SW OS image comprises a primary bootloader (PBL) image, an extensible bootloader (XBL) image, a unified extensible firmware interface (UEFI) image, a modem peripheral subsystem (MPSS) image, and / or a high-level operating system (HLOS) image.7.The method of claim 1, further comprising:identifying the bad block at runtime; andinvoking the driver of the raw NAND-based NVM device to mark the bad block.8.The method of claim 7, further comprising:framing, by the driver of the raw NAND-based NVM device, a bad block table sub-command, including a block number of the bad block; andtriggering the bad block table sub-command to the memory controller of the raw NAND-based NVM device.9.The method of claim 8, further comprising updating, by the raw NAND-based NVM device, the bad block table according to the block number of the bad block.10.The method of claim 7, in which identifying the bad block comprises:accessing, by a software (SW) file system, a block of the raw NAND-based NVM device;receiving, by the SW file system, an error from the raw NAND-based NVM device; anddetecting the block of the raw NAND-based NVM device as the bad block.11.A non-transitory computer-readable medium having program code recorded thereon for efficient bad block management of a raw negative AND (NAND) -based non-volatile memory (NVM) device, the program code being executed by a processor and comprising:program code to boot a system including the raw NAND-based NVM device;program code to transmit a request, by a driver of the raw NAND-based NVM device, for a bad block table stored in a reserved block of the raw NAND-based NVM device;program code to direct, by a memory controller, the request for the bad block table to the raw NAND-based NVM device; andprogram code to provide, by the raw NAND-based NVM device, the bad block table, in which each block in the bad block table corresponds to a memory block of the raw NAND-based NVM device to identify whether the memory block is marked as a bad block or a good block.12.The non-transitory computer-readable medium of claim 11, further comprising program code to initialize the bad block table in the reserved block of the raw NAND-based NVM device according to factory marked bad blocks by a device vendor.13.The non-transitory computer-readable medium of claim 11, further comprising program code to update each block in the bad block table corresponding to the memory block of the raw NAND-based NVM device to identify whether the memory block is marked as the bad block or the good block.14.The non-transitory computer-readable medium of claim 11, in which each bit in the bad block table indicates whether a block of the raw NAND-based NVM device is bad or good.15.The non-transitory computer-readable medium of claim 11, in which the program code to boot the system comprises program code to issue, by a host software (SW) operating system (OS) image, the request for the bad block table.16.The non-transitory computer-readable medium of claim 15, in which the SW OS image comprises a primary bootloader (PBL) image, an extensible bootloader (XBL) image, a unified extensible firmware interface (UEFI) image, a modem peripheral subsystem (MPSS) image, and / or a high-level operating system (HLOS) image.17.The non-transitory computer-readable medium of claim 11, further comprising:program code to identify the bad block at runtime; andprogram code to invoke the driver of the raw NAND-based NVM device to mark the bad block.18.The non-transitory computer-readable medium of claim 17, further comprising:program code to frame, by the driver of the raw NAND-based NVM device, a bad block table sub-command, including a block number of the bad block; andprogram code to trigger the bad block table sub-command to the memory controller of the raw NAND-based NVM device.19.The non-transitory computer-readable medium of claim 18, further comprising program code to update, by the raw NAND-based NVM device, the bad block table according to the block number of the bad block.20.The non-transitory computer-readable medium of claim 17, in which the program code to identify the bad block comprises:program code to access, by a software (SW) file system, a block of the raw NAND-based NVM device;program code to receive, by the SW file system, an error from the raw NAND-based NVM device; andprogram code to detect the block of the raw NAND-based NVM device as the bad block.

Images