NVMe Device Controller Debugging Method, Device, Equipment, Medium and Product

Abstract

The present application discloses an NVMe device controller debugging method, device, equipment, medium and product, which relates to the field of storage technology and is applied to a target NVMe device controller. The method includes: enabling a controller memory buffer during initialization and setting attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through a bus, the controller memory buffer is mapped to the memory space of the target host to obtain a virtual mapping address in the memory space; obtaining a target operation command sent by the target host by accessing the virtual mapping address, and parsing the target operation command to obtain parsed data; the target operation command is a command for performing a JTAG debugging operation on the NVMe device controller; using a TAP state machine to convert the parsed data into JTAG signals, so as to access processor resources in a local system-on-chip based on the JTAG signals to complete the JTAG debugging operation.

Description

Technical Field

[0001] The present invention relates to the field of storage technology, and particularly to a method, device, equipment, medium and product for debugging an NVMe device controller. Background Art

[0002] With the development of embedded systems and storage technology, the debugging requirements are increasing day by day. The traditional JTAG (Joint Test Action Group) debugging interface faces challenges in high-speed memories and complex systems.

[0003] The schematic diagram of the SoC (System on Chip) debugging of a traditional NVMe (Non Volatile Memory Express) device is as Figure 1 shown. The JTAG-DP (JTAG Debug Port) is an interface in the ARM CoreSight debugging architecture, providing a 5-pin standard JTAG interface for connecting an external debugger to the SoC. The JTAG-DP allows the debugger to control and monitor the internal state of the target device by sending a specific sequence of JTAG instructions. The AHB-AP (Advanced High-performance Bus Access Port) is an interface in the CoreSight architecture for accessing devices mounted on the AHB system bus, which enables the debugger to access the CPU memory and registers inside the SoC through memory mapping. The debugger connects to the SoC through the JTAG-DP, and then, through the control of the DAP (Debug Access Port), converts the debugging request into an access to the AHB-AP. The AHB-AP then converts these accesses into AHB bus accesses to access the internal resources of the processor (such as the CPU) for testing and debugging purposes.

[0004] However, the JTAG interface in the traditional JTAG debugging method requires at least 4 pins, which occupies a relatively large amount of I / O (Input / Output) resources and board-level space. In addition, the JTAG debugging has certain limitations in terms of stability and data transfer speed, resulting in low debugging efficiency.

[0005] In summary, how to more efficiently implement the JTAG debugging function for the NVMe device controller to improve the debugging efficiency is a problem to be solved at present. Summary of the Invention

[0006] In view of this, the object of the present invention is to provide a method, device, equipment, medium and product for debugging an NVMe device controller, which can more efficiently implement the JTAG debugging function of the NVMe device controller to improve the debugging efficiency. The specific solution is as follows:

[0007] In the first aspect, the present application discloses a method for debugging an NVMe device controller, which is applied to a target NVMe device controller and includes:

[0008] During the initialization process, enable the controller memory buffer and set the attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through the bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space;

[0009] Obtain the target operation command sent by the target host by accessing the virtual mapping address, and parse the target operation command to obtain the parsed data; wherein, the target operation command is a command for performing JTAG debugging operation on the target NVMe device controller;

[0010] Use the TAP state machine to convert the parsed data into JTAG signals, so as to access the processor resources in the local system-on-chip based on the JTAG signals to complete the JTAG debugging operation.

[0011] Optionally, a controller capability register is locally set in the target NVMe device controller;

[0012] Correspondingly, enabling the controller memory buffer during the initialization process includes:

[0013] Set the target field in the controller capability register that indicates support for the controller memory buffer function to a target value to enable the controller memory buffer.

[0014] Optionally, the process of the target host enumerating any NVMe device controller through the bus includes:

[0015] The target host obtains the target field in the controller capability register of any NVMe device controller through the bus and determines whether the target field is a target value;

[0016] If the target field is a target value, obtain the attribute parameters of the controller memory buffer in any NVMe device controller, and map the controller memory buffer to the local memory space based on the attribute parameters.

[0017] Optionally, the initialization process of the target host includes:

[0018] Enumerate each NVMe device controller through the bus to obtain the attribute parameters of the controller memory buffer in each NVMe device controller;

[0019] Initialize the NVMe driver interface and configure the target register to enable the function of the controller memory buffer; wherein, the target register is used to control and report the status of the controller memory buffer.

[0020] Optionally, obtain the target operation command sent by the target host by accessing the virtual mapped address, including:

[0021] Send a debug request to the NVMe driver interface through the debug tool in the target host;

[0022] Obtain the target operation command sent by the NVMe driver interface; the target operation command is the target operation command obtained after the NVMe driver interface converts the debug request into read and write operations on the virtual mapped address.

[0023] Optionally, a first register for configuring the size information of the controller memory buffer and a second register for specifying the location information of the controller memory buffer in the memory space of the target host are locally set in the target NVMe device controller;

[0024] Correspondingly, setting the attribute parameters of the controller memory buffer includes:

[0025] Configure the value of the first register based on a first preset value to obtain the size information of the controller memory buffer;

[0026] Configure the value of the second register based on a second preset value to obtain the location information of the controller memory buffer in the memory space of the target host.

[0027] Optionally, the NVMe device controller debugging method of the present application further includes:

[0028] Obtain the current first value of the first register and the current second value of the second register through the target host, and allocate a corresponding memory size in the local memory space based on the current first value, and determine the physical address of the controller memory buffer in the local memory space based on the current second value, so as to obtain the virtual mapped address of the controller memory buffer in the local memory space according to the memory size and the physical address.

[0029] Optionally, the second preset value includes a base address register field and an offset address field;

[0030] Correspondingly, determining the physical address of the controller memory buffer in the local memory space based on the current second value includes:

[0031] Determine the corresponding base address register locally based on the base address register field;

[0032] Determine the physical address of the controller memory buffer in the local memory space based on the base address register and the target offset address represented by the offset address field.

[0033] Optionally, the virtual mapped address includes a command register and a data register;

[0034] Accordingly, obtain the target operation command sent by the target host by accessing the virtual mapped address, including:

[0035] Obtain the data written by the target host to the command register and the data register respectively to obtain the target operation command.

[0036] Optionally, the target operation command includes a command type and a data signal;

[0037] Accordingly, obtain the data written by the target host to the command register and the data register respectively to obtain the target operation command, including:

[0038] Obtain the command type written by the target host to the command register; wherein, the command type is a read command type or a write command type;

[0039] Obtain the data signal written by the target host to the data register; wherein, the data signal is a signal corresponding to the read command type or a signal corresponding to the write command type.

[0040] Optionally, use the TAP state machine to convert the parsed data into JTAG signals, including:

[0041] Set the TAP state machine to a preset initial state;

[0042] Generate a corresponding TMS signal according to the command type in the parsed data;

[0043] Use the TMS signal to drive the TAP state machine to perform state transitions starting from the initial state, and extract the data signals in the parsed data bit by bit to convert them into JTAG signals.

[0044] Optionally, the states of the TAP state machine include an initial state, an idle state, a state for selecting the data register path, and a state for selecting the instruction register path.

[0045] Optionally, the virtual mapped address further includes a status register;

[0046] Accordingly, the method of the present application further includes:

[0047] After detecting that the target host writes data to the command register, set the status register to the busy state;

[0048] After completing the JTAG debugging operation, set the status register to the idle state.

[0049] Optionally, after completing the JTAG debugging operation, it further includes:

[0050] Obtain the debugging result corresponding to the JTAG debugging operation;

[0051] Write the debugging result into the data register so that the target host can read the debugging result from the data register.

[0052] Optionally, access the processor resources in the local on-chip system based on the JTAG signal to complete the JTAG debugging operation, including:

[0053] Connect the JTAG signal to the debug access port through the JTAG debug port, and convert the JTAG signal into an access request to the local on-chip system through the debug access port and the advanced high-performance bus access port to access the processor resources in the local on-chip system.

[0054] Optionally, convert the JTAG signal into an access request to the local on-chip system through the debug access port and the advanced high-performance bus access port to access the processor resources in the local on-chip system, including:

[0055] Convert the JTAG signal into an access request to the advanced high-performance bus access port through the debug access port, and convert the access request into an access to the advanced high-performance bus through the advanced high-performance bus access port to obtain the processor resources in the local on-chip system through the advanced high-performance bus.

[0056] In a second aspect, the present application discloses an NVMe device controller debugging device applied to a target NVMe device controller, including:

[0057] A buffer mapping module, configured to enable the controller memory buffer during initialization and set the attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through the bus, map the controller memory buffer to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space;

[0058] A command acquisition module, configured to acquire the target operation command sent by the target host by accessing the virtual mapping address and parse the target operation command to obtain the parsed data; wherein, the target operation command is a command for performing JTAG debugging operation on the target NVMe device controller;

[0059] A debugging module, configured to convert the parsed data into JTAG signals by using a TAP state machine, and access processor resources in a local on-chip system based on the JTAG signals to complete JTAG debugging operations.

[0060] In a third aspect, this application discloses an electronic device, including:

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

[0062] A processor, configured to execute the computer program to implement the steps of the previously disclosed NVMe device controller debugging method.

[0063] In a fourth aspect, this application discloses a computer-readable storage medium, configured to store a computer program; wherein, when the computer program is executed by a processor, the steps of the previously disclosed NVMe device controller debugging method are implemented.

[0064] In a fifth aspect, this application discloses a computer program product, including computer program / instructions, and when the computer program / instructions are executed by a processor, the steps of the previously disclosed NVMe device controller debugging method are implemented.

[0065] It can be seen that in the present application, the target NVMe device controller enables a controller memory buffer during the initialization process and sets attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through a bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain a virtual mapping address of the controller memory buffer in the memory space; obtaining a target operation command sent by the target host by accessing the virtual mapping address, and parsing the target operation command to obtain parsed data; wherein, the target operation command is a command for performing JTAG debugging operations on the target NVMe device controller; converting the parsed data into JTAG signals by using a TAP state machine, and accessing processor resources in a local on-chip system based on the JTAG signals to complete JTAG debugging operations.

[0066] Beneficial effects: In the initialization process of the NVMe device controller in this application, the local controller memory buffer is enabled, and the attribute parameters of the controller memory buffer are set. So that when the target host enumerates the target NVMe device controller through the bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space. Thus, the target host can directly access the controller memory buffer as if it were accessing its own memory, bypassing the traditional NVMe command queue, reducing the protocol stack overhead, and significantly reducing the latency. Further, obtain the target operation command for performing JTAG debugging operations on the target NVMe device controller sent by the target host by accessing the virtual mapping address. That is, the target host can directly operate the virtual mapping address through memory mapping, thereby reducing the CPU overhead and data access latency, improving the host performance, while also reducing the burden on the host CPU and reducing system resource consumption. Then, the parsed data is obtained by parsing the target operation command, and then it is converted into a JTAG signal through the TAP state machine, enabling access to the processor resources in the local system-on-chip based on the JTAG signal to complete the JTAG debugging operation. That is, this application uses the controller memory buffer of the NVMe device controller as a debugging interface. By mapping the controller memory buffer to the host memory space, the host can directly access the controller memory buffer, thereby realizing the JTAG debugging function of the NVMe device controller. In this way, the number of hardware pins is reduced, the data transmission efficiency is improved, and the overall debugging efficiency is thus improved. Description of the Drawings

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

[0068] Figure 1 It is a debugging schematic diagram of a traditional NVMe device controller;

[0069] Figure 2 It is a flowchart of a method for debugging an NVMe device controller disclosed in the present application;

[0070] Figure 3 It is a debugging architecture diagram of an NVMe device controller disclosed in the present application;

[0071] Figure 4 It is a flowchart of a specific method for debugging an NVMe device controller disclosed in the present application;

[0072] Figure 5 An NVMe device JTAG debugging timing interaction diagram disclosed in this application;

[0073] Figure 6 A conversion flowchart using CMB as a JTAG interface disclosed in this application;

[0074] Figure 7 A schematic structural diagram of a debugging device for an NVMe device controller disclosed in this application;

[0075] Figure 8 A structural diagram of an electronic device disclosed in this application. Detailed implementation manners

[0076] Next, the technical solutions in the embodiments of this application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0077] The schematic diagram of the SoC debugging of traditional NVMe devices is as Figure 1 shown. JTAG-DP is an interface in the ARM CoreSight debugging architecture, providing a 5-pin standard JTAG interface for connecting an external debugger to the SoC. JTAG-DP allows the debugger to control and monitor the internal state of the target device by sending a specific JTAG instruction sequence. The debugger connects to the SoC through JTAG-DP, and then through the control of DAP, converts the debugging request into an access to AHB-AP, and AHB-AP then converts these accesses into AHB bus accesses to access the internal resources of the CPU, achieving the purpose of testing and debugging. However, the JTAG interface in the traditional JTAG debugging method requires at least 4 pins, which occupies more I / O (Input / Output) resources and board-level space. In addition, JTAG debugging has certain limitations in terms of stability and data transmission speed, resulting in low debugging efficiency.

[0078] Therefore, the embodiments of this application disclose a method, device, equipment, medium and product for debugging an NVMe device controller, which can more efficiently implement the JTAG debugging function of the NVMe device controller to improve the debugging efficiency.

[0079] See Figure 2 shown. The embodiments of this application disclose a method for debugging an NVMe device controller, which is applied to a target NVMe device controller. The method includes:

[0080] Step S11: Enable the controller memory buffer during initialization and set the attribute parameters of the controller memory buffer so that when the target host enumerates the target NVMe device controller through the bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space.

[0081] In this embodiment, the NVMe device controller enables the local controller memory buffer (Controller Memory Buffer, i.e., CMB) during initialization and sets the attribute parameters of the controller memory buffer so that when the target host enumerates the target NVMe device controller through the bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space, so that the target host can directly access the controller memory buffer like accessing its own memory, bypassing the traditional NVMe command queue, reducing the protocol stack overhead, and significantly reducing the latency. Among them, CMB is an important feature in the NVMe protocol, which allows the SSD controller to map the internal general buffer to the host side, so that the host side can directly access it in the form of PCIe memory read / write (memory read / write).

[0082] Moreover, since each NVMe device controller has a local controller memory buffer, when multiple NVMe device controllers map their local controller memory buffers to the memory space of the target host, the host can debug multiple devices simultaneously.

[0083] It should be noted that the target NVMe device controller is locally provided with a controller capability register; correspondingly, enabling the controller memory buffer during initialization includes: setting the target field in the controller capability register that indicates support for the controller memory buffer function to a target value to enable the controller memory buffer. It can be understood that the controller capability register includes a target field that indicates whether to support the controller memory buffer function, that is, the CAP.CMBS (Controller Memory Buffer Support) field. If CAP.CMBS = 1, it means that the NVMe device controller supports CMB; if CAP.CMBS = 0, it means that the NVMe device controller does not support CMB, and subsequent CMB-related operations cannot be performed. Therefore, the target NVMe device controller will set the CAP.CMBS field in the controller capability register to the target value 1 during the power-on initialization stage, that is, enable the controller capability register CAP.CMBS to enable the controller memory buffer.

[0084] In a specific embodiment, the process by which a target host enumerates any NVMe device controller via a bus includes: the target host obtains a target field in a controller capability register in any NVMe device controller via the bus, and determines whether the target field is a target value; if the target field is the target value, the target host obtains attribute parameters of a controller memory buffer in any NVMe device controller, so as to map the controller memory buffer to a local memory space based on the attribute parameters.

[0085] First, it should be pointed out that enumeration refers to the process in which a host scans a PCIe (Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard) bus during startup to discover devices and allocate resources (such as memory addresses and interrupts). The purposes of enumeration include the following aspects: (1) Device discovery: The host needs to know which PCIe EP (EndPoint) devices are connected to the bus. Since the PCIe system supports hot plugging, devices may be inserted or removed at any time during system operation. Therefore, the host needs to perform device enumeration regularly or when detecting hardware changes to discover new devices or confirm removed devices; (2) Resource allocation: Allocate necessary system resources for each PCIe EP device, such as memory address space, I / O address space, and interrupt numbers, etc. Each device needs to have a unique resource allocation in the system to ensure that they can work properly and do not conflict with each other; (3) Device configuration: Read and set the configuration information of PCIe EP devices. Each PCIe device has a configuration space, which contains information such as the vendor ID, device ID, device type, and supported functions of the device. The host reads this information through the enumeration process and configures the device as needed to adapt it to the system environment.

[0086] In this embodiment, the target host needs to obtain the target field CAP.CMBS in the controller capability register in each NVMe device controller via the PCIe bus. If CAP.CMBS is 1, the target host obtains the attribute parameters of the controller memory buffer in the NVMe device controller, so as to map the controller memory buffer to a local memory space based on the attribute parameters, that is, allocate a corresponding memory space for the controller memory buffer, and then the controller memory buffer can be mapped. That is to say, when the host enumerates PCIe devices, the host reads the PCIe configuration space of the device. If it finds that the NVMe device controller supports CMB (CAP.CMBS = 1), it maps the CMB to its own physical address space according to its attribute parameters.

[0087] Among them, the initialization process of the target host includes: enumerating each NVMe device controller through the bus to obtain the attribute parameters of the controller memory buffer in each NVMe device controller; initializing the NVMe driver interface and configuring the target register to enable the function of the controller memory buffer; wherein, the target register is used to control and report the status of the controller memory buffer. That is, in the power-on initialization stage, both the NVMe device controller and the target host need to complete the local initialization process. Among them, the NVMe device completes the basic function initialization, enables the NVMe controller register CAP.CMBS, and sets the attribute parameters of the CMB. The target host needs to enumerate the PCIE ep device, obtain the attribute parameter settings of the CMB, complete the initialization of the NVMe driver (driver interface), and also needs to configure the target register to enable the CMB function to ensure that the CMB can be accessed; the target register specifically refers to the CMDMSC (Command Memory Space Control and Status Register), which is mainly used to control and report the status of the controller memory buffer. That is, during system initialization, the host sets the CMDMSC register to enable the CMB function. By setting the corresponding bits of this register, the NVMe device is informed that the host is allowed to access the CMB in the form of PCIe memory read / write, providing a basis for subsequent debugging operations.

[0088] Step S12: Obtain the target operation command sent by the target host by accessing the virtual mapped address, and parse the target operation command to obtain the parsed data; wherein, the target operation command is a command for performing JTAG debugging operations on the target NVMe device controller.

[0089] In this embodiment, obtaining the target operation command for performing JTAG debugging operations on the target NVMe device controller sent by the target host by accessing the virtual mapped address means that the target host can directly operate the virtual mapped address through memory mapping, thereby reducing the CPU overhead and data access latency, improving the host performance, simultaneously reducing the burden on the host CPU and reducing the system resource consumption, and then parsing the target operation command to obtain the parsed data.

[0090] In the specific implementation, obtaining the target operation command sent by the target host by accessing the virtual mapped address includes: sending a debugging request to the NVMe driver interface through the debugging tool in the target host; obtaining the target operation command sent by the NVMe driver interface; the target operation command is the target operation command obtained after the NVMe driver interface converts the debugging request into read / write operations on the virtual mapped address. For specific reference Figure 3As shown in the architecture in [description], the target host sends a debug request to the NVMe driver interface through an internal user debug tool. After the NVMe driver interface converts the debug request into read and write operations on the CMB virtual mapped address, it then issues a target operation command to the target NVMe device controller. That is, the host user debug tool accesses the CMB address by calling the Nvme driver interface, and issues the JTAG command through the read and write of the CMB to perform specific debug operations.

[0091] Step S13: Use the TAP state machine to convert the parsed data into JTAG signals, and access the processor resources in the local system-on-chip based on the JTAG signals to complete the JTAG debug operation.

[0092] Specifically, as Figure 3 shown, this embodiment is provided with a CMB2JTAG module, which allows the CMB in the NVMe device controller to be used for JTAG debug functions. By specifying the CMB memory mapping, read and write specific addresses to implement JTAG protocol conversion, and use the TAP state machine to manage the JTAG debug operation. Therefore, in this embodiment, the read CMB data can be converted into JTAG signals through the internal TAP state machine, enabling access to the processor resources in the local system-on-chip based on the JTAG signals to complete the JTAG debug operation. That is, this application uses the controller memory buffer of the NVMe device controller as a debug interface. By mapping the controller memory buffer to the host memory space, the host can directly access the controller memory buffer, thereby implementing the JTAG debug function for the NVMe device controller. In this way, the number of hardware pins is reduced, the data transmission efficiency is improved, and thus the overall debug efficiency is improved.

[0093] In the specific implementation, accessing the processor resources in the local system-on-chip based on the JTAG signals to complete the JTAG debug operation includes: connecting the JTAG signals to the debug access port through the JTAG debug port, and converting the JTAG signals into access requests to the local system-on-chip through the debug access port and the advanced high-performance bus access port to access the processor resources in the local system-on-chip.

[0094] That is, as Figure 3As shown, in this embodiment, the JTAG signal is connected to the Debug Access Port (DAP) through the JTAG-DP (JTAG Debug Port), and then through the control of the Debug Access Port (DAP) and the Advanced High Performence Bus Access Port (i.e., AHB-AP), the JTAG signal is converted into an access request to the local system-on-chip to access the processor resources in the local system-on-chip, such as CPU resources, for the purpose of testing and debugging. Among them, DAP is a key component in the ARM CoreSight debugging architecture. It allows an external debugger to access the debugging resources inside the SoC (System on Chip). DAP provides an interface that enables the debugger to communicate with the debugging hardware on the SoC through a set of standard pins (such as JTAG) to achieve access to and control of the internal resources of the SoC. AHB-AP is a component of DAP. It allows the debugger to access the devices connected to the AHB bus in a memory-mapped manner.

[0095] Specifically, converting the JTAG signal into an access request to the local system-on-chip through the Debug Access Port and the Advanced High Performence Bus Access Port to access the processor resources in the local system-on-chip includes: converting the JTAG signal into an access request to the Advanced High Performence Bus Access Port through the Debug Access Port, and converting the access request into an access to the Advanced High Performence Bus through the Advanced High Performence Bus Access Port to obtain the processor resources in the local system-on-chip through the Advanced High Performence Bus. That is, as Figure 3 shown, DAP converts the JTAG signal into an access request to AHB-AP, and AHB-AP then converts these accesses into accesses to the AHB bus, thereby obtaining the processor resources in the local system-on-chip through the AHB bus.

[0096] It can be seen that during the initialization process, the NVMe device controller in the present application enables the local controller memory buffer and sets the attribute parameters of the controller memory buffer. When the target host enumerates the target NVMe device controller through the bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space, so that the target host can directly access the controller memory buffer as if it were accessing its own memory, bypassing the traditional NVMe command queue, reducing the protocol stack overhead, and significantly reducing the latency. Further, the target operation command for performing JTAG debugging operations on the target NVMe device controller sent by the target host by accessing the virtual mapping address is obtained, that is, the target host can directly operate on the virtual mapping address through memory mapping, thereby reducing the CPU overhead and data access latency, improving the host performance, and at the same time reducing the burden on the host CPU and reducing the system resource consumption. Then, the data after parsing is obtained by parsing the target operation command, and then it is converted into a JTAG signal through the TAP state machine, so that the processor resources in the local system-on-chip can be accessed based on the JTAG signal to complete the JTAG debugging operation. That is, the present application uses the controller memory buffer of the NVMe device controller as a debugging interface. By mapping the controller memory buffer to the host memory space, the host can directly access the controller memory buffer, thereby realizing the JTAG debugging function of the NVMe device controller. In this way, the number of hardware pins is reduced, the data transmission efficiency is improved, and the overall debugging efficiency is improved.

[0097] See Figure 4 and Figure 5 As shown, an embodiment of the present application discloses a specific NVMe device controller debugging method. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically, it includes:

[0098] Step S21: Enable the controller memory buffer during the initialization process, and configure the value of the first register based on the first preset value to obtain the size information of the controller memory buffer, and configure the value of the second register based on the second preset value to obtain the position information of the controller memory buffer in the memory space of the target host.

[0099] In this embodiment, it should be noted that two registers are locally set in the target NVMe device controller to represent the basic information of the CMB. Specifically, the first register is used to configure the size information of the controller memory buffer, and the second register is used to specify the position information of the controller memory buffer in the memory space of the target host. The information of these two registers can be viewed in the host. Therefore, when setting the attribute parameters of the controller memory buffer during the initialization process of the NVMe device controller, it is to configure the values of the first register and the second register.

[0100] Specifically, the first register is the CMBSZ register, which is used to configure the size information of the CMB, for example, using a size of 1M; the second register is the CMBLOC register, which is used to specify the position information of the CMB in the memory space of the target host. Therefore, the NVMe device controller can configure the value of the first register based on the first preset value to obtain the size information of the controller memory buffer, and configure the value of the second register based on the second preset value to obtain the position information of the controller memory buffer in the memory space of the target host.

[0101] Step S22: When the target host enumerates the target NVMe device controller through the bus, map the controller memory buffer to the memory space of the target host based on the size information and the position information, so as to obtain the virtual mapping address of the controller memory buffer in the memory space.

[0102] In this embodiment, when the target host enumerates the target NVMe device controller, it can view the register information of the target NVMe device controller locally, and thus map the controller memory buffer to the memory space of the target host according to the obtained size information and position information.

[0103] Specifically, the above method further includes: obtaining the current first value of the first register and the current second value of the second register through the target host, and allocating the corresponding memory size in the local memory space based on the current first value, and determining the physical address of the controller memory buffer in the local memory space based on the current second value, so as to obtain the virtual mapping address of the controller memory buffer in the local memory space according to the memory size and the physical address. That is, after the target host obtains the current first value of the first register, it can allocate the corresponding memory size in the local memory space according to the current first value for mapping the CMB. In addition, the debugging tool also needs to know the capacity of the CMB to limit the size of the JTAG commands and data, and avoid writing addresses beyond the CMB range. Furthermore, after the target host obtains the current second value of the second register, it can determine the physical address of the controller memory buffer in the local memory space according to the current second value, and thus finally obtain the virtual mapping address of the CMB in the local memory space according to the memory size and the physical address.

[0104] In a specific embodiment, the first preset value for configuring the CMBSZ register includes a Size field, which refers to the length of the available space in the CMB, and the unit is also CMBSZ.SZ. In addition, CMBSZ also includes Size Units (SZU), which represents the size unit of the CMB. Among them, the size of the CMB is allowed to be configured very large as long as the device has enough space.

[0105] In a specific embodiment, the second preset value includes a base address register field and an offset address field. Correspondingly, determining the physical address of the controller memory buffer in the local memory space based on the current second value includes: determining the corresponding base address register locally based on the base address register field; determining the physical address of the controller memory buffer in the local memory space based on the base address register and the target offset address represented by the offset address field. That is, the second preset value for configuring the CMBLOC register includes two main fields: OFST (Offset, offset address field), which represents the offset address of the CMB, with the unit of CMBSZ.SZ and requires 4KB alignment; the BIR (Base Indicator Register, base address register field) field, which represents the serial number of the PCI BAR (base address register). Therefore, when determining the physical address of the CMB in the host memory space, first determine the corresponding base address register locally based on the base address register field, and then determine the final physical address of the controller memory buffer in the local memory space based on the base address register and the target offset address represented by the offset address field. That is, the host first finds the corresponding PCIe BAR through BIR, and combines OFST to map the CMB to the host physical address space. For example, BIR = 0 represents BAR0, and the host reads the base address of BAR0 and adds OFST to obtain the final physical address of the CMB.

[0106] Step S23: Obtain the data written by the target host to the command register and the data register respectively to obtain a target operation command, and parse the target operation command to obtain the parsed data; where the target operation command is a command for performing JTAG debugging operations on the target NVMe device controller.

[0107] It should be noted that the virtual mapped address includes the command register CMD_REG and the data register DATA_REG. Therefore, when the target host issues the target operation command by accessing the virtual mapped address, it mainly writes data to the command register and the data register respectively to issue the target operation command.

[0108] In addition, the virtual mapped address further includes a status register; correspondingly, the method of the present application further includes: after detecting that the target host writes data to the command register, setting the status register to the busy state; after completing the JTAG debugging operation, setting the status register to the idle state. The status register is denoted as STATUS_REG, which is mainly used to reflect the current operation state. Specifically, after detecting that the target host writes data to the command register, the status register is set to the busy state. Additionally, after completing the JTAG debugging operation, the status register is set to the idle state.

[0109] In the specific implementation manner, the target operation command includes a command type and a data signal; correspondingly, obtaining the data written by the target host to the command register and the data register respectively to obtain the target operation command includes: obtaining the command type written by the target host to the command register; wherein, the command type is a read command type or a write command type; obtaining the data signal written by the target host to the data register; wherein, the data signal is a signal corresponding to the read command type or a signal corresponding to the write command type. That is to say, the issued target operation command includes a command type and a data signal. Among them, the target host writes the command type to the command register. The command type can specifically be a read command type or a write command type, and different operation codes can be used to represent it. For example, 0x01 represents writing to the IR (Instruction Register), and 0x02 represents reading from the DR (Data Register). Writing to the IR means writing a specific instruction into the instruction register of the JTAG TAP (Test Access Port) state machine, thereby implementing various debugging and testing functions; reading from the DR means reading data from the data register of the JTAG TAP state machine. The data register is used to store data during the test or debugging process, such as the values of internal chip registers and the test results of the boundary scan chain. In addition, the data signal written by the target host to the data register specifically includes a signal corresponding to the read command type (TDO signal, Test Data Out) or a signal corresponding to the write command type (TDI signal, Test Data In).

[0110] That is to say, three different registers are defined in the virtual mapped address in this embodiment:

[0111] (1) CMD_REG: stores the JTAG command;

[0112] (2) DATA_REG: is used to transfer data (TDI signal / TDO signal);

[0113] (3) STATUS_REG: reflects the current operation state.

[0114] The addresses are defined as follows:

[0115] #define CMD_ADDR 0x20000000;

[0116] #define DATA_ADDR 0x20000004;

[0117] #define STATUS_ADDR 0x20000008.

[0118] In this way, the host issues JTAG operation commands through the CMB. Among them, the CMD_REG in the CMB stores JTAG commands, the DATA_REG is used to transfer data (TDI / TDO), and the STATUS_REG reflects the current operation status. Correspondingly, the NVMe device controller reads the JTAG command by parsing the CMD_REG address in the CMB, performs read and write operations through the DATA_REG in the CMB, reads the JTAG operation status through the STATUS_REG in the CMB, and executes the corresponding JTAG debugging operation according to the determined operation type (such as read, write).

[0119] Step S24: Set the TAP state machine to a preset initial state, generate a corresponding TMS signal according to the command type in the parsed data, use the TMS signal to drive the TAP state machine to perform state transitions starting from the initial state, and extract the data signals in the parsed data bit by bit to convert them into JTAG signals.

[0120] In this embodiment, as Figure 6 shown, when the CMB2JTAG module detects that a JTAG command is written to the CMD_REG, it is necessary to reset the TAP state machine to set the TAP state machine to a preset initial state, specifically to force it to enter the Test-Logic-Reset state. Further, a corresponding TMS (Test Mode Select) signal is generated according to the command type in the parsed data, and the TMS signal is used to drive the TAP state machine to perform state transitions starting from the initial state, and the data signals in the parsed data are extracted bit by bit to convert them into JTAG signals. Among them, the TMS signal controls the TAP state machine to switch between 16 states through the combination of high and low levels (1 or 0).

[0121] It should be noted that the states of the TAP state machine include an initial state, an idle state, a state for selecting a data register path, and a state for selecting an instruction register path.

[0122] It is understandable that the CMB2JTAG module uses the TAP state machine to manage the process of sending, executing, and responding to commands, ensuring the orderly progress of the debugging process. The 16 states of the TAP state machine are defined as follows:

[0123] typedef enum {

[0124] TEST_LOGIC_RESET,

[0125] RUN_TEST_IDLE,

[0126] SELECT_DR_SCAN,

[0127] CAPTURE_DR,

[0128] SHIFT_DR,

[0129] EXIT1_DR,

[0130] PAUSE_DR,

[0131] EXIT2_DR,

[0132] UPDATE_DR,

[0133] SELECT_IR_SCAN,

[0134] CAPTURE_IR,

[0135] SHIFT_IR,

[0136] EXIT1_IR,

[0137] PAUSE_IR,

[0138] EXIT2_IR,

[0139] UPDATE_IR

[0140] } TAP_State;

[0141] TAP_State current_state = TEST_LOGIC_RESET;

[0142] Furthermore, the pseudocode for updating the TAP state machine is as follows:

[0143] void update_tap_state(uint32_t tms) {

[0144] switch (current_state) {

[0145] case TEST_LOGIC_RESET:

[0146] current_state = tms? TEST_LOGIC_RESET : RUN_TEST_IDLE;

[0147] break;

[0148] case RUN_TEST_IDLE:

[0149] current_state = tms? SELECT_DR_SCAN : RUN_TEST_IDLE;

[0150] break;

[0151] case SELECT_DR_SCAN:

[0152] current_state = tms? SELECT_IR_SCAN : CAPTURE_DR;

[0153] break;

[0154] case CAPTURE_DR:

[0155] current_state = tms? EXIT1_DR : SHIFT_DR;

[0156] break;

[0157] case SHIFT_DR:

[0158] current_state = tms? EXIT1_DR : SHIFT_DR;

[0159] break;

[0160] case EXIT1_DR:

[0161] current_state = tms? UPDATE_DR : PAUSE_DR;

[0162] break;

[0163] case PAUSE_DR:

[0164] current_state = tms? EXIT2_DR : PAUSE_DR;

[0165] break;

[0166] case EXIT2_DR:

[0167] current_state = tms? UPDATE_DR : SHIFT_DR;

[0168] break;

[0169] case UPDATE_DR:

[0170] current_state = tms? SELECT_DR_SCAN : RUN_TEST_IDLE;

[0171] break;

[0172] case SELECT_IR_SCAN:

[0173] current_state = tms? TEST_LOGIC_RESET : CAPTURE_IR;

[0174] break;

[0175] case CAPTURE_IR:

[0176] current_state = tms? EXIT1_IR : SHIFT_IR;

[0177] break;

[0178] case SHIFT_IR:

[0179] current_state = tms? EXIT1_IR : SHIFT_IR;

[0180] break;

[0181] case EXIT1_IR:

[0182] current_state = tms? UPDATE_IR : PAUSE_IR;

[0183] break;

[0184] case PAUSE_IR:

[0185] current_state = tms? EXIT2_IR : PAUSE_IR;

[0186] break;

[0187] case EXIT2_IR:

[0188] current_state = tms? UPDATE_IR : SHIFT_IR;

[0189] break;

[0190] case UPDATE_IR:

[0191] current_state = tms? SELECT_DR_SCAN : RUN_TEST_IDLE;

[0192] break;

[0193] }

[0194] }。

[0195] The pseudo-code for reading and writing the CMB data register is as follows:

[0196] void read_write_data(uint32_t *data, int write) {

[0197] if (write) {

[0198] *(volatile uint32_t *)DATA_REG = *data;

[0199] } else {

[0200] *data = *(volatile uint32_t *)DATA_REG;

[0201] }

[0202] }。

[0203] The pseudo-code for updating the CMB status register is as follows:

[0204] int check_status() {

[0205] return *(volatile uint32_t *)STATUS_REG;

[0206] }。

[0207] The above process will be described in detail below by taking the example of the host sending a read DR (data register) command through the CMB:

[0208] Step 1: Initialize the TAP state machine

[0209] When the CMB2JTAG module detects that JTAG_READ_DR is written to the CMD_REG, reset the TAP state machine:

[0210] Force entry into the Test-Logic-Reset state (by pulling the TMS signal high).

[0211] Subsequently, jump to Run-Test / Idle (TMS = 0).

[0212] Step 2: Enter the data register (DR) path

[0213] 1. Select-DR-Scan (TMS = 1):

[0214] Prepare to switch to the DR path.

[0215] 2. Capture-DR (TMS = 0):

[0216] Capture the current value of the register (such as the content of the CPU register).

[0217] 3. Shift-DR (TMS = 0):

[0218] On the rising edge of TCK, shift TDI (from DATA_REG) bit by bit into the register, and at the same time shift the captured data out from TDO bit by bit.

[0219] Data exchange: For each cycle of TCK, 1 bit of TDI is shifted in, and 1 bit of TDO is shifted out (completed by reading and writing through DATA_REG).

[0220] 4. Exit1-DR (TMS = 1):

[0221] End the shift operation.

[0222] 5. Update-DR (TMS = 1):

[0223] Update the shifted data to the register (such as writing to the CPU register).

[0224] Step 3: Return to the idle state

[0225] Jump back to Run-Test / Idle (TMS = 0) and wait for the next command.

[0226] Step S25: Access the processor resources in the local on-chip system based on the JTAG signal to complete the JTAG debugging operation, obtain the debugging result corresponding to the JTAG debugging operation, and then write the debugging result into the data register so that the target host can read the debugging result from the data register.

[0227] In this embodiment, after the JTAG debugging operation is completed, the corresponding debugging result is obtained, and the debugging result is written into the data register so that the target host can read the debugging result from the data register, then the status register is updated, the TAP state machine is reset, and wait for the next JTAG command.

[0228] It can be seen that this application realizes the JTAG debugging function of the NVMe device through NVMe CMB. By completing the settings of the NVMe device controller and CMB in the initialization stage, the host is allowed to directly access the CMB through the NVMe driver interface without going through multiple protocol conversions, reducing the CPU overhead and data access latency. The user debugging tool can read and write the CMB through the Nvme_driver interface, issue JTAG commands, the NVMe device parses the commands in the CMB and executes the JTAG operation, and finally realizes the access and debugging of the SoC CPU resources through the CMB-to-JTAG module and DAP, ensuring the accuracy and timeliness of command execution. The advantage of this method is to utilize the characteristic that NVMe CMB can quickly access the storage controller to effectively realize the JTAG debugging function of the NVMe storage controller. By directly accessing the CMB for JTAG debugging, intermediate steps are reduced, the debugging efficiency and flexibility are improved, and at the same time, the system resource consumption is reduced, providing a more efficient and concise solution for the debugging of NVMe storage devices.

[0229] See Figure 7 As shown, an embodiment of this application discloses a debugging device for an NVMe device controller, which is applied to a target NVMe device controller. The device includes:

[0230] A buffer mapping module 11, configured to enable the controller memory buffer during initialization and set the attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through the bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space;

[0231] A command acquisition module 12, configured to acquire the target operation command sent by the target host by accessing the virtual mapping address, and parse the target operation command to obtain the parsed data; wherein, the target operation command is a command for performing JTAG debugging operation on the target NVMe device controller;

[0232] The debugging module 13 is used to convert the parsed data into JTAG signals by using the TAP state machine, so as to access the processor resources in the local on-chip system based on the JTAG signals to complete the JTAG debugging operation.

[0233] It can be seen that the NVMe device controller in this application enables the local controller memory buffer during the initialization process and sets the attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through the bus, the controller memory buffer is mapped to the memory space of the target host based on the attribute parameters to obtain the virtual mapping address of the controller memory buffer in the memory space, so that the target host can directly access the controller memory buffer like accessing its own memory, bypassing the traditional NVMe command queue, reducing the protocol stack overhead, and significantly reducing the latency. Further, obtain the target operation command for performing the JTAG debugging operation on the target NVMe device controller sent by the target host by accessing the virtual mapping address, that is, the target host can directly operate the virtual mapping address through memory mapping, thereby reducing the CPU overhead and the latency of data access, improving the host performance, while also reducing the burden on the host CPU and reducing the system resource consumption. Then, the parsed data is obtained by parsing the target operation command, and then it is converted into JTAG signals through the TAP state machine, so that the processor resources in the local on-chip system can be accessed based on the JTAG signals to complete the JTAG debugging operation. That is, this application uses the controller memory buffer of the NVMe device controller as a debugging interface. By mapping the controller memory buffer to the host memory space, the host can directly access the controller memory buffer, thereby realizing the JTAG debugging function of the NVMe device controller. In this way, the number of hardware pins is reduced and the data transmission efficiency is improved, thus improving the overall debugging efficiency.

[0234] Since the embodiments of the device part correspond to the above embodiments, the embodiments of the device part are described with reference to the embodiments of the above method part and will not be repeated here.

[0235] Figure 8 It is a schematic structural diagram of an electronic device provided by an embodiment of this application. Specifically, it may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. Among them, the memory 22 is used to store a computer program, and the computer program is loaded and executed by the processor 21 to implement the relevant steps in the NVMe device controller debugging method executed by the electronic device disclosed in any of the foregoing embodiments.

[0236] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and no specific limitation is imposed on it here; the input / output interface 25 is used to obtain external input data or output data to the outside, and its specific interface type can be selected according to specific application needs, and no specific limitation is imposed here.

[0237] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 can be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). The processor 21 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 CPU (Central Processing Unit); the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may be integrated with a GPU (Graphics Processing Unit), and the GPU is responsible for the rendering and drawing of the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, and the AI processor is used to process computational operations related to machine learning.

[0238] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, a random access memory, a disk, or an optical disc, etc. The resources stored thereon include an operating system 221, a computer program 222, and data 223, etc., and the storage method can be short-term storage or permanent storage.

[0239] Among them, the operating system 221 is used to manage and control each hardware device and computer program 222 on the electronic device 20, so as to implement the operation and processing of the massive data 223 in the memory 22 by the processor 21. It can be Windows, Unix, Linux, etc. In addition to the computer program that can be used to complete the NVMe device controller debugging method executed by the electronic device 20 disclosed in any of the foregoing embodiments, the computer program 222 may further include computer programs that can be used to complete other specific tasks. The data 223 may include not only the data transmitted by external devices received by the electronic device, but also the data collected by its own input / output interface 25, etc.

[0240] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium storing a computer program, which, when loaded and executed by a processor, implements the steps of the NVMe device controller debugging method disclosed in any of the foregoing embodiments.

[0241] An embodiment of the present invention also discloses a computer program product including a computer program / instructions, which, when executed by a processor, implements the steps of the NVMe device controller debugging method disclosed in any of the foregoing embodiments.

[0242] In this specification, each embodiment is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple. For the relevant parts, please refer to the description of the method part.

[0243] 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 both. 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 this application.

[0244] The steps of the methods or algorithms described in combination with the embodiments disclosed in this document can be implemented directly by hardware, software modules executed by a processor, or a combination of both. The software modules can be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, compact disc read-only memory (CD-ROM), or any other form of storage medium known in the technical field.

[0245] Finally, it should also be noted that in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the existence of additional identical elements in the process, method, article or device comprising the element.

[0246] The above has introduced in detail a method, device, equipment and storage medium for debugging an NVMe device controller provided by the present invention. Specific examples are used in this document 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; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation to the present invention.

Claims

1. A method for debugging an NVMe device controller, characterized in that, Applied to the target NVMe device controller, including: Enable the controller memory buffer during initialization and set the attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through the bus, based on the attribute parameters, map the controller memory buffer to the memory space of the target host to obtain the virtual mapping address of the controller memory buffer in the memory space; Obtain the target operation command sent by the target host by accessing the virtual mapping address, and parse the target operation command to obtain the parsed data; wherein, the target operation command is a command for performing JTAG debugging operation on the target NVMe device controller; Use the TAP state machine to convert the parsed data into JTAG signals, and access the processor resources in the local system-on-chip based on the JTAG signals to complete the JTAG debugging operation; Wherein, the attribute parameters include the size information of the controller memory buffer and the location information of the controller memory buffer in the memory space of the target host. The target host allocates the corresponding memory size in the memory space according to the size information, and determines the physical address of the controller memory buffer in the memory space according to the location information, so as to obtain the virtual mapping address of the controller memory buffer in the memory space based on the memory size and the physical address.

2. The NVMe device controller debugging method according to claim 1, wherein, The target NVMe device controller is locally provided with a controller capability register; Correspondingly, enabling the controller memory buffer during initialization includes: Set the target field in the controller capability register for indicating support for the controller memory buffer function to a target value to enable the controller memory buffer.

3. The NVMe device controller debugging method according to claim 2, characterized in that The process of the target host enumerating any NVMe device controller through the bus includes: The target host obtains the target field in the controller capability register of any NVMe device controller through the bus, and determines whether the target field is the target value; If the target field is the target value, obtain the attribute parameters of the controller memory buffer in any NVMe device controller, and map the controller memory buffer to the local memory space based on the attribute parameters.

4. The NVMe device controller debugging method according to claim 3, wherein The initialization process of the target host includes: Enumerate each NVMe device controller through the bus to obtain the attribute parameters of the controller memory buffer in each NVMe device controller; Initialize the NVMe driver interface and configure the target register to enable the function of the controller memory buffer; wherein, the target register is used to control and report the state of the controller memory buffer.

5. The NVMe device controller debugging method according to claim 4, characterized in that The obtaining the target operation command sent by the target host by accessing the virtual mapping address includes: Send a debugging request to the NVMe driver interface through the debugging tool in the target host; Obtain the target operation command sent by the NVMe drive interface; the target operation command is the target operation command obtained after the NVMe drive interface converts the debugging request into read and write operations on the virtual mapped address.

6. The NVMe device controller debugging method according to claim 1, characterized in that, The target NVMe device controller is locally provided with a first register for configuring the size information of the controller memory buffer and a second register for specifying the position information of the controller memory buffer in the memory space of the target host. Correspondingly, the setting of the attribute parameters of the controller memory buffer includes: Configure the value of the first register based on a first preset value to obtain the size information of the controller memory buffer. Configure the value of the second register based on a second preset value to obtain the position information of the controller memory buffer in the memory space of the target host.

7. The NVMe device controller debugging method according to claim 6, wherein, It further includes: Obtain the current first value of the first register and the current second value of the second register through the target host, and allocate a corresponding memory size in the local memory space based on the current first value, and determine the physical address of the controller memory buffer in the local memory space based on the current second value, so as to obtain the virtual mapped address of the controller memory buffer in the local memory space according to the memory size and the physical address.

8. The NVMe device controller debugging method according to claim 7, characterized in that, The second preset value includes a base address register field and an offset address field. Correspondingly, the determining of the physical address of the controller memory buffer in the local memory space based on the current second value includes: Determine the corresponding base address register locally based on the base address register field. Determine the physical address of the controller memory buffer in the local memory space based on the base address register and the target offset address represented by the offset address field.

9. The NVMe device controller debugging method according to claim 1, wherein The virtual mapped address includes a command register and a data register. Correspondingly, the obtaining of the target operation command sent by the target host by accessing the virtual mapped address includes: Obtain the data written by the target host to the command register and the data register respectively to obtain the target operation command.

10. The NVMe device controller debugging method according to claim 9, characterized in that, The target operation command includes a command type and a data signal. Correspondingly, the obtaining of the data written by the target host to the command register and the data register respectively to obtain the target operation command includes: Obtain the command type written by the target host to the command register; wherein, the command type is a read command type or a write command type. Obtain the data signal written by the target host to the data register; wherein, the data signal is a signal corresponding to the read command type or a signal corresponding to the write command type.

11. The NVMe device controller debugging method according to claim 10, wherein The converting of the parsed data into a JTAG signal by using the TAP state machine includes: Set the TAP state machine to a preset initial state. Generate a corresponding TMS signal according to the command type in the parsed data. Drive the TAP state machine to perform state transitions starting from the initial state using the TMS signal, and extract the data signals in the parsed data bit by bit to convert them into JTAG signals.

12. The NVMe device controller debugging method according to claim 11, wherein The states of the TAP state machine include the initial state, the idle state, the state for selecting the data register path, and the state for selecting the instruction register path.

13. The NVMe device controller debugging method according to claim 9, characterized in that The virtual mapped address further includes a status register; Correspondingly, the method further includes: After detecting that the target host writes data to the command register, set the status register to the busy state; After completing the JTAG debugging operation, set the status register to the idle state.

14. The NVMe device controller debugging method according to claim 9, characterized in that, After completing the JTAG debugging operation, it further includes: Obtain the debugging result corresponding to the JTAG debugging operation; Write the debugging result into the data register so that the target host can read the debugging result from the data register.

15. The NVMe device controller debugging method according to any one of claims 1 to 14, characterized in that, The accessing the processor resources in the local on-chip system based on the JTAG signal to complete the JTAG debugging operation includes: Connect the JTAG signal to the debug access port through the JTAG debug port, and convert the JTAG signal into an access request to the local on-chip system through the debug access port and the advanced high-performance bus access port to access the processor resources in the local on-chip system.

16. The NVMe device controller debugging method according to claim 15, wherein The converting the JTAG signal into an access request to the local on-chip system through the debug access port and the advanced high-performance bus access port to access the processor resources in the local on-chip system includes: Convert the JTAG signal into an access request to the advanced high-performance bus access port through the debug access port, and convert the access request into an access to the advanced high-performance bus through the advanced high-performance bus access port to obtain the processor resources in the local on-chip system through the advanced high-performance bus.

17. An NVMe device controller debugging device, characterized in that, Applied to a target NVMe device controller, it includes: A buffer mapping module, used to enable the controller memory buffer during initialization and set the attribute parameters of the controller memory buffer, so that when the target host enumerates the target NVMe device controller through the bus, map the controller memory buffer to the memory space of the target host based on the attribute parameters to obtain the virtual mapped address of the controller memory buffer in the memory space; A command acquisition module, used to acquire the target operation command issued by the target host by accessing the virtual mapped address and parse the target operation command to obtain the parsed data; wherein, the target operation command is a command for performing JTAG debugging operation on the target NVMe device controller; A debugging module, used to convert the parsed data into JTAG signals using the TAP state machine to access the processor resources in the local on-chip system based on the JTAG signals to complete the JTAG debugging operation; Wherein, the attribute parameters include the size information of the controller memory buffer and the location information of the controller memory buffer in the memory space of the target host. The target host allocates a corresponding memory size in the memory space according to the size information, and determines the physical address of the controller memory buffer in the memory space according to the location information, so as to obtain the virtual mapping address of the controller memory buffer in the memory space based on the memory size and the physical address.

18. An electronic device, characterized in that, Comprising: A memory for storing a computer program; A processor for executing the computer program to implement the steps of the NVMe device controller debugging method according to any one of claims 1 to 16.

19. A computer-readable storage medium, characterized in that, For storing a computer program; wherein, when the computer program is executed by the processor, the steps of the NVMe device controller debugging method according to any one of claims 1 to 16 are implemented.

20. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the steps of the NVMe device controller debugging method according to any one of claims 1 to 16 are implemented.

Images