Memory testing method and apparatus

Abstract

The present disclosure relates to a memory testing method and device, and belongs to the technical field of semiconductor testing. The method comprises: determining fault address positioning information of a first fault memory based on a first memory fault event detected by a test program; writing the fault address positioning information into a non-volatile storage area in a system running process to obtain fault address record data; determining the fault address positioning information according to the obtained fault address record data in response to a system restart operation; performing a state modification operation on a fault entry in the first fault memory based on the fault address positioning information to obtain a fault shielding physical address; and performing a test operation on the first fault memory based on the fault shielding physical address to obtain a memory test result. The present disclosure stores the physical slot address of the fault into the non-volatile storage area, shields the fault address after the system restart, removes the fault address from the available physical address, and tests to skip these fault addresses at the hardware level.

Description

Technical Field

[0001] This disclosure relates to the field of semiconductor testing technology, and more specifically, to a memory testing method, a memory testing apparatus, an electronic device, and a computer program product. Background Technology

[0002] Dynamic Random Access Memory (DRAM) is a type of volatile semiconductor memory whose memory cells require periodic refreshes to retain data. DRAM system-level testing schemes are designed to verify the functionality, performance, and reliability of DRAM under conditions close to real-world application environments. System-level testing typically places the DRAM on a standard system motherboard or a specially designed test board, performing read / write, refresh, and stress tests through the actual memory controller and bus interface. This testing method covers real-world signal environments that are difficult to simulate with Automatic Test Equipment (ATE), thus more effectively identifying defects that would only surface under system-level operating conditions.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] The purpose of this disclosure is to provide a memory testing method, a memory testing device, an electronic device, a computer-readable storage medium, and a computer program product, thereby overcoming, to at least a certain extent, the problem that in memory system-level testing, it is impossible to dynamically and completely shield detected faulty memory within a single test process, resulting in the ineffective use of subsequent test time and low test productivity.

[0005] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0006] According to a first aspect of this disclosure, a memory testing method is provided, comprising: determining fault address location information of a first faulty memory based on a first memory fault event detected by a test program; writing the fault address location information to a non-volatile storage area during system operation to obtain fault address record data; in response to a system restart operation, determining the fault address location information by the firmware side based on the fault address record data obtained from the non-volatile storage area; performing a status modification operation on fault entries in the first faulty memory based on the fault address location information to obtain a fault masking physical address; and performing a test operation on the first faulty memory based on the fault masking physical address to obtain a memory test result.

[0007] In one exemplary embodiment of this disclosure, determining the fault address location information of the first faulty memory based on the first memory fault event detected by the test program includes: in response to the first memory fault event, determining the faulty physical address corresponding to the first faulty memory; performing a decoding operation on the faulty physical address based on an address decoding library to obtain the fault address location information, wherein the fault address location information is a quadruple constructed from the processor slot identifier, the memory controller identifier, the memory channel identifier, and the memory slot identifier.

[0008] In one exemplary embodiment of this disclosure, the step of writing the fault address location information into a non-volatile storage area during system operation to obtain fault address record data includes: the test program writing the fault address location information into the sensor data record of the baseboard management controller through a first interface to obtain the fault address record data.

[0009] In one exemplary embodiment of this disclosure, the step of determining the fault address location information by the firmware side based on the fault address record data obtained from the non-volatile storage area in response to a system restart operation includes: initiating a power-on self-test operation of the basic input / output system firmware in response to the system restart operation; querying the sensor data record by the basic input / output system before the memory controller initialization operation; and obtaining the fault address location information by the parsing module in the basic input / output system based on the sensor data record by reading the sensor status byte and reading field.

[0010] In one exemplary embodiment of this disclosure, the step of performing a state modification operation on the fault entry in the first faulty memory based on the fault address location information to obtain the fault-masking physical address includes: parsing the fault address location information to obtain a fault address quadruple; obtaining a pre-configured memory configuration structure array, the memory configuration structure array including a status identifier bit; determining the fault entry corresponding to the fault address quadruple based on the status identifier bit, the fault entry being a memory entry whose status identifier bit is a fault identifier; obtaining the initial state corresponding to the fault entry, and modifying the initial state to a specified state through the state modification operation to obtain the fault-masking physical address.

[0011] In one exemplary embodiment of this disclosure, the step of writing the fault address location information into a non-volatile storage area during system operation to obtain fault address record data further includes: the test program serializing the fault address location information through a second interface to obtain serialized fault address location information; and writing the serialized fault address location information into a non-volatile firmware interface runtime variable of a unified extensible firmware interface to obtain the fault address record data.

[0012] In one exemplary embodiment of this disclosure, the step of determining the fault address location information by the firmware side based on the fault address record data obtained from the non-volatile storage area in response to a system restart operation includes: performing a memory controller initialization operation in response to the system restart operation; loading an execution environment driver during the driver execution environment phase of the unified extensible firmware interface; and obtaining the fault address record data from the runtime variables of the non-volatile firmware interface through a variable acquisition function by the execution environment driver to obtain the fault address location information.

[0013] In one exemplary embodiment of this disclosure, the step of performing a status modification operation on the fault entry in the first fault memory based on the fault address location information to obtain the fault masking physical address includes: parsing the fault address location information by the execution environment driver to obtain a fault address information list, the fault address information list including the fault entry; and performing a status modification operation on the fault entry by the execution environment driver to obtain the fault masking physical address.

[0014] In one exemplary embodiment of this disclosure, the step of modifying the state of the fault entry by the execution environment driver to obtain the fault masking physical address includes: the execution environment driver modifying the state of the fault entry by a memory configuration protocol to obtain the fault masking physical address.

[0015] In one exemplary embodiment of this disclosure, the step of modifying the state of the fault entry by the execution environment driver to obtain the fault masking physical address includes: the execution environment driver performing a state modification operation on the fault entry through a memory reference code library function to obtain the fault masking physical address.

[0016] In one exemplary embodiment of this disclosure, the step of performing a test operation on the first faulty memory based on the fault-masking physical address to obtain a memory test result includes: performing memory training and initialization operations based on the fault-masking physical address; masking the address location information of the fault entry by adjusting the physical address mapping to obtain a target test address, wherein the target test address is the remaining address in the memory address of the first faulty memory after removing the fault address corresponding to the fault entry; and performing a test operation on the first faulty memory based on the target test address to obtain a memory test result.

[0017] In one exemplary embodiment of this disclosure, the step of performing a test operation on the first faulty memory based on the target test address to obtain a memory test result includes: generating a test vector for the target test address by the test program; and performing a test operation on the first faulty memory based on the test vector by the test program to obtain the memory test result.

[0018] In one exemplary embodiment of this disclosure, the method further includes: in response to a test end command, the baseboard management controller clears the fault flag bit in the fault address record data to obtain updated fault address record data; in response to a second memory fault event detected by the test program, performing a test operation on the second faulty memory based on the updated fault address record data.

[0019] In one exemplary embodiment of this disclosure, the method further includes: in response to a test end command, obtaining a pre-configured variable modification program; clearing the non-volatile firmware interface runtime variables to zero through the variable modification program to obtain updated fault address record data; and in response to a second memory fault event detected by the test program, performing a test operation on the second faulty memory based on the updated fault address record data.

[0020] According to a second aspect of this disclosure, a memory testing apparatus is provided, comprising: a fault information determination module, configured to determine fault address location information of a first faulty memory based on a first memory fault event detected by a test program; a fault information recording module, configured to write the fault address location information into a non-volatile storage area during system operation to obtain fault address recording data; a fault information reading module, configured to determine the fault address location information by the firmware side based on the fault address recording data obtained from the non-volatile storage area in response to a system restart operation; a fault state modification module, configured to perform a state modification operation on fault entries in the first faulty memory based on the fault address location information to obtain a fault masking physical address; and a memory testing module, configured to perform a test operation on the first faulty memory based on the fault masking physical address to obtain a memory test result.

[0021] In one exemplary embodiment of this disclosure, the fault information determination module includes a fault information determination unit, configured to: in response to the first memory fault event, determine the fault physical address corresponding to the first fault memory; perform a decoding operation on the fault physical address based on an address decoding library to obtain the fault address location information, wherein the fault address location information is a quadruple constructed from a processor slot identifier, a memory controller identifier, a memory channel identifier, and a memory slot identifier.

[0022] In one exemplary embodiment of this disclosure, the fault information recording module includes a first fault information recording unit, used to: write the fault address location information into the sensor data record of the baseboard management controller through the first interface by the test program, thereby obtaining the fault address recording data.

[0023] In one exemplary embodiment of this disclosure, the fault information reading module includes a first fault information reading unit, configured to: initiate a power-on self-test operation of the basic input / output system firmware in response to the system restart operation; query the sensor data records by the basic input / output system before the memory controller initialization operation; and obtain the fault address location information by reading the sensor status byte and reading field based on the sensor data records by the parsing module in the basic input / output system.

[0024] In one exemplary embodiment of this disclosure, the fault state modification module includes a first fault state modification unit, configured to: perform a parsing operation on the fault address location information to obtain a fault address quadruple; obtain a pre-configured memory configuration structure array, the memory configuration structure array including a status identifier bit; determine the fault entry corresponding to the fault address quadruple based on the status identifier bit, the fault entry being a memory entry whose status identifier bit is a fault identifier; obtain the initial state corresponding to the fault entry, and modify the initial state to a specified state through the state modification operation to obtain the fault masking physical address.

[0025] In one exemplary embodiment of this disclosure, the fault information recording module further includes a second fault information recording unit, used for: serializing the fault address location information by the test program through a second interface to obtain serialized fault address location information; and writing the serialized fault address location information into the non-volatile firmware interface runtime variable of the unified extensible firmware interface to obtain the fault address recording data.

[0026] In one exemplary embodiment of this disclosure, the fault information reading module includes a second fault information reading unit, configured to: perform a memory controller initialization operation in response to the system restart operation; load an execution environment driver during the driver execution environment phase of the unified extensible firmware interface; and obtain the fault address record data from the runtime variables of the non-volatile firmware interface through a variable acquisition function by the execution environment driver to obtain the fault address location information.

[0027] In one exemplary embodiment of this disclosure, the fault status modification module includes a second fault status modification unit, configured to: perform a parsing operation on the fault address location information by the execution environment driver to obtain a fault address information list, the fault address information list including the fault entries; and perform a status modification operation on the fault entries by the execution environment driver to obtain the fault masking physical address.

[0028] In one exemplary embodiment of this disclosure, the second fault state modification unit includes a first state modification subunit, used to: perform a state modification operation on the fault entry by the execution environment driver through a memory configuration protocol to obtain the fault masking physical address.

[0029] In one exemplary embodiment of this disclosure, the second fault state modification unit includes a second state modification subunit, used to: perform a state modification operation on the fault entry by the execution environment driver through a memory reference code library function to obtain the fault masking physical address.

[0030] In one exemplary embodiment of this disclosure, the memory testing module includes a memory testing unit, configured to: perform memory training and initialization operations based on the fault-masking physical address; mask the address location information of the fault entry by adjusting the physical address mapping to obtain a target test address, wherein the target test address is the remaining address in the memory address of the first faulty memory after removing the fault address corresponding to the fault entry; and perform testing operations on the first faulty memory based on the target test address to obtain memory test results.

[0031] In one exemplary embodiment of this disclosure, the memory testing unit includes a memory testing subunit, configured to: generate a test vector for the target test address by the testing program; and perform a test operation on the first faulty memory based on the test vector by the testing program to obtain the memory test result.

[0032] In one exemplary embodiment of this disclosure, the memory testing apparatus further includes a fault state reset module, configured to: in response to a test end command, clear the fault flag bit in the fault address record data by the baseboard management controller to obtain updated fault address record data; and in response to a second memory fault event detected by the test program, perform a test operation on the second faulty memory based on the updated fault address record data.

[0033] In one exemplary embodiment of this disclosure, the memory testing apparatus further includes a variable clearing module, configured to: in response to a test end command, acquire a pre-configured variable modification program; clear the runtime variables of the non-volatile firmware interface to zero through the variable modification program to obtain updated fault address record data; and in response to a second memory fault event detected by the test program, perform a test operation on the second faulty memory based on the updated fault address record data.

[0034] According to a third aspect of this disclosure, an electronic device is provided, comprising: a processor; and a memory storing computer-readable instructions that, when executed by the processor, implement the memory testing method according to any one of the preceding claims.

[0035] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the memory testing method according to any one of the preceding claims.

[0036] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the memory testing method described in any one of the preceding claims.

[0037] The technical solution provided in this disclosure may include the following beneficial effects: The memory testing method in the exemplary embodiments of this disclosure, on the one hand, proposes a dynamic fault address masking method. After detecting faulty memory, its physical slot address is stored in a non-volatile storage area so as to mask the faulty address during the memory initialization phase after system restart, removing it from the available physical address list, thereby automatically skipping these faulty addresses in subsequent hardware operations. On the other hand, the information relay station in the non-volatile storage area successfully bridges the two phases of runtime (test program in the operating system environment) and pre-boot system (firmware environment), realizing the persistence and transmission of fault states.

[0038] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0039] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating an exemplary embodiment of the memory testing method of this disclosure is shown schematically; Figure 2 This illustration schematically shows a flowchart of a memory test based on persistent storage of fault information via an out-of-band management channel, according to an exemplary embodiment of this disclosure. Figure 3 This illustration schematically shows a flowchart of a memory test using persistent storage of fault information via a unified extensible firmware interface, according to an exemplary embodiment of this disclosure. Figure 4 A block diagram of a memory testing apparatus according to an exemplary embodiment of the present disclosure is shown schematically; Figure 5 A schematic diagram of a computer-readable storage medium according to an exemplary embodiment of the present disclosure is shown. Figure 6 A block diagram of an electronic device according to an exemplary embodiment of the present disclosure is shown schematically. Detailed Implementation

[0040] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0041] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of the specific details described, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known structures, methods, apparatuses, implementations, materials, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0042] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, or in one or more software-hardened modules, or in different network and / or processor devices and / or microcontroller devices.

[0043] According to embodiments of this disclosure, a memory testing method, a memory testing apparatus, a computer-readable storage medium, an electronic device, and a computer program product are proposed.

[0044] In this article, it is important to understand that the terms used, such as Dual-Inline-Memory-Modules (DIMMs), are a common type of modular computer memory hardware used in desktops, laptops, and servers, and consist of multiple Random Access Memory (RAM) modules on a single printed circuit board.

[0045] Furthermore, the number of any elements in the accompanying drawings is for illustrative purposes only and not for limitation, and any naming is for distinction only and has no limiting meaning.

[0046] The principles and spirit of this disclosure will be explained in detail below with reference to several representative embodiments.

[0047] As DRAM storage density and system complexity continue to increase, System Level Test (SLT), as the final quality checkpoint before product shipment, is having an increasingly significant impact on overall production capacity due to its testing time and cost. Related SLT solutions, after detecting memory faults, still require indiscriminate testing of the entire address space, including the faulty memory cell. This is mainly achieved through two methods: First, software-level filtering. The test program maintains a "bad address list" and skips these addresses when generating subsequent test vectors. However, this cannot prevent the BIOS, memory controller, or system background services from accessing these addresses; the faulty memory cell still consumes system resources, and filtering calculations increase overhead. Second, manual intervention. After a test failure, an operator records the fault information and manually replaces the DIMM or adjusts the test configuration. This process is non-automated, inefficient, and prone to errors.

[0048] Neither of these two methods achieves complete hardware-level, automated, and cross-test cycle shielding. Furthermore, this testing mode has the following drawbacks: redundant testing of storage areas that have been identified as faulty not only consumes a large amount of valuable test machine time, severely dragging down test productivity, but may also cause faulty units to trigger system-level errors (such as crashes or data corruption) under continuous pressure, interfering with the test evaluation of normal units and increasing the uncertainty and risk of the overall testing process.

[0049] Based on this, in this example embodiment, a memory testing method is first provided. The memory testing method of this disclosure can be implemented using a server or using a terminal device. The terminal described in this disclosure can include mobile terminals such as mobile phones, tablets, laptops, handheld computers, and personal digital assistants (PDAs), as well as fixed terminals such as desktop computers. Figure 1 A schematic diagram illustrating a memory testing method flow according to some embodiments of the present disclosure is shown. Reference Figure 1 The memory testing method may include the following steps: Step S110: Based on the first memory fault event detected by the test program, determine the fault address location information of the first faulty memory; Step S120: Write the fault address location information into the non-volatile storage area during system operation to obtain fault address record data; In step S130, in response to the system restart operation, the firmware side determines the fault address location information based on the fault address record data obtained from the non-volatile storage area; Step S140: Based on the fault address location information, perform a status modification operation on the fault entry in the first fault memory to obtain the fault masking physical address; Step S150: Perform a test operation on the first faulty memory based on the fault-masking physical address to obtain the memory test results.

[0050] According to the memory testing method in this example embodiment, on the one hand, this disclosure proposes a dynamic fault address masking method. After detecting faulty memory, its physical slot address is stored in a non-volatile storage area so as to mask the faulty address during the memory initialization phase after system restart, removing it from the available physical address list, thereby automatically skipping these faulty addresses in subsequent hardware operations. On the other hand, the information relay station in the non-volatile storage area successfully bridges the two phases of runtime (test program in the operating system environment) and pre-boot system (firmware environment), realizing the persistence and transmission of fault states.

[0051] The memory testing method in this example implementation will be further explained below.

[0052] In one exemplary embodiment of this disclosure, for step S110, based on the first memory fault event detected by the test program, the fault address location information of the first fault memory is determined, including: in response to the first memory fault event, determining the fault physical address corresponding to the first fault memory; performing a decoding operation on the fault physical address based on the address decoding library to obtain the fault address location information, wherein the fault address location information is a quadruple constructed from the processor slot identifier, the memory controller identifier, the memory channel identifier, and the memory slot identifier.

[0053] The test program can be a software program that performs SLT testing on the memory under test. The test program typically runs on an operating system or a Unified Extensible Firmware Interface (UEFI) environment, specifically for reading, writing, verification, and stress testing of the memory subsystem. A memory failure event can be an event detected during the test that causes a memory failure, error, or anomaly. The first memory failure event can be a memory failure event detected during the ongoing SLT test. The first faulty memory can be the memory that failed in the first memory failure event.

[0054] SLT testing programs can detect faults through system error mechanisms or targeted testing. System error mechanisms may include, but are not limited to, Machine Check Architecture (MCA) and Error Detection and Correction (EDAC). When the SLT testing program detects a first memory fault event for a specific DIMM, it determines the first faulty memory corresponding to the first memory fault event and the corresponding faulty physical address.

[0055] refer to Figure 2 , Figure 2 This illustration schematically depicts a flowchart of a memory testing process based on persistent storage of fault information via an out-of-band management channel, according to an exemplary embodiment of this disclosure. In the SLT testing environment, in step S201, when the test program detects a memory fault (such as an error in a specific DIMM), it calls an address decoding library to decode the erroneous System Physical Address (SPA) into physical DIMM location information, i.e., the fault address location information of a four-tuple. The address decoding library can be an information database used to record the mapping relationship between physical addresses and hardware topology locations. Due to differences in memory interleaving and channel mapping rules across different platforms, a platform-specific decoding library is required to correctly parse the system physical address and obtain the physical DIMM location information.

[0056] Fault address location information can be used to describe the physical location of faulty memory. This information is not simply a physical address, but rather structured information that reflects the physical topology of the memory after decoding. Fault address location information can be encoded using a quadruple, which can include the processor socket identifier, memory controller identifier, memory channel identifier, and memory slot identifier.

[0057] The processor socket identifier (Socket_ID) uniquely identifies the processor socket. Since server motherboards typically have multiple processor sockets, each corresponding to a physical processor, the Socket_ID distinguishes which processor socket a DIMM is associated with. In server systems, the memory controller is integrated inside the processor; therefore, the DIMM's access channel is bound to a specific processor socket.

[0058] The Memory Controller Identifier (MC_ID) is a unique identifier for a memory controller. A single processor may integrate multiple memory controllers, each managing a set of memory channels. The MC_ID is used to distinguish which memory controller within the processor a given DIMM belongs to.

[0059] A memory channel identifier (Channel_ID) is a unique identifier for a memory channel. Multiple memory channels are connected to each memory controller, and each channel can connect to one or more DIMM slots. The Channel_ID identifies the specific memory channel to which the DIMM resides.

[0060] The memory slot identifier (Slot_ID) is a unique identifier for a DIMM slot. There are usually multiple DIMM slots on the same memory channel, and the Slot_ID is used to distinguish which slot on the channel the DIMM is inserted into.

[0061] The combination of the four fields (Socket_ID, MC_ID, Channel_ID, Slot_ID) uniquely identifies the physical location of a DIMM within the server. For example, a Socket_ID of 0, MC_ID of 1, Channel_ID of 2, and Slot_ID of 0 indicates that the DIMM is located in slot 0 of memory channel 2, managed by memory controller 1, under processor socket 0. When the system detects a DIMM error, this information can accurately determine the specific location of the faulty memory module on the motherboard. Through these steps, the SLT test program can accurately locate the physical location information of the faulty DIMM (such as CPU socket, memory channel, and DIMM slot) while running within the operating system, for subsequent address masking operations.

[0062] In one exemplary embodiment of this disclosure, step S120, writing the fault address location information to a non-volatile storage area during system operation to obtain fault address record data, includes: the test program writing the fault address location information to the sensor data record of the baseboard management controller through a first interface to obtain fault address record data.

[0063] In this embodiment, after decoding the fault address location information, it can be written to a non-volatile storage area during system operation. This ensures that the fault address location information is not lost after a system power failure and restart, and persistent storage of fault information is achieved through out-of-band communication. For example, the Baseboard Management Controller (BMC), as a management unit independent of the main system, stores the received fault information in a dedicated non-volatile area, such as the System Event Log (SEL) or a custom Field Replaceable Unit (FRU) field, ensuring that the information is not lost after a system power failure and restart.

[0064] The fault information is reported to the BMC via out-of-band communication. (Continue to refer to...) Figure 2 In step S202, the test program writes the quadruplet information to the Sensor Data Record (SDR). The test program uses the Keyboard Controller Style (KCS) interface of the Intelligent Platform Management Interface (IPMI) to write the quadruplet fault information encoded in step S201 into the sensor data record in the BMC. The BMC ensures that this information is not lost after system power failure. IPMI overKCS is a communication mechanism between the host and the BMC defined in the IPMI specification. Through these steps, the test program can write the fault DIMM identifier into the non-volatile memory of the board management controller via an out-of-band management protocol, achieving persistent storage of fault information. Furthermore, the use of a standardized out-of-band communication interface for fault information reporting gives this solution good platform compatibility and scalability, without relying on a specific operating system or software stack.

[0065] In one exemplary embodiment of this disclosure, for step S130, in response to a system restart operation, the firmware determines fault address location information based on fault address record data obtained from the non-volatile storage area, including: in response to a system restart operation, initiating a power-on self-test operation of the basic input / output system firmware; before the memory controller initialization operation, the basic input / output system queries the sensor data record; and the parsing module in the basic input / output system reads the sensor status byte and reading field based on the sensor data record to obtain the fault address location information, wherein the sensor data record stores fault address record data.

[0066] After completing the persistent storage of fault information, continue to refer to... Figure 2 In step S203, a system restart operation is performed, entering the Basic Input Output System (BIOS) Power-On Self-Test (POST) process. Before the Memory Reference Code (MRC) initialization phase, sensor status bytes and reading fields are read based on the SDR. For example, the BIOS queries the predefined SDR through its IPMI driver. The SDR is a data structure or storage area used to record information related to hardware sensors, containing recorded data related to hardware status and faults.

[0067] Customized BIOS code actively queries the Sensor Data Record (SDR) via system interfaces such as the System Management Bus (SMBus) and the KCS. The BIOS firmware includes a pre-configured parsing module corresponding to this SDR, which reads the sensor status byte and reading field based on the SDR. Through this read operation, fault location information can be retrieved from the SDR. The sensor status byte can be a one-byte field in the sensor data record representing the sensor's current state. The reading field can be a field in the sensor data record representing the number of reads or a read count. Following these steps, upon the next power-on, the system can actively query the fault DIMM list stored in the BMC before the memory controller initialization phase of the BIOS's power-on self-test.

[0068] In one exemplary embodiment of this disclosure, step S140, based on the fault address location information, involves performing a state modification operation on the fault entry in the first fault memory to obtain the fault-masking physical address. This includes: parsing the fault address location information to obtain a fault address quadruple; obtaining a pre-configured memory configuration structure array, which includes a status identifier bit; determining the fault entry corresponding to the fault address quadruple based on the status identifier bit, where the fault entry is a memory entry with a fault identifier bit; obtaining the initial state corresponding to the fault entry; and modifying the initial state to a specified state through a state modification operation to obtain the fault-masking physical address.

[0069] Continue to refer to Figure 2 In step S204, the quadruple is parsed, the fault entry is found in the memory configuration structure array, and the corresponding status is modified. The BIOS dynamically adjusts the memory configuration table. The BIOS memory initialization module maintains an internal DIMM configuration structure array (i.e., the memory configuration structure array) to record the configuration status of each physical DIMM slot. When a fault flag bit is read from the BMC, the BIOS performs a parsing operation on the fault address location information, such as parsing the quadruple in the reading field to obtain the fault address quadruple.

[0070] Each DIMM entry in the DIMM configuration structure array has a corresponding status flag to indicate whether the DIMM entry is available. After parsing the fault address quadruple, the corresponding DIMM fault entry can be found in the memory configuration structure array based on the fault address quadruple, and its status can be modified from the initial state to a specified state. The specified state can be an unavailable state, and the initial state can be the current state corresponding to the fault entry. The initial state can be an enabled state or a present state. The enabled or present state is modified to an unavailable state, thus obtaining the fault masking physical address.

[0071] The fault-masking physical address can be the address obtained after masking the physical address of the memory that is abnormal in the first faulty memory. Through the above steps, the decision-making and execution point of fault masking is brought forward from the traditional operating system / application layer to the earliest stage of hardware resource configuration, namely BIOS memory initialization. This achieves resource isolation at the lowest level of the system, realizing true hardware-level masking. Since the masking action is automatically completed by the underlying firmware, there is no need to modify the upper-level test program or operating system. The operating system and the SLT test program running on it perceive a clean and healthy memory pool, which greatly simplifies the complexity of the test software and improves the versatility of the solution.

[0072] In one exemplary embodiment of this disclosure, step S150, which involves testing the first faulty memory based on the fault-masking physical address to obtain memory test results, includes: performing memory training and initialization operations based on the fault-masking physical address; masking the address location information of the fault entry by adjusting the physical address mapping to obtain a target test address, wherein the target test address is the remaining address in the memory address of the first faulty memory after removing the fault address corresponding to the fault entry; and performing test operations on the first faulty memory based on the target test address to obtain memory test results.

[0073] Continue to refer to Figure 2 In step S205, memory training and initialization are performed based on the updated configuration array, skipping memory entries with a "not available" status. For example, standard MRC code performs memory training and initialization based on the updated "DIMM configuration structure array," which is the structure array obtained after modifying the status of fault entries in the DIMM configuration structure array.

[0074] Memory training and initialization can be considered as a complete process during system startup where the memory controller (MC) calibrates parameters, adjusts timings, and configures the state of the memory subsystem. Its core objective is to find the optimal signal timing and electrical parameter configuration between the memory controller and the DIMM (Digital Module) under specific hardware conditions, establishing a stable and reliable communication link.

[0075] The MRC code iterates through the DIMM configuration structure array in the order of memory controller, memory channel, and DIMM slot, reading the status field of each DIMM entry one by one to identify which DIMMs need to participate in initialization and training, and which DIMMs need to be skipped. For DIMM entries with a status field of "Unavailable," the following operations do not need to be performed: do not send mode register setting commands; do not perform signal training; do not allocate the address mapping range corresponding to the DIMM; and do not include the DIMM in the memory topology enumeration result. Therefore, DIMMs with a status of "Disabled" will be completely skipped, and the UEFI memory mapping that the BIOS finally passes to the operating system will not contain any address range corresponding to the faulty DIMM.

[0076] The memory controller only initializes and manages DIMMs that are reported as "existing and available" by the BIOS. Faulty DIMMs are excluded from the resource list at the lowest level of the system. Therefore, there is no need to allocate refresh commands or maintain the line buffer state for faulty DIMMs, which reduces the scheduling burden and power consumption of the controller and saves memory controller resources. At the same time, since faulty DIMMs are not initialized, their chips and buffer chips are in a non-powered or low-power state, which can reduce system power consumption. The bandwidth originally used to access faulty DIMMs is released and can be used for testing healthy DIMMs, which can indirectly improve test throughput.

[0077] After training, the standard MRC code generates updated memory topology information and address mapping tables based on the initialization results of all "available" DIMMs, thus adjusting the physical address mapping. By adjusting the physical address mapping, the address location information of faulty entries is masked, ensuring that the address space corresponding to the faulty DIMM will not appear in the available memory mapping, thereby obtaining the target test address. The target test address can be the test memory address space obtained during subsequent operating system testing, completely excluding the portion corresponding to the faulty DIMM; that is, the remaining address after removing the faulty address corresponding to the faulty entry from the memory address of the first faulty memory.

[0078] The UEFI memory mapping ultimately passed by the BIOS to the operating system will not contain any address range corresponding to the faulty DIMM, but only the target test address. Subsequent testing operations on the first faulty memory will be performed based on the target test address to obtain the memory test results. By adjusting the physical address mapping, the faulty memory can be physically shielded. Since the faulty DIMM is completely isolated, its sudden error cannot cause the entire test system to blue screen, restart, or data corruption, thus reducing system downtime. At the same time, it avoids coupling interference from the faulty unit to the normal unit (such as power supply noise and signal integrity degradation), making the test results for the healthy DIMM more accurate. In addition, the risk of interruption in long-term reliability testing (such as burn-in) is greatly reduced, ensuring the continuity of the test process.

[0079] In one exemplary embodiment of this disclosure, a test operation is performed on the first faulty memory based on a target test address to obtain a memory test result, including: generating a test vector for the target test address by a test program; and performing a test operation on the first faulty memory based on the test vector by the test program to obtain a memory test result.

[0080] Continue to refer to Figure 2In step S206, after the operating system starts, the test program obtains the target test address (i.e., available physical memory information) and generates test vectors only for the healthy address space. After the operating system starts, the SLT test program obtains the system's available physical memory information through standard APIs. The test program will only generate test vectors for the healthy address space, completely bypassing the masked faulty address space. Through the above test operations, when the SLT test program (or any application) runs under the operating system, its accessible memory range automatically masks faulty units, achieving transparent masking without modifying the test program itself.

[0081] Since subsequent tests completely skip the faulty DIMM, unnecessary read / write operations, verification, and error handling overhead for invalid cells are avoided, reducing the single test cycle by up to (N-1) / N. The percentage of time spent testing faulty DIMMs (N is the total number of DIMMs) allows for the testing of more devices under test to be completed within the same time frame, thus improving equipment utilization. Furthermore, the reduction in power and machine time consumption per unit of production capacity reduces testing costs. By concentrating fixed testing time and computing resources on healthy DIMMs, more thorough and rigorous testing modes (such as extending testing time and increasing pressure intensity) can be performed on healthy units.

[0082] In one exemplary embodiment of this disclosure, in response to a test end command, the baseboard management controller clears the fault flag bit in the fault address record data to obtain updated fault address record data; in response to a second memory fault event detected by the test program, a test operation is performed on the second faulty memory based on the updated fault address record data.

[0083] Continue to refer to Figure 2 In step S207, the fault flag bit corresponding to the sensor data record is cleared. After the test is completed, the BMC clears the fault flag bit corresponding to the SDR. The next time the system starts, the BIOS will re-identify and initialize the new DIMM on the slot.

[0084] When a faulty DIMM is replaced, the corresponding flag in the BMC is cleared via management commands, specifically by resetting the fault flag bit in the fault address record data to zero, resulting in updated fault address record data. Updated fault address record data can be obtained by resetting the fault flag bit in the fault address record data. This updated fault address record data can be used during the detection process of a new DIMM. For example, if a faulty DIMM is replaced with a new one, and the newly replaced DIMM also experiences a memory fault, a corresponding second memory fault event is generated.

[0085] When the test program detects a second memory fault event, it will perform a test operation on the second faulty memory based on the updated fault address record data. The test process for the second faulty memory is the same as that for the first faulty memory, and will not be described in detail here. By clearing the fault flag bit, the state of the faulty DIMM can be reset, so that it can be restored to normal identification on the next system startup without skipping the faulty address. Through the above steps, the entire process from fault detection to resource masking can be completed automatically without manual intervention; the test program does not need to integrate complex address filtering and fault handling logic, but only needs to focus on test stimulus generation and result analysis, which simplifies the test program design; and eliminates the fluctuation of test results caused by manual operation or differences in software filtering strategies, improving the consistency of the test process.

[0086] In one exemplary embodiment of this disclosure, step S120, which involves writing the fault address location information into a non-volatile storage area during system operation to obtain fault address record data, further includes: the test program serializing the fault address location information through a second interface to obtain serialized fault address location information; and writing the serialized fault address location information into a non-volatile firmware interface runtime variable of the unified extensible firmware interface to obtain fault address record data.

[0087] refer to Figure 3 , Figure 3 This illustration schematically shows a flowchart of a memory testing process using a unified extensible firmware interface (UEFI) according to an exemplary embodiment of this disclosure. In step S301, similar to step S201, the test program detects a memory fault, calls the address decoding library, and decodes the faulty system physical address into a four-tuple of fault address location information. The specific process of this step will not be described in detail in this embodiment. In step S302, the test program calls the second interface to serialize the fault address location information and write it into a predefined non-volatile firmware interface runtime variable of the UEFI. The second interface can be an interface different from the first interface; for example, the second interface can be an interface called by UEFI runtime services.

[0088] For example, the SLT test program can call the SetVariable() interface of the UEFI runtime service, which can be used to set the value of a variable that is data stored in the UEFI system. The test program writes fault address location information into a predefined, globally accessible UEFI variable. The variable data is serialized and stored using a custom structure, which can store multiple fault DIMM records. The UEFI firmware ensures that this variable is stored in the platform's non-volatile memory.

[0089] Through the above steps, fault address location information can be written into the Non-Volatile Random Access Memory (NVRAM) variable during UEFI runtime while the operating system is running. NVRAM variables are key-value pairs maintained by firmware (such as UEFI / BIOS) and stored in non-volatile media (such as SPI Flash). They are used to retain critical data such as system configuration, boot items, and security policies after power failure, serving as an important bridge for information transmission between the operating system and firmware, and realizing the persistence and transmission of fault address location information.

[0090] In one exemplary embodiment of this disclosure, for step S130, in response to a system restart operation, the firmware side determines the fault address location information based on the fault address record data obtained from the non-volatile storage area, including: in response to a system restart operation, performing a memory controller initialization operation; loading the execution environment driver during the driver execution environment stage of the unified extensible firmware interface; and obtaining the fault address record data from the runtime variables of the non-volatile firmware interface through a variable acquisition function by the execution environment driver to obtain the fault address location information.

[0091] Continue to refer to Figure 3 In step S303, the SLT test program triggers a warm reset, and the system enters the UEFI firmware environment. In step S304, during the UEFI driver execution environment phase, a specified interface is called to read variables. Early in the UEFI driver execution environment (DXE), a custom DXE driver (such as DimmDisableDxe.efi) is loaded, and this driver uses the GetVariable() runtime service to read the variables from step S302. The DXE is the execution phase that the UEFI firmware enters after completing memory initialization in the PEI (Pre-EFI Initialization) phase. During the DXE phase, main memory is available, and the firmware can load and execute a large number of UEFI drivers, completing the initialization and abstraction of various hardware devices in the system, preparing for the final boot of the operating system.

[0092] In this implementation, the variable retrieval function can be the GetVariable() function, which returns the value of a specified variable. The GetVariable() function is used to retrieve fault address record data from the NVRAM variable to obtain fault address location information. Through the above steps, it is possible to load the UEFI driver during the UEFI driver execution environment phase, read the NVRAM variable through the BIOS / UEFI driver, retrieve the fault address record data from the NVRAM variable, and obtain the fault address location information.

[0093] In one exemplary embodiment of this disclosure, step S140, which involves modifying the state of fault entries in the first fault memory based on fault address location information to obtain fault-masking physical addresses, includes: parsing the fault address location information by the execution environment driver to obtain a fault address information list, which includes fault entries; and modifying the state of the fault entries by the execution environment driver to obtain fault-masking physical addresses.

[0094] Continue to refer to Figure 3 In step S305, the driver parses variables to obtain a list of fault address information and marks the corresponding faulty memory as "unavailable". The memory configuration protocol is parsed and modified. The DXE driver parses the fault address location information obtained from the variable content. After the parsing operation is completed, a list of fault address information, i.e., a list of faulty DIMMs, is obtained. The list of faulty DIMMs can contain fault entries. A fault entry can be a record generated for each DIMM determined to be faulty after a memory fault is detected. Each fault entry uniquely identifies a faulty DIMM and describes its location, fault type, and related attributes.

[0095] For each fault entry in the fault DIMM list, the DXE driver modifies the status of the fault entry to obtain the fault-masking physical address. Through the above steps, the decision-making and execution point for fault masking can be advanced from the traditional operating system / application layer to the earliest stage of hardware resource configuration—BIOS memory initialization—thus achieving resource isolation at the lowest system level and realizing true hardware-level masking.

[0096] In one exemplary embodiment of this disclosure, the execution environment driver performs a state modification operation on the fault entry to obtain the fault masking physical address, including: the execution environment driver performs a state modification operation on the fault entry through a memory configuration protocol to obtain the fault masking physical address.

[0097] In this embodiment, the DXE driver can modify the status flags corresponding to the fault entry through the Memory Configuration Protocol provided by UEFI. Similar to the operation of modifying the status flags in step S204, the status flags of the fault entry are modified from the initial state to a specified state. The specified state can be an unavailable state, and the initial state can be the current state corresponding to the fault entry. The initial state can be an enabled or present state. The enabled or present state is then modified to disabled, obtaining the fault masking physical address. Through the above status modification operation, physical isolation of the faulty memory can be achieved during subsequent testing.

[0098] In one exemplary embodiment of this disclosure, the execution environment driver performs a state modification operation on the fault entry to obtain the fault masking physical address, including: the execution environment driver performs a state modification operation on the fault entry through a memory reference code library function to obtain the fault masking physical address.

[0099] In addition to using memory configuration protocols for status modification, platform-specific Memory Reference Code (MRC) library functions can be directly called to mark a faulty DIMM as "unavailable." For example, the DXE driver can obtain the set of MRC library functions corresponding to the current platform type and version. The platform-specific MRC library is provided by the platform firmware and encapsulates function interfaces related to memory controller initialization, memory topology enumeration, and DIMM status management.

[0100] The execution environment driver calls a function in the MRC library used to modify the DIMM status, passing the four-tuple location information of the faulty DIMM as a parameter. This four-tuple allows the MRC library function to uniquely index the location of the target DIMM in the memory topology. Upon receiving the call, the MRC library function finds the entry corresponding to the target DIMM in the memory topology data structure and modifies the DIMM's status field from its original state (e.g., "normal," "available," "enabled") to "unavailable." Specific implementation steps may include: updating the status flag of the faulty DIMM entry in the memory topology table; removing the memory address range corresponding to the DIMM from the available memory mapping; and updating the available capacity information of the memory channel and memory controller associated with the DIMM.

[0101] After the MRC library function completes execution, it returns the execution result (such as a success or failure status code) to the caller. The execution environment driver confirms that the target faulty DIMM has been successfully marked as "unavailable," thus completing the physical masking of the faulty memory. Through the above status modification operation, physical isolation of the faulty memory can be achieved during subsequent testing.

[0102] Continue to refer to Figure 3 In step S306, memory training and initialization are performed, skipping memory instances marked as "unavailable". The execution steps of step S306 are the same as those of step S205, and will not be repeated here. Through the above steps, the subsequent standard memory initialization process (executed by the platform MRC) is based on the modified DIMM configuration information, skipping all DIMMs marked as "unavailable", and the memory mapping ultimately passed to the operating system does not contain the addresses of these DIMMs. When the subsequent SLT test program (or any application) runs under the operating system, its accessible memory range automatically masks the faulty units, achieving transparent masking without requiring modification of the test program itself.

[0103] In this embodiment, after obtaining the fault masking physical address, the first faulty memory is tested based on the fault masking physical address, and the specific implementation process for obtaining the memory test result is the same as the aforementioned implementation process, and will not be repeated here.

[0104] In one exemplary embodiment of this disclosure, in response to a test end command, a pre-configured variable modification program is obtained; the runtime variables of the non-volatile firmware interface are cleared to zero through the variable modification program to obtain updated fault address record data; in response to a second memory fault event detected by the test program, a test operation is performed on the second fault memory based on the updated fault address record data.

[0105] In step S307, after entering the operating system or replacing the memory, the variable is cleared or deleted to prepare for the next test. After completing the test operation on the first faulty memory, a test end command is generated. After successful initialization and entering the operating system, or after replacing the DIMM, the NVRAM variable can be cleared or deleted through a UEFI application (running under UEFI Shell) or a privileged program in the operating system for variable modification (such as a variable modification program), to obtain updated fault address record data and prepare for the next test.

[0106] Similarly, the specific implementation process of testing the second fault memory corresponding to the second memory fault event after clearing the variable through the variable modification program is the same as the specific implementation process of subsequent testing after clearing the fault flag bit. This disclosure will not elaborate on this further.

[0107] It should be noted that the terms "first," "second," etc., used in this disclosure are only for distinguishing different memory failure events, interfaces, and faulty memory, and should not impose any limitations on this disclosure.

[0108] In summary, the memory testing method disclosed herein determines the fault address location information of the first faulty memory based on the first memory fault event detected by the test program; writes the fault address location information to a non-volatile storage area during system operation to obtain fault address record data; in response to a system restart operation, the firmware side determines the fault address location information based on the fault address record data obtained from the non-volatile storage area; based on the fault address location information, performs a status modification operation on the fault entries in the first faulty memory to obtain the fault masking physical address; and performs a test operation on the first faulty memory based on the fault masking physical address to obtain the memory test result. On one hand, this disclosure proposes a dynamic fault address masking method, which stores the physical slot address of faulty memory in a non-volatile storage area after detection, so as to mask the fault address during the memory initialization phase after system restart, removing it from the available physical addresses, thereby automatically skipping these fault addresses in subsequent hardware operations. On the other hand, the information relay station in the non-volatile storage area successfully bridges the two stages of runtime (test program in the operating system environment) and pre-system startup (firmware environment), realizing the persistence and transmission of fault states. On the other hand, in the earliest stage of system startup, automatic, persistent, transparent, and thorough hardware-level shielding of faulty DIMMs is achieved, thereby improving the efficiency and stability of SLT testing. Furthermore, the combined mechanism of BMC persistent storage and transparency to upper-layer software provides automated state memory across cycles, which is a key feature for achieving an automated closed loop of "one-time detection, permanent shielding." The shielding action is completed by the underlying firmware, and the test program does not need to be aware of or adapt to it, simplifying the integration complexity of the automation process.

[0109] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0110] Furthermore, a memory testing apparatus is also provided in this exemplary embodiment. (See reference) Figure 4 The memory testing device 400 may include: a fault information determination module 410, a fault information recording module 420, a fault information reading module 430, a fault status modification module 440, and a memory testing module 450.

[0111] Specifically, the fault information determination module 410 is used to determine the fault address location information of the first faulty memory based on the first memory fault event detected by the test program; the fault information recording module 420 is used to write the fault address location information to the non-volatile storage area during system operation to obtain fault address recording data; the fault information reading module 430 is used to determine the fault address location information by the firmware side based on the fault address recording data obtained from the non-volatile storage area in response to the system restart operation; the fault status modification module 440 is used to perform status modification operations on the fault entries in the first faulty memory based on the fault address location information to obtain the fault masking physical address; and the memory testing module 450 is used to perform test operations on the first faulty memory based on the fault masking physical address to obtain memory test results.

[0112] In one exemplary embodiment of this disclosure, the fault information determination module 410 includes a fault information determination unit, configured to: in response to a first memory fault event, determine the fault physical address corresponding to the first fault memory; perform a decoding operation on the fault physical address based on an address decoding library to obtain fault address location information, wherein the fault address location information is a quadruple constructed from a processor slot identifier, a memory controller identifier, a memory channel identifier, and a memory slot identifier.

[0113] In one exemplary embodiment of this disclosure, the fault information recording module 420 includes a first fault information recording unit, used to: write fault address location information into the sensor data record of the baseboard management controller through a first interface by a test program to obtain fault address recording data.

[0114] In one exemplary embodiment of this disclosure, the fault information reading module 430 includes a first fault information reading unit, used for: in response to a system restart operation, initiating a power-on self-test operation of the basic input / output system firmware; before the memory controller initialization operation, querying sensor data records by the basic input / output system; and obtaining fault address location information by the parsing module in the basic input / output system based on reading sensor status bytes and reading fields from the sensor data records, wherein fault address record data is stored in the sensor data records.

[0115] In one exemplary embodiment of this disclosure, the fault state modification module 440 includes a first fault state modification unit, configured to: perform a parsing operation on the fault address location information to obtain a fault address quadruple; obtain a pre-configured memory configuration structure array, the memory configuration structure array including a status identifier bit; determine the fault entry corresponding to the fault address quadruple based on the status identifier bit, the fault entry being a memory entry with a fault identifier bit; obtain the initial state corresponding to the fault entry, and modify the initial state to a specified state through a state modification operation to obtain the fault masking physical address.

[0116] In one exemplary embodiment of this disclosure, the fault information recording module 420 further includes a second fault information recording unit, used for: serializing the fault address location information by the test program through the second interface to obtain serialized fault address location information; and writing the serialized fault address location information into the non-volatile firmware interface runtime variable of the unified extensible firmware interface to obtain fault address recording data.

[0117] In one exemplary embodiment of this disclosure, the fault information reading module 430 includes a second fault information reading unit, used for: performing a memory controller initialization operation in response to a system restart operation; loading an execution environment driver during the driver execution environment phase of the unified extensible firmware interface; and obtaining fault address record data from the runtime variables of the non-volatile firmware interface through a variable acquisition function by the execution environment driver to obtain fault address location information.

[0118] In one exemplary embodiment of this disclosure, the fault status modification module 440 includes a second fault status modification unit, configured to: perform a parsing operation on the fault address location information by the execution environment driver to obtain a fault address information list, the fault address information list including fault entries; and perform a status modification operation on the fault entries by the execution environment driver to obtain the fault masking physical address.

[0119] In one exemplary embodiment of this disclosure, the second fault state modification unit includes a first state modification subunit, used to: perform a state modification operation on the fault entry by the execution environment driver through a memory configuration protocol to obtain the fault masking physical address.

[0120] In one exemplary embodiment of this disclosure, the second fault state modification unit includes a second state modification subunit, used to: perform state modification operations on fault entries by the execution environment driver through memory reference code library functions to obtain the fault masking physical address.

[0121] In one exemplary embodiment of this disclosure, the memory testing module 450 includes a memory testing unit, configured to: perform memory training and initialization operations based on the fault-masking physical address; mask the address location information of the fault entry by adjusting the physical address mapping to obtain a target test address, wherein the target test address is the remaining address in the memory address of the first faulty memory after removing the fault address corresponding to the fault entry; and perform testing operations on the first faulty memory based on the target test address to obtain memory test results.

[0122] In one exemplary embodiment of this disclosure, the memory testing unit includes a memory testing subunit, used for: generating a test vector for a target test address by a test program; and performing a test operation on a first faulty memory based on the test vector by the test program to obtain a memory test result.

[0123] In one exemplary embodiment of this disclosure, the memory testing apparatus 400 further includes a fault state reset module, configured to: in response to a test end command, clear the fault flag bit in the fault address record data by the baseboard management controller to obtain updated fault address record data; and in response to a second memory fault event detected by the test program, perform a test operation on the second faulty memory based on the updated fault address record data.

[0124] In one exemplary embodiment of this disclosure, the memory testing apparatus 400 further includes a variable clearing module, configured to: in response to a test end command, obtain a pre-configured variable modification program; clear the runtime variables of the non-volatile firmware interface to zero through the variable modification program to obtain updated fault address record data; and in response to a second memory fault event detected by the test program, perform a test operation on the second faulty memory based on the updated fault address record data.

[0125] The specific details of the virtual modules of the above memory testing devices have been described in detail in the corresponding memory testing methods. For any undisclosed details, please refer to the implementation methods in the method section, and therefore will not be repeated here.

[0126] It should be noted that although several modules or units of the memory testing apparatus have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0127] Exemplary embodiments of this disclosure also provide a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the memory testing method described above.

[0128] In one implementation, the computer program product may be a tangible product containing a computer program, such as a computer-readable storage medium storing the computer program. (See reference...) Figure 5 , Figure 5The illustration schematically depicts a computer-readable storage medium according to an exemplary embodiment of the present disclosure. The computer-readable storage medium 500 can be a storage medium based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, including but not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. Exemplarily, a computer program product can be implemented as a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0129] In one implementation, the computer program product can be an intangible product containing a computer program. For example, the computer program product can be implemented as a virtual digital product, such as an executable file, installation package, or other digital file storing the computer program.

[0130] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0131] Computer programs can be carried or transmitted via signals such as electricity, magnetism, light, electromagnetic fields, and infrared radiation. Electronic devices can convert the signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, to execute) the method steps of various exemplary embodiments of this disclosure, such as the memory testing method described above.

[0132] Exemplary embodiments of this disclosure also provide an electronic device, which may include a processor and a memory. The memory stores executable instructions of the processor, such as a computer program. The processor executes the executable instructions to perform the method steps of various exemplary embodiments of this disclosure. Furthermore, the electronic device may also include a display for displaying a graphical user interface.

[0133] The following is for reference. Figure 6 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 6The electronic device 600 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0134] like Figure 6 As shown, the electronic device 600 may include: a processor 610, a memory 620, a bus 630, an I / O (input / output) interface 640, a network adapter 650, and a display 660.

[0135] Memory 620 may include volatile memory, such as RAM 621 and cache unit 622, and may also include non-volatile memory, such as ROM 623. Memory 620 may also include one or more program modules 624, such program modules 624 including, but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 624 may include the modules in the above-described device.

[0136] The processor 610 may include one or more processing units, such as an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor, and / or an NPU (Neural-Network Processing Unit).

[0137] The processor 610 can be used to execute executable instructions stored in the memory 620, such as the memory test method described above.

[0138] Bus 630 is used to connect different components of electronic device 600 and may include a data bus, an address bus and a control bus.

[0139] Electronic device 600 can communicate with one or more external devices 700 (such as keyboard, mouse, external controller, etc.) through I / O interface 640.

[0140] Electronic device 600 can communicate with one or more networks via network adapter 650. For example, network adapter 650 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 650 can communicate with other modules of electronic device 600 via bus 630.

[0141] Electronic device 600 can display a graphical user interface via display 660, such as a display interface showing memory test results.

[0142] although Figure 6 Other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, may also be configured in the electronic device 600.

[0143] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0144] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. A memory testing method, characterized in that, include: Based on the first memory failure event detected by the test program, determine the fault address location information of the first faulty memory; The fault address location information is written to a non-volatile storage area during system operation to obtain fault address record data; In response to a system restart operation, the firmware determines the fault address location information based on the fault address record data obtained from the non-volatile storage area. Based on the fault address location information, the status modification operation is performed on the fault entry in the first fault memory to obtain the fault masking physical address. Based on the fault-masking physical address, a test operation is performed on the first faulty memory to obtain the memory test results.

2. The method according to claim 1, characterized in that, The determination of the fault address location information of the first faulty memory based on the first memory fault event detected by the test program includes: In response to the first memory failure event, determine the physical address of the failure corresponding to the first faulty memory; The faulty physical address is decoded using an address decoding library to obtain the faulty address location information, which is a quadruple constructed from the processor socket identifier, memory controller identifier, memory channel identifier, and memory socket identifier.

3. The method according to claim 1, characterized in that, The step of writing the fault address location information to a non-volatile storage area during system operation to obtain fault address record data includes: The test program writes the fault address location information into the sensor data record of the baseboard management controller through the first interface to obtain the fault address record data.

4. The method according to claim 3, characterized in that, In response to a system restart operation, the firmware determines the fault address location information based on the fault address record data obtained from the non-volatile storage area, including: In response to the system restart operation, the power-on self-test operation of the basic input / output system firmware is initiated; Before the memory controller initialization operation, the basic input / output system queries the sensor data records; The fault location information is obtained by the parsing module in the basic input / output system, which reads the sensor status byte and reading field based on the sensor data record.

5. The method according to claim 1, characterized in that, The step of modifying the status of fault entries in the first fault memory based on the fault address location information to obtain the fault masking physical address includes: The fault address location information is parsed to obtain the fault address quadruple; Obtain a pre-configured memory configuration structure array, the memory configuration structure array including status flag bits; The fault entry corresponding to the fault address quadruple is determined based on the status flag bit, and the fault entry is a memory entry whose status flag bit is a fault flag; Obtain the initial state corresponding to the fault entry, modify the initial state to the specified state through the state modification operation, and obtain the fault masking physical address.

6. The method according to claim 1, characterized in that, The step of writing the fault address location information to a non-volatile storage area during system operation to obtain fault address record data further includes: The test program serializes the fault address location information through the second interface to obtain the serialized fault address location information. The serialized fault address location information is written into the non-volatile firmware interface runtime variable of the unified extensible firmware interface to obtain the fault address record data.

7. The method according to claim 6, characterized in that, In response to a system restart operation, the firmware determines the fault address location information based on the fault address record data obtained from the non-volatile storage area, including: In response to the system restart operation, a memory controller initialization operation is performed; During the driver execution environment phase of the unified extensible firmware interface, the execution environment driver is loaded; The execution environment driver obtains the fault address record data from the runtime variables of the non-volatile firmware interface through a variable acquisition function to obtain the fault address location information.

8. The method according to claim 1, characterized in that, The step of modifying the status of fault entries in the first fault memory based on the fault address location information to obtain the fault masking physical address includes: The execution environment driver performs a parsing operation on the fault address location information to obtain a fault address information list, which includes the fault entries. The execution environment driver performs a status modification operation on the fault entry to obtain the fault masking physical address.

9. The method according to claim 8, characterized in that, The step of modifying the status of the fault entry by the execution environment driver to obtain the fault masking physical address includes: The execution environment driver performs a status modification operation on the fault entry through a memory configuration protocol to obtain the fault masking physical address.

10. The method according to claim 8, characterized in that, The step of modifying the status of the fault entry by the execution environment driver to obtain the fault masking physical address includes: The execution environment driver performs a status modification operation on the fault entry through a memory reference code library function to obtain the physical address of the fault mask.

11. The method according to claim 1, characterized in that, The step of testing the first faulty memory based on the fault-masking physical address to obtain memory test results includes: Memory training and initialization operations are performed based on the fault-masking physical address; By adjusting the physical address mapping to mask the address location information of the fault entry, a target test address is obtained. The target test address is the remaining address in the memory address of the first fault memory after removing the fault address corresponding to the fault entry. The first faulty memory is tested based on the target test address to obtain the memory test results.

12. The method according to claim 11, characterized in that, The step of performing a test operation on the first faulty memory based on the target test address to obtain memory test results includes: The test program generates a test vector for the target test address; The test program performs a test operation on the first faulty memory based on the test vector to obtain the memory test result.

13. The method according to any one of claims 1 to 5, 11 to 12, characterized in that, The method further includes: In response to the test end command, the baseboard management controller clears the fault flag bit in the fault address record data to obtain updated fault address record data; In response to a second memory fault event detected by the test program, a test operation is performed on the second faulty memory based on the updated fault address record data.

14. The method according to any one of claims 1 to 2, 6 to 12, characterized in that, The method further includes: In response to the test end command, retrieve the pre-configured variable modification procedure; The variable modification program clears the runtime variables of the non-volatile firmware interface to zero, thereby obtaining updated fault address record data; In response to a second memory fault event detected by the test program, a test operation is performed on the second faulty memory based on the updated fault address record data.

15. A memory testing device, characterized in that, include: The fault information determination module is used to determine the fault address location information of the first faulty memory based on the first memory fault event detected by the test program. The fault information recording module is used to write the fault address location information into a non-volatile storage area during system operation to obtain fault address recording data; The fault information reading module is used to determine the fault address location information by the firmware side based on the fault address record data obtained from the non-volatile storage area in response to the system restart operation. The fault status modification module is used to perform status modification operations on the fault entries in the first fault memory based on the fault address location information, so as to obtain the fault masking physical address. The memory testing module is used to perform test operations on the first faulty memory based on the fault-masking physical address and obtain memory test results.

Images