System and method for storing operating life history on a non-volatile dual inline memory module

An information handling system includes a non-volatile dual in-line memory module (NVDIMM) and a processor. The NVDIMM instantiates first and second partitions of non-volatile memory. The first partition is reserved and is not accessible to an operating system instantiated on the information handling system. The second partition is accessible to the operating system. The first partition includes a first region and a second region. The processor boots the information handling system to configure the NVDIMM based upon information from the first region, detects an error associated with the NVDIMM, and writes information associated with the error to the second region.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to information handling systems, and more particularly relates to storing operating life history on a Non-Volatile Dual Inline Memory Module (NVDIMM).

BACKGROUND

SUMMARY

An information handling system may include a non-volatile dual in-line memory module (NVDIMM) and a processor. The NVDIMM may instantiate first and second partitions of non-volatile memory. The first partition may be reserved and is not accessible to an operating system instantiated on the information handling system. The second partition may be accessible to the operating system. The first partition may include a first region and a second region. The processor may boot the information handling system to configure the NVDIMM based upon information from the first region, detect an error associated with the NVDIMM, and write information associated with the error to the second region

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1shows a portion of an information handling system100including a CPU or processor102, and dual in-line memory modules (DIMMs)104,106, and108. CPU102includes a processor core120and a memory controller126. CPU102may include additional components (not shown), without varying from the scope of this disclosure. CPU102executes code to implement a basic input/output system (BIOS)122, and upon completion of a boot process of the BIOS, executes an operating system (OS)124. BIOS122represents firmware code utilized during the boot process to execute a power-on self-test (POST), to initialize the hardware components of information handling system100, and to pass execution to OS124. For example, the hardware components of information handling system100initialized by BIOS122may include, but are not limited to, CPU102and DIMMs104,106, and108. BIOS122also represents firmware code to provide runtime services for OS124and other programs executed by CPU102. BIOS122includes a non-volatile dual in-line memory module (NVDIMM) firmware interface table (NFIT)130, and memory reference code (MRC)132. NFIT130stores information including, but not limited to, persistent memory ranges and properties for DIMMs104,106, and108.

DIMMS104,106, and108represent DIMMs that make one or more types of memory134accessible to CPU102for data storage. For example, DIMMs104,106, and108may include dynamic random access memory (DRAM), flash memory storage, NVDIMM storage, or other types of storage, as needed or desired. When one or more of DIMMs104,106, or108represents NVDIMM storage, the NVDIMM storage may include: NVDIMM-F having only persistent memory, such as flash storage; NVDIMM-N having both flash storage and DRAM on the same memory module; NVDIMM-P having persistent DRAM; and NVDIMM-X having NAND flash storage and DRAM on the same memory module. In a particular embodiment, one or more of DIMMs104,106, and108represent NVDIMMs that utilize Intel Optane DC Persistent Memory Modules (Apache Pass (AEP)) DIMMs with memory134configured according to one of the memory types stated above, such as NVDIMM-F. One of ordinary skill in the art will recognize that whileFIG. 1illustrates DIMMs104,106, and108, this disclosure is not limited to three DIMMs but can be applied to any number of DIMMs, as indicated by the ellipses in between DIMMs104and106. In an embodiment, one or more of DIMMs104,106, and108may include additional components (not shown), without varying from the scope of this disclosure.

CPU102provides the data processing functionality of information handling system100, such as is typically associated with an information handling system. As such, CPU102represents a data processing apparatus, such as one or more processor cores, and the associated data input and output (I/O) functionality, such as a chipset component, and other I/O processor components. CPU102operates to execute machine-executable code to perform the data processing tasks associated with information handling system100.

BIOS122can be referred to as a firmware image, and the term BIOS is herein used interchangeably with the term firmware image, or simply firmware. BIOS122includes instructions executable by CPU102to initialize and test the hardware components of system100, and to load a boot loader or OS124from a mass storage device. BIOS122additionally provides an abstraction layer for the hardware, i.e. a consistent way for application programs and operating systems to interact with the keyboard, display, and other input/output devices. When power is first applied to information handling system100, the information handling system begins a sequence of initialization procedures. During the initialization sequence, also referred to as a boot sequence, components of information handling system100are configured and enabled for operation, and device drivers for the components is installed. Device drivers provide an interface through which other components of information handling system100communicate with a corresponding device.

In a particular embodiment, BIOS122is substantially compliant with one or more revisions of the Unified Extensible Firmware Interface (UEFI) specification. The UEFI specification standard replaces the antiquated personal computer BIOS system found in some older information handling systems. The UEFI specification provides standard interfaces and interoperability guidelines for devices and components that together make up an information handling system. In particular, the UEFI specification provides a standardized architecture and data structures to manage initialization and configuration of devices, booting of platform resources, and passing of control to the operating system. The UEFI specification allows for the extension of platform firmware by loading UEFI driver and UEFI application images. For example, an original equipment manufacturer can include customized or proprietary images to provide enhanced control and management of information handling system100. While the techniques disclosed herein are described in the context of a UEFI compliant system, one of skill will appreciate that the disclosed systems and methods can be implemented at substantially any information handling system having configurable firmware.

Memory controller126represents a portion of a processor complex that is dedicated to the management of the data storage and retrieval from the memory devices of information handling system100, and the information handling system100may include one or more additional memory controllers similar to the memory controller126, as needed or desired. Memory controller126may reside on a system printed circuit board, may be integrated into an I/O processor component, may be integrated with a processor on a system-on-a-chip (SoC), or may be implemented in another way, as needed or desired. Memory controller126operates to provide data and control interfaces to one or more DIMMs, such as DIMMs104,106, and108, in accordance with a particular memory architecture. For example, memory controller126and the DIMMs104,106, and108may operate in accordance with a Double-Data Rate (DDR) standard, such as a JEDEC DDR4 or DDR5 standard.

Typically, before any usable memory134within DIMMs104,106, and108may be accessed by OS124, BIOS122performs a POST for information handling system100. During the POST, BIOS122executes MRC132to access information associated with DIMMs104,106, and108and configure a memory address decode register for DIMMs104,106, and108as will be described herein. In an embodiment, the information associated with DIMMs104,106, and108stored within the memory address decode register may include, but is not limited to, a mode of operation for DIMMs104,106, and108, and a total amount of memory for the DIMMs, and the like. The mode of operation can be an application-direct mode, a memory mode, a storage mode, or the like. In the application-direct mode, applications executed by processor core120via OS124directly access data stored within DIMMs104,106, and108. In the memory mode, a DRAM portion of DIMMs104,106, and108are accessed by processor core120of CPU102to store data in the DIMMs. In the storage mode, data is accessed in DIMMs104,106, and108in a block data format. These modes of operation can be set as attributes for DIMMs104,106, and108by the OS124, by UEFI environment of BIOS122, or the like. After the memory address decode register has been configured for DIMMs104,106, and108and other operations of POST have been completed, BIOS122may exit POST and processor core120performs one or more runtime operations of OS124.

FIG. 2illustrates a phase diagram200for an information handling system that operates using a UEFI, including a security phase (SEC)210, a pre-EFI initialization phase (PEI)220, a driver execution environment phase (DXE)230, a boot device selection phase (BDS)240, a transient system load phase (TSL)250, a run time phase (RT)260, and an afterlife phase (AL) (not shown). SEC210is the first phase of a UEFI boot process on the information handling system that operates to set up a pre-verifier212. Pre-verifier212handles all restart events on the information handling system, and temporarily allocates a portion of memory for use during the other boot phases. SEC210is executed out of the firmware resident on the information handling system, such as BIOS122, and so serves as a root of trust for the system. SEC210passes execution to PEI220which initializes the system memory for the information handling system. PEI220includes CPU initialization224, chipset initialization (not shown), and board resource initialization (not shown).

PEI220passes execution to DXE230which performs device specific initializations for the information handling system. In particular, DXE230executes an EFI driver dispatcher232that operates to load device, bus, and service drivers234. For example, the EFI driver dispatcher232may load drivers including, but not limited to, an address range scrubbing (ARS) driver, a block input/output (I/O) driver, and a partition driver. DXE230passes execution to BDS240to execute a boot manager242which identifies a boot target, and passes execution to TSL250. TSL250launches an OS boot loader252which loads the operating system, and passes execution to the operating system262at RT260.

Techniques disclosed herein may typically be implemented during DXE230, and may utilize services provided by the UEFI specification, such as boot services. UEFI applications, including OS loaders, must use boot services functions to access devices and allocate memory. Services are defined by interface functions that may be used by code running in the UEFI environment. Such code may include protocols that manage device access or extend platform capability, as well as applications running in the pre-boot environment, and OS loaders. During boot, system resources are owned by the firmware and are controlled through boot services interface functions. All boot services functionality is available until an OS loader loads enough of its own environment to take control of the system's continued operation and then terminates boot services with a call to ExitBootServices( ).

One class of boot services includes protocol handler services, such as LoadImage, StartImage, InstallProtocolInterface, RegisterProtocolNotify, LocateProtocol, and numerous others. A protocol consists of a 128-bit globally unique identifier (GUID) and a Protocol Interface structure. The structure contains the functions and instance data that are used to access a device. The functions that make up Protocol Handler Services allow applications to install a protocol on a handle, identify the handles that support a given protocol, determine whether a handle supports a given protocol, and the like. LoadImage loads an image, such as a device driver, into system memory. StartImage transfers control to a loaded image's entry point. InstallProtocolInterface installs a protocol interface on a device handle. A driver can install multiple protocols. RegisterProtocolNotify registers an event that is to be signaled whenever an interface is installed for a specified protocol. LocateProtocol returns an array of handles that support a specified protocol. During DXE230, boot services and runtime services can be started and a UEFI boot manager can load UEFI drivers and UEFI applications in an order defined by the global NVRAM variables. Driver initialization includes identifying a driver image that is stored on some type of media, such as at NVRAM330ofFIG. 3. While the techniques disclosed herein are typically implemented during DXE230, in another embodiment, these techniques can be implemented using UEFI system management services, such as SmmInstallProtocolInterface, SmmRegisterProtocolNotify, and the like.

FIG. 3illustrates an information handling system300similar to information handling system100ofFIG. 1, including a CPU302, dual in-line memory modules (DIMMs)304,306, and308(DIMMs304-308), and a non-volatile random access memory (NVRAM)330. Information handling system300may include additional components (not shown), without varying from the scope of this disclosure. CPU302includes a processor core320and a memory controller326. CPU302may include additional components (not shown), without varying from the scope of this disclosure. CPU302is in communication with NVRAM330, which stores a BIOS322. CPU302executes BIOS322, and upon completion of the BIOS322executes an OS324.

Each of DIMMs304,306, and308includes memory340and serial presence detect (SPD) data342. CPU302communicates with each of DIMMs304,306, and308via one or more communication interfaces344. In an embodiment, each communication interface344, shown between CPU302and DIMM304,306, and308represents one or more different communication interfaces. In particular, a first portion of communication interface344may represent a high-bandwidth data communication interface for communicating data between CPU302and memory340. For example, the high-bandwidth data communication interface may include an interface that operates in accordance with a Double-Data Rate (DDR) standard, such as a JEDEC DDR4 or DDR5 standard. Further, a second portion of communication interface344may represent a low-bandwidth data communication interface for communicating data between CPU302and SPD data342. For example, the low-bandwidth data communication interface may include a System Management Bus (SMBus) interface. During a boot process, such as a POST portion of PEI phase220of a UEFI boot process, BIOS322operates to access SPD data342from each of DIMMs304,306, and308to configure the operations between CPU302and the DIMMs. SPD data342includes information as to the configuration, capacity, signal timing requirements, and other parameters for the operation between CPU302and DIMMs304,306, and308. After BIOS322configures the operations between CPU302and DIMMs304,306, and308, the CPU can communicate with memory340in the DIMMs directly via the high-bandwidth communication interface.

In a particular embodiment, one or more of DIMMs304,306, and308represents a NVDIMM such as an Intel Optane DC Persistent Memory Module (DCPMM) DIMM. Here, a portion of memory340is reserved for various functions that are related to how the NVDIMM is to be utilized in information handling system300. For example, BIOS322can store information related to the memory mode (e.g., application-direct mode, memory mode, storage mode) in which to operate the NVDIMM, to namespaces instantiated on the NVDIMM, or the like. Here, the information can be stored on different partitions of memory340that are restricted from access by the CPU under the control of OS324. That is, the partitions may represent memory regions of memory340that are reserved to the use of BIOS322.

FIG. 4illustrates a partition map400of a NVDIMM, such as an Intel Optane DC Persistent Memory Module (DCPMM) DIMM. Partition map400includes partitions402,404,406, and408. Partition402is a 128 kilobyte (KB) partition that includes a 64 KB region410that is reserved for information stored by a manufacturer of the NVDIMM, for example, for Intel proprietary information related to the configuration of the NVDIMM. Partition402also includes a 64 KB region412that is accessible to an original equipment manufacturer (OEM) for storage of information that is at the OEMs discretion. Various embodiments information to be stored in OEM region412will be described further below. Partition404is a 128 KB partition that includes a configuration data segment414. Partition406is a 128 KB partition that includes namespace data for one or more NVDIMMs that are configured in the storage mode. Partition408represents the bulk of the data storage capacity of the DIMM that is usable in the selected mode by the information handling system for data storage.

Returning toFIG. 3, BIOS322further includes an error log module336that operates to detect and log errors on information handling system300. The errors can include hardware errors, machine check exceptions, software generated errors, and the like. Generally, the error logs can be utilized to troubleshoot and determine a root cause of the fault conditions. However, when an error relates to one or more of DIMMs304,306, or308, a user of information handling system300may access the error logs generated by error log module336, and, after determining that the error relates to a DIMM, may return the DIMM to an OEM to determine what caused the DIMM to fail. Here, because the error logs that directed the user to identify the DIMM as failing resides on the information handling system, the OEM is deprived of critical information whereby the OEM can determine the cause of the DIMM failure.

In a particular embodiment, a NVDIMM stores error log information in its OEM region of the NVDIMM memory to facilitate the determination of NVDIMM failures.FIG. 5illustrates OEM region412in an embodiment of the present disclosure. OEM region412includes error log data500. In a particular embodiment, when an error log module, such as error log module336, detects an error in the operation of a NVDIMM, the error log module stores information related to the error in error log data500. An example of an error in the operation of a NVDIMM that may be stored in error log data500may include errors in an address range scrubbing (ARS) operation during the POST of an information handling system or during runtime operation of the information handling system. Other errors stored in error log data500may include boot time errors, such as an unclean shutdown, incomplete boot process, disabled storage media, and the like, or may include run time errors, such as changes in the health status of the NVDIMM. Additionally, error log data500may include a log of the number and timing of important memory related commands, such as security or overwrite related commands, or the like. For example, during a boot process, an indication as to the firmware commands issued to the NVDIMM could be utilized to determine whether or not the firmware commands were successfully executed. In a particular embodiment, when an error is detected, a System Management Interrupt (SMI) is issued to the processor of the information handling system, and the BIOS executes error log module336out of System Management Mode (SMM) to store the information related to the error in error log data500.

FIG. 6is a flow diagram illustrating a method600for logging the working life history of a NVDIMM, such as an Intel Optane DCPMM, starting at block602. It will be readily appreciated that not every method step set forth in this flow diagram is always necessary, and that certain steps of the methods can be combined, performed simultaneously, in a different order, or perhaps omitted, without varying from the scope of the disclosure. At block604, an information handling system initiates a POST process. For example, an information handling system may instantiate a BIOS or UEFI, and the BIOS or UEFI can initiate a POST process when the information handling system is powered on.

A decision is made as to whether or not there were any memory related failures or errors during the POST process in decision block606. The failures or errors that may be deemed to be related to the system memory may be any of the failures or errors as described above. If there were any memory related failures or errors during the POST process, the “YES” branch of decision block606is taken, the failure or error information is written to the OEM region on the NVDIMM in block608, and the method proceeds to block610as described below. If there were not any memory related failures or errors during the POST process, the “NO” branch of decision block606is taken and the method proceeds to block610as described below.

At block610, run time operation of the information handling system is begun. For example, during a TSL phase of a UEFI boot process, the control of the information handling system may be passed from the boot process to the control of an operating system. A decision is made as to whether or not there were any memory related failures or errors during the run time operation of the information handling system in decision block612. The failures or errors that may be deemed to be related to the system memory may be any of the failures or errors as described above. If there were any memory related failures or errors during the run time operation of the information handling system, the “YES” branch of decision block612is taken, the failure or error information is written to the OEM region on the NVDIMM in block614, and the method ends at block616. If there were not any memory related failures or errors during the run time operation of the information handling system, the “NO” branch of decision block612is taken and the method ends in block614.

FIG. 7illustrates a general information handling system700including a processor702, a memory704, a northbridge/chipset706, a PCI bus708, a universal serial bus (USB) controller710, a USB712, a keyboard device controller714, a mouse device controller716, a configuration an ATA bus controller720, an ATA bus722, a hard drive device controller724, a compact disk read only memory (CD ROM) device controller726, a video graphics array (VGA) device controller730, a network interface controller (NIC)740, a wireless local area network (WLAN) controller750, a serial peripheral interface (SPI) bus760, a NVRAM770for storing BIOS772, and a baseboard management controller (BMC)780. In an embodiment, information handling system700may be information handling system100ofFIG. 1and/or information handling system300ofFIG. 3. BMC780can be referred to as a service processor or embedded controller (EC). Capabilities and functions provided by BMC780can vary considerably based on the type of information handling system. For example, the term baseboard management system is often used to describe an embedded processor included at a server, while an embedded controller is more likely to be found in a consumer-level device. As disclosed herein, BMC780represents a processing device different from CPU702, which provides various management functions for information handling system700. For example, an embedded controller may be responsible for power management, cooling management, and the like. An embedded controller included at a data storage system can be referred to as a storage enclosure processor.

For purpose of this disclosure information handling system700can include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, information handling system700can be a personal computer, a laptop computer, a smart phone, a tablet device or other consumer electronic device, a network server, a network storage device, a switch, a router, or another network communication device, or any other suitable device and may vary in size, shape, performance, functionality, and price. Further, information handling system700can include processing resources for executing machine-executable code, such as CPU702, a programmable logic array (PLA), an embedded device such as a System-on-a-Chip (SoC), or other control logic hardware. Information handling system700can also include one or more computer-readable medium for storing machine-executable code, such as software or data.

System700can include additional processors that are configured to provide localized or specific control functions, such as a battery management controller. Bus760can include one or more busses, including a SPI bus, an I2C bus, a system management bus (SMBUS), a power management bus (PMBUS), and the like. BMC780can be configured to provide out-of-band access to devices at information handling system700. As used herein, out-of-band access herein refers to operations performed prior to execution of BIOS772by processor702to initialize operation of system700.

BIOS772can be referred to as a firmware image, and the term BIOS is herein used interchangeably with the term firmware image, or simply firmware. BIOS772includes instructions executable by CPU702to initialize and test the hardware components of system700, and to load a boot loader or an operating system (OS) from a mass storage device. BIOS772additionally provides an abstraction layer for the hardware, such as a consistent way for application programs and operating systems to interact with the keyboard, display, and other input/output devices. When power is first applied to information handling system700, the system begins a sequence of initialization procedures. During the initialization sequence, also referred to as a boot sequence, components of system700are configured and enabled for operation, and device drivers can be installed. Device drivers provide an interface through which other components of the system700can communicate with a corresponding device.

Information handling system700can include additional components and additional busses, not shown for clarity. For example, system700can include multiple processor cores, audio devices, and the like. While a particular arrangement of bus technologies and interconnections is illustrated for the purpose of example, one of skill will appreciate that the techniques disclosed herein are applicable to other system architectures. System700can include multiple CPUs and redundant bus controllers. One or more components can be integrated together. For example, portions of northbridge/chipset706can be integrated within CPU702. Additional components of information handling system700can include one or more storage devices that can store machine-executable code, one or more communications ports for communicating with external devices, and various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. For example, device controller730may provide data to a display device790to visually present the information to an individual associated with information handling system700. An example of information handling system700includes a multi-tenant chassis system where groups of tenants (users) share a common chassis, and each of the tenants has a unique set of resources assigned to them. The resources can include blade servers of the chassis, input/output (I/O) modules, Peripheral Component Interconnect-Express (PCIe) cards, storage controllers, and the like.

Information handling system700can include a set of instructions that can be executed to cause the information handling system to perform any one or more of the methods or computer based functions disclosed herein. The information handling system700may operate as a standalone device or may be connected to other computer systems or peripheral devices, such as by a network.

The information handling system700can include a disk drive unit and may include a computer-readable medium, not shown inFIG. 7, in which one or more sets of instructions, such as software, can be embedded. Further, the instructions may embody one or more of the methods or logic as described herein. In a particular embodiment, the instructions may reside completely, or at least partially, within system memory704or another memory included at system700, and/or within the processor702during execution by the information handling system700. The system memory704and the processor702also may include computer-readable media.

The device or module can include software, including firmware embedded at a processor or software capable of operating a relevant environment of the information handling system. The device or module can also include a combination of the foregoing examples of hardware or software. Note that an information handling system can include an integrated circuit or a board-level product having portions thereof that can also be any combination of hardware and software.