Firmware debugging method and device, equipment and medium

Abstract

The invention provides a firmware debugging method, device, equipment and medium, which are applied to the technical field of firmware debugge.The firmware debugging method comprises the steps that a first nonvolatile memory fast interface message is constructed through a configuration management tool running on a simulation host and sent to simulation nonvolatile memory fast interface equipment, and the first nonvolatile memory fast interface message is sent to the simulation nonvolatile memory fast interface equipment; converting the first nonvolatile memory fast interface message into a user-defined format message through the simulated nonvolatile memory fast interface equipment, and sending the user-defined format message to nonvolatile memory fast interface firmware through a preset communication protocol, so that the firmware executes a corresponding firmware debugging command to obtain an execution result; and obtaining a result message returned by the firmware through the simulation nonvolatile memory fast interface equipment, and returning the result message to the configuration management tool so as to verify an execution result. The fast interface firmware of the nonvolatile memory can be debugged without actual hardware, so that the debugging cost is reduced, and the influence on the development efficiency is avoided.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware debugging, and particularly to a firmware debugging method, device, equipment and medium. Background Art

[0002] The development of non-volatile memory fast interface firmware is relatively complex, and a large amount of debugging and verification is required during the development process to ensure its performance and stability. However, in the early stage of firmware development, the hardware device is often not yet manufactured, which causes developers to be unable to conduct functional verification and performance testing in a real hardware environment. And existing testing tools usually rely on actual hardware to simulate the interaction between the host and the firmware, which is not only costly but also time-consuming, limiting the flexibility and efficiency of the development cycle.

[0003] Therefore, how to ensure the debugging of non-volatile memory fast interface firmware without actual hardware, reduce the debugging cost, and avoid affecting the development efficiency is a problem that those skilled in the art need to solve. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a firmware debugging method, device, equipment and medium, which can ensure the debugging of non-volatile memory fast interface firmware without actual hardware, reduce the debugging cost, and avoid affecting the development efficiency. The specific solutions are as follows:

[0005] In the first aspect, the present invention provides a firmware debugging method, including:

[0006] Construct a first non-volatile memory fast interface message through a configuration management tool running on a simulated host, and send the first non-volatile memory fast interface message to a simulated non-volatile memory fast interface device, wherein the simulated host and the simulated non-volatile memory fast interface device are both simulated based on a fast simulator;

[0007] Through the simulated non-volatile memory fast interface device, convert the first non-volatile memory fast interface message into a custom format message, and send the custom format message to the non-volatile memory fast interface firmware through a preset communication protocol, so that the non-volatile memory fast interface firmware executes the firmware debugging command corresponding to the custom format message to obtain an execution result;

[0008] Obtain, through the simulated non-volatile memory fast interface device, a result message corresponding to the execution result returned by the non-volatile memory fast interface firmware based on the preset communication protocol, and return the result message to the configuration management tool, so that the management configuration tool can verify the execution result.

[0009] Optionally, converting the first non-volatile memory fast interface message into a custom format message includes:

[0010] Parsing the submission queue entry in the first non-volatile memory fast interface message, and if the target data is indicated in the submission queue entry, adding the target data to the tail of the submission queue entry as the first data payload to obtain a custom format message;

[0011] wherein the target data is management data or write data.

[0012] Optionally, adding the target data to the tail of the submission queue entry as the first data payload to obtain a custom format message includes:

[0013] Adding the target data to the tail of the submission queue entry as the first data payload, calculating the check value of the target data to obtain a first check value, and adding the first check value after the first data payload to obtain a custom format message, so that after the non-volatile memory fast interface firmware passes the check of the first data payload based on the first check value, it executes the firmware debug command corresponding to the custom format message.

[0014] Optionally, returning the result message to the configuration management tool includes:

[0015] Converting the result message into a second non-volatile memory fast interface message;

[0016] Returning the second non-volatile memory fast interface message to the configuration management tool.

[0017] Optionally, converting the result message into a second non-volatile memory fast interface message includes:

[0018] Extracting the completion queue entry from the result message;

[0019] If the field value of the specified field in the completion queue entry is 0, taking the completion queue entry as the second non-volatile memory fast interface message; wherein, the specified field represents the length of the second data payload in the result message.

[0020] If the field value of the specified field in the completion queue entry is not 0, writing the second data payload in the result message into the physically continuous memory area of the virtual host, and taking the completion queue entry as the second non-volatile memory fast interface message.

[0021] Optionally, writing the second data payload in the result message into the physically continuous memory area of the virtual host, and taking the completion queue entry as the second non-volatile memory fast interface message includes:

[0022] Extract a second check value from the result message;

[0023] Verify the second data payload using the second check value;

[0024] If the second data payload passes the verification, write the second data payload in the result message to the physically contiguous memory area of the virtual host, and use the completion queue entry as a second non-volatile memory express message.

[0025] Optionally, it further includes:

[0026] If the second data payload fails the verification, write the corresponding error code to the target field of the completion queue entry, and use the completion queue entry after writing the error code as a second non-volatile memory express message.

[0027] In a second aspect, the present invention discloses a firmware debugging device, including:

[0028] A configuration management tool, configured to construct a first non-volatile memory express message and send the first non-volatile memory express message to an emulated non-volatile memory express device, wherein the configuration management tool runs on an emulated host, and both the emulated host and the emulated non-volatile memory express device are emulated based on a fast simulator;

[0029] The emulated non-volatile memory express device is configured to convert the first non-volatile memory express message into a custom format message and send the custom format message to the non-volatile memory express firmware through a preset communication protocol, so that the non-volatile memory express firmware executes the firmware debugging command corresponding to the custom format message to obtain an execution result;

[0030] And, the emulated non-volatile memory express device is further configured to: obtain the result message corresponding to the execution result returned by the non-volatile memory express firmware based on the preset communication protocol, and return the result message to the configuration management tool for the management configuration tool to verify the execution result.

[0031] In a third aspect, the present invention discloses a firmware debugging device, including:

[0032] A memory, configured to store a computer program;

[0033] A processor, configured to execute the computer program to implement the steps of the foregoing firmware debugging method.

[0034] Fourthly, the present invention discloses a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the foregoing firmware debugging method are implemented.

[0035] Fifthly, the present invention provides a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the foregoing disclosed firmware debugging method are implemented.

[0036] As can be seen from the above solutions, the present invention provides a firmware debugging method, including: constructing a first Non-Volatile Memory Express (NVMe) message through a configuration management tool running on a simulation host, and sending the first NVMe message to a simulated NVMe device, wherein the simulation host and the simulated NVMe device are both simulated based on a fast simulator; converting, by the simulated NVMe device, the first NVMe message into a custom format message, and sending the custom format message to the NVMe firmware through a preset communication protocol, so that the NVMe firmware executes a firmware debugging command corresponding to the custom format message to obtain an execution result; obtaining, by the simulated NVMe device, a result message corresponding to the execution result returned by the NVMe firmware based on the preset communication protocol, and returning the result message to the configuration management tool, so that the configuration management tool verifies the execution result.

[0037] It can be seen that the beneficial effects of the present invention are as follows: based on simulation by a fast simulator, a simulation host and the simulated NVMe device are obtained. A configuration management tool runs on the simulation host. The configuration management tool constructs a first NVMe message and sends it to the simulated NVMe device. The simulated NVMe device converts it into a custom format message and sends it to the NVMe firmware through a preset communication protocol, so that the NVMe firmware executes a corresponding firmware debugging command to obtain an execution result. The simulated NVMe device then returns the corresponding result message to the configuration management tool, so that the configuration management tool verifies the execution result. In this way, through the simulation host and the simulated NVMe device, and by implementing the corresponding message conversion and sending / receiving logic, firmware debugging is performed, which can ensure that the NVMe firmware is debugged without actual hardware, reduce the debugging cost, and avoid affecting the development efficiency.

[0038] Accordingly, a firmware debugging device, equipment and medium provided by the present invention also have the above technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present invention, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0040] Figure 1 A flowchart of a firmware debugging method provided by an embodiment of the present invention;

[0041] Figure 2 A schematic diagram of firmware debugging provided by an embodiment of the present invention;

[0042] Figure 3 A schematic diagram of the transmission message format corresponding to an NVMe query / read data command provided by an embodiment of the present invention;

[0043] Figure 4 A schematic diagram of the received message format corresponding to an NVMe query / read data command provided by an embodiment of the present invention;

[0044] Figure 5 A schematic diagram of the transmission message format corresponding to an NVMe management / write data command provided by an embodiment of the present invention;

[0045] Figure 6 A schematic diagram of the received message format corresponding to an NVMe management / write data command provided by an embodiment of the present invention;

[0046] Figure 7 A schematic diagram of the structure of a firmware debugging device provided by an embodiment of the present invention;

[0047] Figure 8 A structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0048] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0049] The terms "including" and "having" in the specification of the present invention and the above-mentioned drawings, as well as any variations related to "including" and "having", are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may include steps or units not listed.

[0050] With the continuous growth of data center and high-performance computing requirements, due to its high bandwidth and low latency characteristics, NVMe technology has become the mainstream interface standard for storage devices. NVMe firmware is responsible for managing communication with the host and supports various host configuration functions, such as command queuing, data transfer, and error handling. However, the development and verification process of firmware faces some challenges, especially when the hardware is not yet ready. Complexity of firmware development: NVMe firmware needs to support multiple host protocols and configuration options, and a large amount of debugging and verification is required during the development process to ensure its performance and stability. The design of the firmware not only needs to consider the compatibility of various hardware environments, but also ensure that the firmware can handle different types of host requests. Lack of hardware verification environment: In the early stage of firmware development, hardware devices are often not yet manufactured, which causes developers to be unable to conduct functional verification and performance testing in a real hardware environment. Limitations of testing tools: Existing testing tools usually rely on actual hardware to simulate the interaction between the host and the firmware. This method is not only costly but also time-consuming, limiting the flexibility and efficiency of the development cycle. Requirements for reliability and performance: With the continuous evolution of NVMe technology, the requirements for the reliability and performance of the firmware are also increasing. Developers need an effective solution to ensure the stability and compatibility of the firmware under different host configurations and quickly respond to market demands.

[0051] Therefore, the present invention provides a firmware debugging method, device, equipment, and medium, which can ensure the debugging of non-volatile memory express firmware without actual hardware, reduce the debugging cost, and avoid affecting the development efficiency.

[0052] First, the terms related to the present invention are explained:

[0053] NVMe (i.e., Non-Volatile Memory Express, non-volatile memory express interface): A high-performance, low-latency storage interface protocol designed specifically for solid-state drives (SSDs) to fully utilize the advantages of flash storage. NVMe is connected through the PCIe (i.e., Peripheral Component Interconnect Express, high-speed serial computer expansion bus standard) bus, supports multiple command queues and parallel processing, and improves data transfer speed.

[0054] Firmware: A software program embedded in a hardware device that is responsible for controlling and managing hardware operations. Firmware is usually stored in non-volatile memory and can improve device functionality or fix vulnerabilities after being updated.

[0055] QEMU (Quick EMUlator): An open-source virtual machine monitor that can simulate multiple hardware platforms and devices. QEMU supports virtualization of multiple operating systems and can simulate various hardware platforms and devices. By using QEMU for device emulation, a flexible test environment can be created without real hardware. The verification of firmware can be effectively achieved by converting NVMe messages into TCP message format.

[0056] TCP (Transmission Control Protocol): A connection-oriented and reliable transport layer protocol used to achieve reliable data transmission in a network. TCP ensures the order and integrity of data packets and is widely used in Internet communication.

[0057] Device emulation: Replicating the behavior and functions of a hardware device in a virtual environment through software means. Device emulation allows developers to conduct tests and verifications without actual hardware.

[0058] Host configuration tool: A software tool used to configure and manage the communication between a host and an NVMe device. The host configuration tool can debug and verify the functionality of firmware by sending commands and receiving feedback.

[0059] PRP (Physical Region Page): A physical memory address description mechanism defined in the NVMe protocol. When transferring data between a host and an NVMe controller, it is used to specify the physical memory location of the data buffer. Its core function is to directly locate the memory area through the physical address, ensuring the efficiency and security of DMA (Direct Memory Access) operations.

[0060] To enable those skilled in the art to better understand the solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0061] Next, a firmware debugging method provided by an embodiment of the present invention will be introduced in detail. Figure 1 The following is a flowchart of a firmware debugging method provided by an embodiment of the present invention. This firmware debugging method includes:

[0062] Step S11: Construct a first Non-Volatile Memory Express (NVMe) message through a configuration management tool running on a simulation host, and send the first NVMe message to a simulated NVMe device, where both the simulation host and the simulated NVMe device are simulated based on a fast simulator.

[0063] In an embodiment of the present invention, a first NVMe message can be constructed based on a command to be tested, including a query command, a management command, a read data command, and a write data command. The query command and the management command are control flow commands, and the read data command and the write data command are data flow commands. A field specifying a command type is included in the first NVMe message.

[0064] In an embodiment of the present invention, the first NVMe message is sent to a simulated NVMe device so that the simulated NVMe device interacts with the NVMe firmware, completing the interaction between the configuration management tool in the simulation host and the NVMe firmware.

[0065] Step S12: Through the simulated NVMe device, convert the first NVMe message into a custom format message, and send the custom format message to the NVMe firmware through a preset communication protocol, so that the NVMe firmware executes a firmware debugging command corresponding to the custom format message to obtain an execution result.

[0066] In an optional embodiment, the preset communication protocol can be the TCP protocol. That is, in an embodiment of the present invention, the first NVMe message can be converted into a custom format message to be sent through the TCP protocol.

[0067] In an optional embodiment, the submission queue entry in the first NVMe message can be parsed. If the submission queue entry indicates the existence of target data, the target data is added to the tail of the submission queue entry as the first data payload to obtain a custom format message; where the target data is management data or write data.

[0068] In the first non-volatile memory fast interface message, a PRP (Physical Region Page) field and a data length field are included. The PRP field is used to describe the physical addresses of the host memory buffer, and the controller directly accesses these addresses through DMA to transfer data. The data length field (Data Length) is used to specify the number of bytes of the data payload, and the controller transfers data of the specified length according to this value. Therefore, it is possible to indicate whether there is target data based on the PRP field and the data length field in the first non-volatile memory fast interface message. Among them, the target data is added to the tail of the submission queue entry as the first data payload, that is, the target data is added after the submission queue entry.

[0069] In an alternative embodiment, the target data can be added to the tail of the submission queue entry as the first data payload, and the check value of the target data is calculated to obtain a first check value. The first check value is added after the first data payload to obtain a custom format message, so that after the non-volatile memory fast interface firmware passes the verification of the first data payload based on the first check value, it executes the firmware debug command corresponding to the custom format message.

[0070] That is to say, in the embodiments of the present invention, a check value can be added to the transmitted message to ensure the reliability of message transmission. In addition, in the embodiments of the present invention, after the non-volatile memory fast interface firmware passes the verification of the first data payload based on the first check value, the custom format message is converted into a non-volatile memory fast interface message, and the corresponding firmware debug command is executed based on the non-volatile memory fast interface message.

[0071] Step S13: Obtain the result message corresponding to the execution result returned by the non-volatile memory fast interface firmware based on the preset communication protocol through the simulated non-volatile memory fast interface device, and return the result message to the configuration management tool so that the management configuration tool can verify the execution result.

[0072] In an alternative embodiment, returning the result message to the configuration management tool includes: converting the result message into a second non-volatile memory fast interface message; returning the second non-volatile memory fast interface message to the configuration management tool.

[0073] In an alternative embodiment, converting the result message into a second Non-Volatile Memory Express (NVMe) message includes: extracting a completion queue entry from the result message; if the field value of a specified field in the completion queue entry is 0, using the completion queue entry as the second NVMe message; wherein the specified field represents the length of a second data payload in the result message. If the field value of the specified field in the completion queue entry is not 0, writing the second data payload in the result message into a physically contiguous memory area of the virtual host, and using the completion queue entry as the second NVMe message.

[0074] Among them, the return messages of the management command and the write data command do not contain data, so the specified field is 0, and the physically contiguous memory area is the area described by the PRP field.

[0075] In an alternative embodiment, writing the second data payload in the result message into a physically contiguous memory area of the virtual host, and using the completion queue entry as the second NVMe message may include: extracting a second check value from the result message; using the second check value to verify the second data payload; if the second data payload passes the verification, writing the second data payload in the result message into a physically contiguous memory area of the virtual host, and using the completion queue entry as the second NVMe message. If the second data payload fails the verification, writing a corresponding error code into a target field of the completion queue entry, and using the completion queue entry after writing the error code as the second NVMe message. The error code may reuse the field for transmitting errors in the completion queue entry.

[0076] Among them, the second check value may be a check value calculated by the NVMe firmware based on the second data payload. The verification process may be to calculate a check value based on the second data payload, compare the calculated check value with the second check value carried in the message, if they are the same, it is determined that the verification passes, if they are different, it is determined that the verification fails.

[0077] Moreover, in an alternative embodiment, a completion queue entry may be extracted from the result message; if the field value of a specified field in the completion queue entry is 0, the completion queue entry is used as a second non-volatile memory express message; wherein, the specified field characterizes the length of a second data payload in the result message. If the field value of the specified field in the completion queue entry is not 0, the second data payload and a second check value are read, and it is determined whether the lengths of the second data payload and the second check value are correct based on the field value of the specified field in the completion queue entry. When the lengths of the second data payload and the second check value are correct, the second check value is extracted from the result message; the second data payload is verified using the second check value; if the second data payload passes the verification, the second data payload in the result message is written into a physically contiguous memory area of the virtual host, and the completion queue entry is used as a second non-volatile memory express message.

[0078] In an alternative embodiment, the verification of the execution result by the management configuration tool may include: for query commands and management commands, determining the correctness and reliability based on a comparison between the second non-volatile memory express message and the expected result. For data read and write commands, after obtaining the second non-volatile memory express message corresponding to the data write command, a data read command is issued to read out the written data corresponding to the write command, and the read written data is compared with the original written data to complete the verification. That is, through a write-then-read scheme, the data written by the host is compared with the data read from the corresponding location to ensure the correctness of the read and written data. Additionally, for a data read command, the second non-volatile memory express message of the data read command may be obtained, the check value of the read data is obtained through a query command, and the read data is verified based on the check value. In an alternative embodiment, the check value may be saved after being verified by an emulated non-volatile memory express device for the read data.

[0079] It can be seen that, based on the simulation of the fast simulator in the embodiments of the present invention, a simulation host and the simulated non-volatile memory express interface device are obtained. A configuration management tool is run in the simulation host, and a first non-volatile memory express interface message is constructed by the configuration management tool and sent to the simulated non-volatile memory express interface device. The simulated non-volatile memory express interface device converts it into a custom format message and sends it to the non-volatile memory express interface firmware through a preset communication protocol, so that the non-volatile memory express interface firmware executes the corresponding firmware debugging command to obtain an execution result. The simulated non-volatile memory express interface device then returns the corresponding result message to the configuration management tool, so that the management configuration tool can verify the execution result. In this way, through the simulation host and the simulated non-volatile memory express interface device, and by implementing the corresponding message conversion and sending / receiving logic, firmware debugging can be carried out, which can ensure the debugging of the non-volatile memory express interface firmware without actual hardware, reduce the debugging cost, and avoid affecting the development efficiency.

[0080] Further, as shown in Figure 2 the embodiments of the present invention provide a schematic diagram of firmware debugging. Using the device simulation technology in QEMU, when the virtual NVMe device receives an NVMe message in QEMU, it converts it into a custom message format and sends it to the NVMe firmware through the TCP protocol. After receiving the message, the NVMe firmware executes the corresponding command and converts the result into a TCP message and returns it to the configuration management software. In the embodiments of the present invention, a module for converting TCP messages and NVMe messages is added to the original firmware to support running on any hardware platform that supports TCP messages. Based on the QEMU simulation host, a simulation host is obtained, that is, Figure 2 the Guest OS in it. The simulated NVMe device includes QEMU NVMe device simulation, an NVMe message and TCP message conversion module, and a TCP message sending and receiving module. The simulation host and the simulated NVMe device act as clients. The QEMU NVMe device simulation, an NVMe message and TCP message conversion module are added to the NVMe firmware, acting as the server. Both run on the host system of the hardware platform.

[0081] The definition of the TCP message format includes control messages and data messages. The control messages are divided into query messages and management messages, that is, the messages corresponding to query commands and management commands, mainly for managing the configuration information of the NVMe device; the data messages are divided into read data and write data messages. That is, the messages corresponding to data read commands and data write commands. The design of its message format is as follows:

[0082] Message corresponding to the NVMe query / read data command: The format of the transmitted message, i.e., SQE (Submission Queue Entry), maintains the original format of the NVMe command and is fully compatible with all fields defined in the NVMe specification. Avoid disassembling the SQE into different fields to simplify the implementation logic between the host and the device. As Figure 3 shown, Figure 3 Figure 180 is a schematic diagram of the format of the transmitted message corresponding to the NVMe query / read data command provided by an embodiment of the present invention. The format of the received message consists of a CQE (Completion Queue Entry) message + data payload + CRC32. Among them, the CQE maintains the original format of the NVMe command; the data payload is the data packet returned by the NVMe device for querying or reading data, and the length of the data payload is specified by CQE DWORD0. CRC32 calculates the check value for the data payload to ensure end-to-end data integrity. As Figure 4 shown, Figure 4 Figure 182 is a schematic diagram of the format of the received message corresponding to the NVMe query / read data command provided by an embodiment of the present invention.

[0083] Message corresponding to the NVMe administrative / write data command: The format of the transmitted message consists of an SQE message + data payload + CRC32. Among them, the SQE maintains the original format of the NVMe command; the data payload is the data sent to the NVMe device, including administrative data and write data, and the length of the data payload is specified by SQE DWORD10. CRC32 calculates the check value for the data payload to ensure end-to-end integrity. As Figure 5 shown, Figure 5 Figure 186 is a schematic diagram of the format of the transmitted message corresponding to the NVMe administrative / write data command provided by an embodiment of the present invention. The format of the received message is the same as the NVMe CQE message format. As Figure 6 shown, Figure 6 Figure 188 is a schematic diagram of the format of the received message corresponding to the NVMe administrative / write data command provided by an embodiment of the present invention.

[0084] Furthermore, the firmware debugging solution provided by the embodiments of the present invention may include the following steps:

[0085] Step 1: Environment preparation. Modify the implementation code of the NVMe device in QEMU to add a message conversion and message sending / receiving module. After adding, compile a new QEMU executable file. Modify the firmware code, add a message conversion and message sending / receiving module, and compile the new firmware.

[0086] Step 2: Start the QEMU simulation environment and run the QEMU instance. Start the QEMU instance using the command line, ensuring that the appropriate virtual hardware configuration is specified. For example, when using QEMU to simulate an x86 host environment, that is, running the qemu-system-x86_64 process of QEMU, ensure that the parameters -device nvme and -device nvme-ns are carried. This ensures that after the QEMU instance starts, it can correctly load the modified NVMe device program and can receive NVMe messages sent by the host, and run the virtual host and virtual NVMe device based on the QEMU instance.

[0087] Step 3: Prepare the host configuration management tool and configure the configuration management tool to connect it to the QEMU-simulated NVMe device, ensuring that NVMe messages can be correctly sent and received.

[0088] Step 4: The host tool constructs an NVMe message and sends the constructed NVMe message to the QEMU-simulated NVMe device.

[0089] Step 5: After the QEMU-simulated NVMe device receives the NVMe message from the host, it calls the TCP message conversion module. This module converts the received NVMe message into the TCP message format. The converted TCP message is sent to the firmware. The conversion process is as follows: 1) Parse the SQE sent by the host. If it carries data, append it to the end of the SQE, calculate the CRC32 value for the payload data, and append its CRC32 to the data payload to form a TCP data packet. 2) Send the organized TCP data packet to the firmware through the TCP message sending interface.

[0090] Step 6: The firmware receives the TCP message. According to the received message, the message conversion module converts the TCP message into an NVMe message. The firmware parses and executes the corresponding NVMe command (such as a read or write operation by the configuration management machine) and prepares to return the result.

[0091] Step 7: After the firmware completes the operation, it constructs the execution result into the TCP message format. The result message is sent back to the QEMU-simulated NVMe device through the TCP interface.

[0092] Step 8: The NVMe device simulated by QEMU receives the TCP message sent by the firmware. The conversion module is called to convert the TCP message into the NVMe message format and verify the integrity of the message. After the verification passes, the converted NVMe message is sent back to the host configuration management tool. The process of message reception, parsing, and verification is as follows: 1) Read 16 bytes of CQE from the TCP Socket. Obtain the length of the payload data carried in the message through DWORD0 in the CQE. 2) If the length of the payload data is 0, directly return the CQE to the host configuration management tool. 3) If the length of the payload data is not 0, read the payload data + CRC32. The length read is: the data length information carried by DWORD0 in the CQE + 4 bytes. Verify the integrity of the payload data through the CRC32 value. After the verification is successful, copy the payload data to the PRP carried in the SQE. Return the CQE message to the host tool. If the verification fails, refill the failed return code in the CQE and return it to the host configuration management tool. PRP is a field (or a list of PRPs) in the SQE that describes the physically contiguous memory regions in the host memory, and the controller can directly read and write these regions through DMA (Direct Memory Access).

[0093] Step 9: The host tool receives the responded NVMe CQE message. For query and management commands, the host configuration management tool compares the CQE return result with the expected result to determine the correctness and reliability. For data read and write commands, through the write-then-read scheme, compare the data written by the host with the data read from the corresponding location to ensure the correctness of the read and written data.

[0094] It can be seen that the present invention provides a solution for joint debugging of NVMe firmware and configuration management tools in the development stage. Through device simulation technology, the reliability verification of the firmware is realized, eliminating the dependence on the real hardware environment. Use QEMU to simulate the NVMe device and perform the conversion between NVMe messages and TCP messages. Design a TCP message and NVMe message conversion module, that is, a dynamic message conversion module implemented in QEMU, including its functions, interface definitions, and interaction methods with the firmware. The TCP communication interface is integrated in the NVMe firmware, involving the design of the firmware to implement the functions of receiving and sending TCP messages, ensuring that the firmware can process the TCP messages from QEMU and return results. And provide a device simulation system based on QEMU and its applications, involving the usage method of QEMU as a device simulation platform, specifically including how to configure and run the virtual NVMe device to support the technical solutions for firmware testing and verification.

[0095] That is, the embodiments of the present invention may include: NVMe device simulation based on QEMU: By utilizing the device simulation function of QEMU, a flexible test environment is provided, enabling the verification of the interaction between NVMe firmware and host tools without actual hardware. Integration of the TCP message conversion module: A dynamic conversion module between NVMe messages and TCP messages is implemented in QEMU, allowing the firmware to correctly process the received TCP messages and return the results as NVMe messages. This modular design enhances the flexibility and maintainability of the system. Hardware-independent verification method: A firmware verification method that does not rely on actual hardware is provided, solving the problem of the lack of a test environment in the initial stage of firmware development and effectively improving the development efficiency and product market launch speed.

[0096] Thus, the beneficial effects of the embodiments of the present invention are as follows: Hardware-independent: Firmware verification can still be effectively carried out without real hardware. High flexibility: The NVMe firmware can run on any hardware platform that supports TCP messages. Improved development efficiency: Shorten the firmware development and testing cycles and accelerate the product market launch process. Enhanced reliability verification: Provide comprehensive functional verification and enhance the reliability of the firmware. That is, the embodiments of the present invention propose a co-debugging method based on QEMU device simulation and TCP message transmission for the challenges and requirements in the NVMe firmware development process, providing a new solution for the effective verification of the firmware and host tools. This method not only overcomes the problem of the lack of a hardware environment but also improves the efficiency and reliability of firmware development, having important application prospects and market value.

[0097] See Figure 7 As shown, the embodiments of the present invention provide a firmware debugging device, including:

[0098] A configuration management tool 71, configured to construct a first Non-Volatile Memory Express (NVMe) message and send the first NVMe message to an emulated NVMe device, wherein the configuration management tool runs on an emulated host, and both the emulated host and the emulated NVMe device are emulated based on a fast simulator;

[0099] An emulated NVMe device 72, configured to convert the first NVMe message into a custom format message and send the custom format message to the NVMe firmware through a preset communication protocol, so that the NVMe firmware executes the firmware debugging command corresponding to the custom format message and obtains an execution result;

[0100] Moreover, the simulated non-volatile memory express interface device 72 is further configured to: obtain the result message corresponding to the execution result returned by the non-volatile memory express interface firmware based on the preset communication protocol, and return the result message to the configuration management tool 71, so that the configuration management tool can verify the execution result.

[0101] Wherein, the simulated non-volatile memory express interface device 72 includes a message conversion module that converts the first non-volatile memory express interface message into a custom format message. In a specific embodiment, it can be used for:

[0102] Parse the submission queue entry in the first non-volatile memory express interface message. If the submission queue entry indicates the existence of target data, add the target data to the tail of the submission queue entry as the first data payload to obtain a custom format message; wherein, the target data is management data or write data.

[0103] In an alternative embodiment, the message conversion module is specifically configured to:

[0104] Add the target data to the tail of the submission queue entry as the first data payload, calculate the check value of the target data to obtain a first check value, and add the first check value after the first data payload to obtain a custom format message, so that the non-volatile memory express interface firmware can execute the firmware debug command corresponding to the custom format message after passing the verification of the first data payload based on the first check value.

[0105] The message conversion module is further configured to: convert the result message into a second non-volatile memory express interface message; and return the second non-volatile memory express interface message to the configuration management tool.

[0106] In an alternative embodiment, the message conversion module is specifically configured to extract the completion queue entry from the result message; if the field value of the specified field in the completion queue entry is 0, use the completion queue entry as the second non-volatile memory express interface message; wherein, the specified field represents the length of the second data payload in the result message; if the field value of the specified field in the completion queue entry is not 0, write the second data payload in the result message into the physically contiguous memory area of the virtual host, and use the completion queue entry as the second non-volatile memory express interface message.

[0107] In an alternative embodiment, the message conversion module is specifically configured to extract a second check value from the result message; use the second check value to check the second data payload; if the second data payload passes the check, write the second data payload in the result message into the physically contiguous memory area of the virtual host, and use the completion queue entry as a second non-volatile memory express message. If the second data payload fails the check, write the corresponding error code into the target field of the completion queue entry, and use the completion queue entry after writing the error code as a second non-volatile memory express message.

[0108] It can be seen that the embodiment of the present invention is based on simulation by a fast simulator to obtain a simulation host and the simulated non-volatile memory express device. A configuration management tool is run in the simulation host. The configuration management tool constructs a first non-volatile memory express message and sends it to the simulated non-volatile memory express device. The simulated non-volatile memory express device converts it into a custom format message and sends it to the non-volatile memory express firmware through a preset communication protocol, so that the non-volatile memory express firmware executes the corresponding firmware debugging command to obtain an execution result. The simulated non-volatile memory express device then returns the corresponding result message to the configuration management tool so that the configuration management tool can verify the execution result. In this way, through the simulation host and the simulated non-volatile memory express device, and implementing the corresponding message conversion and sending / receiving logic for firmware debugging, it is possible to ensure that the non-volatile memory express firmware can be debugged without actual hardware, reduce the debugging cost, and avoid affecting the development efficiency.

[0109] Figure 7 For the description of the features in the corresponding embodiments, reference can be made to Figure 1 the relevant descriptions of the corresponding embodiments, which will not be elaborated here one by one.

[0110] Figure 8 The following is a structural diagram of an electronic device provided by an embodiment of the present invention. As Figure 8 shown, the electronic device includes: a memory 80 for storing a computer program;

[0111] a processor 81 for implementing the steps of the firmware debugging method in the above embodiment when executing the computer program.

[0112] Among them, the processor 81 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 81 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 81 may also include a main processor and a coprocessor. The main processor is a processor used to process data in the wake state, also known as the central processing unit (CPU); the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 81 may be integrated with a graphics processing unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 81 may further include an artificial intelligence (AI) processor, and the AI processor is used to process computational operations related to machine learning.

[0113] The memory 80 may include one or more computer-readable storage media, and the computer-readable storage media may be non-transitory. The memory 80 may further include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash storage devices. In this embodiment, the memory 80 is at least used to store the following computer program 801. After the computer program is loaded and executed by the processor 81, it can implement the relevant steps of the firmware debugging method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 80 may further include an operating system 802 and data 803, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 802 may include Windows, Unix, Linux, etc. The data 803 may include, but is not limited to, debugging data, etc.

[0114] In some embodiments, the electronic device may further include a display screen 82, an input / output interface 83, a communication interface 84, a power supply 85, and a communication bus 86.

[0115] Those skilled in the art can understand that Figure 8 the structure shown in

[0116] It can be understood that if the firmware debugging method in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, etc., all of which can store program codes.

[0117] Based on this, the embodiments of the present invention further provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the steps of the firmware debugging method as described above.

[0118] Next, a computer program product provided by the embodiments of the present invention will be introduced. The computer program product described below can be cross-referred to other embodiments described in this article.

[0119] A computer program product includes computer programs / instructions. When the computer programs / instructions are executed by a processor, they implement the steps of the aforementioned disclosed firmware debugging method.

[0120] The above has introduced in detail a firmware debugging method, device, equipment, and medium provided by the embodiments of the present invention. The various embodiments in the specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts among the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple. For the relevant parts, refer to the description of the method part.

[0121] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this article can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0122] The above has introduced in detail a firmware debugging method, device, equipment and medium provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims

1. A firmware debugging method, characterized in that: include: Constructing a first non-volatile memory fast interface message through a configuration management tool running on a simulation host, and sending the first non-volatile memory fast interface message to a simulation non-volatile memory fast interface device, wherein the simulation host and the simulation non-volatile memory fast interface device are both based on fast simulator simulation; The first non-volatile memory fast interface message is converted into a custom format message by the simulated non-volatile memory fast interface device, and the custom format message is sent to the non-volatile memory fast interface firmware through a preset communication protocol, so that the non-volatile memory fast interface firmware executes the firmware debugging command corresponding to the custom format message to obtain an execution result; The result message corresponding to the execution result returned by the non-volatile memory fast interface firmware based on the preset communication protocol is obtained through the simulated non-volatile memory fast interface device, and the result message is returned to the configuration management tool so that the management configuration tool can verify the execution result.

2. The firmware debugging method according to claim 1, characterized in that: Converting the first non-volatile memory fast interface message into a custom format message includes: Parsing the submission queue item in the first non-volatile memory fast interface message, and if the submission queue item indicates that target data exists, adding the target data to the end of the submission queue item as a first data payload to obtain a custom format message; The target data is management data or write data.

3. The firmware debugging method according to claim 2, characterized in that: The target data is added to the end of the submission queue item as the first data payload to obtain a custom format message, including: The target data is added to the tail of the submission queue item as the first data payload, and a check value of the target data is calculated to obtain a first check value. After the first check value is added to the first data payload, a custom format message is obtained, so that the non-volatile memory fast interface firmware executes a firmware debugging command corresponding to the custom format message after the first data payload is verified based on the first check value.

4. The firmware debugging method according to any one of claims 1 to 3, characterized in that: Returning the result message to the configuration management tool includes: Converting the result message into a second non-volatile memory fast interface message; The second non-volatile memory fast interface message is returned to the configuration management tool.

5. The firmware debugging method according to claim 4, characterized in that: Converting the result message into a second non-volatile memory fast interface message comprises: Extracting a completion queue item from the result message; If the field value of the designated field in the completion queue item is 0, the completion queue item is used as a second non-volatile memory fast interface message; wherein the designated field represents the length of the second data load in the result message; If the field value of the designated field in the completion queue entry is not 0, the second data payload in the result message is written into the physical continuous memory area of ​​the virtual host, and the completion queue entry is used as a second non-volatile memory fast interface message.

6. The firmware debugging method according to claim 5, characterized in that: Writing the second data payload in the result message into the physical continuous memory area of ​​the virtual host and using the completion queue item as a second non-volatile memory fast interface message, including: Extracting a second check value from the result message; Verifying the second data payload using the second verification value; If the second data payload passes the verification, the second data payload in the result message is written into the physically continuous memory area of ​​the virtual host, and the completion queue entry is used as a second non-volatile memory fast interface message.

7. The firmware debugging method according to claim 6, characterized in that: Also includes: If the second data load fails the check, the corresponding error code is written into the target field of the completion queue item, and the completion queue item after the error code is written is used as the second non-volatile memory fast interface message.

8. A firmware debugging device, characterized in that: include: A configuration management tool, used for constructing a first non-volatile memory fast interface message, and sending the first non-volatile memory fast interface message to a simulated non-volatile memory fast interface device, wherein the configuration management tool runs on a simulated host, and the simulated host and the simulated non-volatile memory fast interface device are both simulated based on a fast simulator; The emulated non-volatile memory fast interface device is used to convert the first non-volatile memory fast interface message into a custom format message, and send the custom format message to the non-volatile memory fast interface firmware through a preset communication protocol, so that the non-volatile memory fast interface firmware executes the firmware debugging command corresponding to the custom format message to obtain an execution result; In addition, the simulated non-volatile memory fast interface device is also used to: obtain a result message corresponding to the execution result returned by the non-volatile memory fast interface firmware based on the preset communication protocol, and return the result message to the configuration management tool so that the management configuration tool can verify the execution result.

9. A firmware debugging device, characterized in that: include: Memory for storing computer programs; A processor, configured to execute the computer program to implement the steps of the firmware debugging method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the firmware debugging method according to any one of claims 1 to 7 are implemented.

Images