Firmware testing method and device, electronic equipment and readable storage medium

Abstract

The invention discloses a firmware testing method and device, electronic equipment and a readable storage medium, and the method comprises the steps: creating a virtual drive program in a kernel space of an operating system, and simulating a hardware function of a memory controller by the virtual drive program; deploying a command monitoring component in a user space of the operating system, wherein the command monitoring component establishes a communication link with the virtual driving program in the kernel space through a system calling interface; compiling the firmware package in a user space of an operating system to generate an executable firmware package, and transmitting the firmware package to a virtual drive program in a kernel space through the communication link; and executing function verification of the firmware package through the virtual drive program, feeding back a verification result to the command monitoring component, and iteratively modifying a firmware code in a user space based on a feedback result until a firmware function meets a preset requirement. According to the firmware testing scheme provided by the invention, the testing process is greatly simplified.

Description

Technical Field

[0001] The present application relates to the field of communications, and in particular to a firmware testing method, device, electronic device, and readable storage medium. Background Art

[0002] Firmware plays a central role in the architecture of solid-state drives (SSDs). As the underlying software embedded in the storage device, it controls hardware-level operations and management. Firmware is irreplaceable for SSD stability, performance optimization, and data security.

[0003] During the development of SSD firmware, a variety of testing strategies are typically employed to ensure the firmware's reliability, performance, and interoperability. According to current technical practices, SSD firmware is typically burned into the controller's internal read-only memory (ROM). Once the firmware module design is initially completed, white-box testing is performed to identify and address potential design flaws. White-box testing involves intentionally introducing various error scenarios to simulate abnormal conditions that may occur in the actual operating environment. This is done to verify that the firmware module's ability to handle these events meets expectations, and the firmware can be adjusted and corrected accordingly. However, this process is often complex and time-consuming, involving the frequent testing of new versions of the firmware into ROM.

[0004] Based on this problem, how to reduce the firmware development cycle and hardware dependency cost of firmware development / testing is a problem that technicians in this field are focusing on. Summary of the Invention

[0005] To address the above technical issues, this application provides a firmware testing method, device, electronic device, and readable storage medium that can evaluate firmware development results online without the need for physical burning. At the same time, it supports real-time compilation and modification, thereby greatly simplifying the testing process and improving efficiency. In this way, not only is the time cost of repeated burning reduced, but the flexibility and responsiveness of testing are also enhanced, helping to accelerate product iteration and improvement.

[0006] To solve the above technical problems, the present application provides a firmware testing method, comprising:

[0007] Creating a virtual driver in a kernel space of an operating system, the virtual driver emulating hardware functions of a memory controller;

[0008] Deploy a command monitoring component in the user space of the operating system, wherein the command monitoring component establishes a communication link with the virtual driver in the kernel space through a system call interface;

[0009] Compiling the firmware package in the user space of the operating system to generate an executable firmware package, and transmitting the firmware package to the virtual driver in the kernel space through the communication link;

[0010] Functional verification of the firmware package is performed through the virtual driver, and the verification result is fed back to the command monitoring component. Based on the feedback result, the firmware code is iteratively modified in the user space until the firmware function meets the preset requirements.

[0011] Optionally, in some embodiments of the present application, the step of the virtual driver simulating the hardware function of the memory controller includes:

[0012] Simulate the physical storage space of flash memory chips through memory mapping technology;

[0013] Dynamically generate a mapping table between logical addresses and physical block addresses based on the FTL rule engine;

[0014] Simulate the interrupt response mechanism and DMA transfer process of the memory controller.

[0015] Optionally, in some embodiments of the present application, the communication link is implemented in the following manner:

[0016] Register the device object in kernel space and receive instructions from user space through the IRP mechanism;

[0017] The command monitoring component sends test commands to the virtual driver through system calls, including read and write operations, error injection instructions, and status query instructions.

[0018] Optionally, in some embodiments of the present application, the step of iteratively modifying the firmware code includes:

[0019] The command monitoring component parses the log information fed back by the virtual driver to locate firmware defects;

[0020] Call the compiler in the user space to perform incremental compilation of the firmware code to generate an updated firmware package;

[0021] The updated firmware package is reloaded into the virtual driver via the communication link, triggering a new round of verification.

[0022] Optionally, in some embodiments of the present application, the virtual driver supports emulation of multiple types of storage devices, including USB flash drives, eMMC, UFS, and SSDs compatible with the FTL protocol:

[0023] The firmware testing method further includes:

[0024] Dynamically adjust the capacity, interface protocol (such as SATA, NVMe), and performance indicators of the simulated storage device based on preset parameters.

[0025] Optionally, in some embodiments of the present application, the method further includes:

[0026] In the mass production stage, the verified firmware package is converted into a hardware burning format through tools;

[0027] Use mass production tools to burn the firmware package to the physical storage device.

[0028] Optionally, in some embodiments of the present application, performing functional verification of the firmware package by the virtual driver includes:

[0029] Mapping the firmware code of the firmware package to the shared memory area through a shared memory mechanism;

[0030] Transmitting the data to the virtual driver through the shared memory area and informing the virtual driver through a notification mechanism;

[0031] The virtual driver verifies the received firmware code and performs firmware function verification according to the firmware code after the verification passes.

[0032] Optionally, in some embodiments of the present application, performing firmware function verification according to the firmware code after the verification passes includes:

[0033] The virtual driver simulates the hardware operation according to the firmware code after receiving the logical operation sent by the command monitoring component;

[0034] The virtual driver records performance indicators during the simulated hardware operation process and sends the performance indicators to the command monitoring component so that the command monitoring component can verify the firmware function corresponding to the firmware code.

[0035] Optionally, in some embodiments of the present application, the virtual driver records performance indicators during the simulated hardware operation process and sends the performance indicators to the command monitoring component so that the command monitoring component verifies the firmware function corresponding to the firmware code, including:

[0036] After the virtual driver adjusts the recorded performance indicators into data in a preset format, the adjusted performance indicators are written into the shared memory area, and an event signal is sent to the command monitoring component based on an event notification mechanism;

[0037] When the command monitoring component receives the event signal, it reads a performance indicator from the shared memory area and verifies the firmware function corresponding to the firmware code based on the read performance indicator.

[0038] Accordingly, the present application also provides a firmware testing device, which is applied to a virtual machine system and includes:

[0039] Creating a module for creating a virtual driver in a kernel space of an operating system, wherein the virtual driver simulates a hardware function of a memory controller;

[0040] A deployment module is used to deploy a command monitoring component in the user space of the operating system, wherein the command monitoring component establishes a communication link with the virtual driver in the kernel space through a system call interface;

[0041] A compiling module, configured to compile the firmware package in the user space of the operating system to generate an executable firmware package, and transmit the firmware package to the virtual driver in the kernel space via the communication link;

[0042] A verification module is used to perform functional verification of the firmware package through the virtual driver, feed back the verification result to the command monitoring component, and iteratively modify the firmware code in the user space based on the feedback result until the firmware function meets the preset requirements.

[0043] The present application also provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0044] The present application also provides a computer storage medium, wherein the computer storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0045] As described above, the present application provides a firmware testing method, device, electronic device and readable storage medium, which creates a virtual driver in the kernel space of the operating system, wherein the virtual driver simulates the hardware function of the memory controller, deploys a command monitoring component in the user space of the operating system, and the command monitoring component establishes a communication link with the virtual driver in the kernel space through the system call interface, compiles the firmware package in the user space of the operating system, generates an executable firmware package, and transmits the firmware package to the virtual driver in the kernel space through the communication link, performs functional verification of the firmware package through the virtual driver, and feeds back the verification result to the command monitoring component. Based on the feedback result, the firmware code is iteratively modified in the user space until the firmware function meets the preset requirements. In the firmware testing solution provided by the present application, there is no need for physical burning, so the firmware development results can be evaluated online. At the same time, it supports real-time compilation and modification, thereby greatly simplifying the test process and improving efficiency. In this way, not only the time cost of repeated burning is reduced, but also the flexibility and response speed of the test are enhanced, which helps to accelerate product iteration and improvement. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] The accompanying drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for describing the embodiments. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without inventive work.

[0047] Figure 1 This is a flowchart of a firmware testing method provided by an embodiment of the present application;

[0048] Figure 2 This is a schematic diagram of the structure of a firmware testing device provided by an embodiment of the present application;

[0049] Figure 3 It is a structural diagram of the smart terminal provided in an embodiment of the present application.

[0050] The purpose of this application, as well as its functional features and advantages, will be further described in conjunction with the embodiments and with reference to the accompanying drawings. The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and the accompanying text are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of this application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0051] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0052] It should be noted that, in this document, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, components, features, and elements with the same name in different embodiments of the present application may have the same meaning or different meanings, and their specific meanings need to be determined by their explanation in the specific embodiment or further combined with the context of the specific embodiment.

[0053] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0054] In the subsequent description, the use of suffixes such as "module", "component" or "unit" to represent elements is only for the purpose of facilitating the description of the present application and has no specific meaning. Therefore, "module", "component" or "unit" can be used interchangeably.

[0055] The following is a detailed description of the embodiments involved in this application. It should be noted that the order of description of the embodiments in this application does not limit the priority order of the embodiments.

[0056] The embodiments of the present application provide a firmware testing method, apparatus, storage medium, and electronic device for use in a virtual machine system. Specifically, the firmware testing method of the embodiments of the present application can be performed by an electronic device or a server, wherein the electronic device can be a terminal. The terminal can be an electronic device such as a smartphone, a tablet computer, a laptop computer, a touch screen, a game console, a personal computer (PC), a personal digital assistant (PDA), etc. The terminal can also include a client, which can be a media player client or an instant messaging client, etc.

[0057] In one embodiment, a firmware testing method includes: creating a virtual driver in the kernel space of an operating system, the virtual driver simulating the hardware functions of a memory controller; deploying a command monitoring component in the user space of the operating system, the command monitoring component establishing a communication link with the virtual driver in the kernel space via a system call interface; compiling a firmware package in the user space of the operating system to generate an executable firmware package, and transmitting the firmware package to the virtual driver in the kernel space via a communication link; performing functional verification of the firmware package via the virtual driver, feeding back the verification results to the command monitoring component, and iteratively modifying the firmware code in the user space based on the feedback results until the firmware functions meet preset requirements. Through the collaboration of the virtual driver and the command monitoring component, online development and testing of FTL firmware can be achieved without physical burning, thereby significantly reducing the development cycle and hardware dependency costs.

[0058] See also Figure 1 , Figure 1 This is a flowchart of a firmware testing method provided in an embodiment of the present application. The specific process of the firmware testing method can be as follows:

[0059] 101. A virtual driver is created in the kernel space of the operating system, where the virtual driver simulates the hardware function of the memory controller.

[0060] Among them, the virtual driver is used to simulate the functions of the solid-state drive controller. The Kernel-Mode Driver Framework (KMDF) is a high-level abstraction layer provided by Microsoft for developing Windows kernel-mode drivers. It is built on the Windows kernel and provides driver developers with a series of classes, methods, and services to help developers develop kernel-mode drivers more conveniently, efficiently, and safely. KMDF is used to develop virtual drivers. With the help of KMDF, the virtual driver simulates the hardware environment of the solid-state drive (SSD) controller, simulates the NVMe protocol stack, NAND Flash operations, and FTL (Flash Translation Layer) logic. KMDF provides a basic framework and functional interface for the virtual driver, such as the creation of device objects, the processing of I / O requests, and the management of events, allowing developers to focus on simulating hardware functions and implementing firmware logic without paying too much attention to the underlying kernel programming details.

[0061] Kernel space is a part of the operating system's memory space, distinct from user space. In modern operating systems, memory is divided into kernel space and user space. Kernel space has the highest privileges, allowing direct access to the computer's hardware resources, such as the CPU, memory, and I / O devices. The operating system kernel and kernel-mode drivers both run in kernel space.

[0062] Virtual drivers run in kernel space. Because they need to emulate hardware device behavior and directly control and operate hardware resources, they must run in kernel space and obtain sufficient permissions. For example, emulating NAND flash read, write, or erase operations requires direct access to the physical address of the storage device, which is only possible in kernel space. Furthermore, the kernel space runtime environment ensures the stability and efficiency of virtual drivers, preventing interference from user space programs.

[0063] For example, you can use the Windows Driver Kit (WDK) in conjunction with Visual Studio for development. The WDK provides the header files, library files, and compilation tools required for kernel-mode driver development, while Visual Studio is used for code writing and project management. Alternatively, you can use the Kernel-Mode Driver Framework (KMDF), which provides an object-oriented API that simplifies driver development and enhances stability. Compared to the traditional WDM framework, KMDF is easier to maintain and offers better memory management.

[0064] Specifically, use WdfDeviceCreate to create a virtual PCI device representing the memory controller and define the hardware ID (such as PCI\VEN_1234&DEV_5678). Use WdfPciAssignResources to assign virtual I / O ports, memory regions, and interrupt resources. These resources will be mapped to the simulated memory controller functions, thereby emulating hardware resources.

[0065] Furthermore, NVMe command processing functions are developed to simulate the NVMe controller's response to various commands (such as Identify, Read / Write, Admin Command, etc.), thereby simulating the NVMe protocol stack. Virtual NVMe controller registers are created, including Controller Configuration Register, Admin Submission / Completion Queue, etc., for interaction with the firmware. Simulation of NAND Flash operations is implemented, including FTL (Flash Translation Layer) functions such as bad block management and wear leveling. At the same time, a virtual interrupt service routine (ISR) is registered using WdfInterruptCreate, which is triggered when the simulated memory controller needs to respond to an event (such as data transfer completion). A DMA channel is created through WdfDmaEnablerCreate to simulate the data transmission process with NAND Flash and support the efficient movement of bulk data.

[0066] Finally, a shared memory area is created for data exchange between user space and kernel space. The user space command monitoring component writes the compiled firmware code to the shared memory. An event object (Event) is used in conjunction with the shared memory to implement a notification mechanism. When the firmware code is written, an event is triggered using SetEvent. The driver captures the event using WaitForSingleObjectEx and reads the firmware code.

[0067] Through the above steps, the virtual driver can simulate the hardware functions of the memory controller in kernel space, including the NVMe protocol stack, NAND Flash interface, interrupt processing, and DMA transfer. This allows user-space firmware code to be functionally verified without relying on physical hardware, greatly improving SSD firmware development efficiency.

[0068] Optionally, in some embodiments of the present application, the virtual driver simulates the hardware functions of the memory controller by simulating the physical storage space of the flash memory chip using memory mapping technology, dynamically generating a mapping table between logical addresses and physical block addresses based on the FTL rule engine, and simulating the memory controller's interrupt response mechanism and DMA transfer process. Based on this solution, the virtual driver fully replicates the core functions of the SSD controller, ensuring consistency between the test environment and the actual hardware.

[0069] Specifically, the virtual driver creates a contiguous block of system memory in kernel space (for example, using MmAllocateContiguousMemory) as the simulated NAND Flash physical storage space. Using WdfIoResourceListAppendDescriptor, it maps this memory area as the virtual device's I / O resources, simulating the flash memory chip's physical address space. Using WdfPciAssignResources to allocate memory resources, the virtual driver simulates the PCI device's BAR (Base Address Register) and maps the memory area to the user-mode address space for firmware access.

[0070] In addition, the virtual driver implements the core functionality of the FTL (Flash Translation Layer), maintaining a mapping table from logical block addresses (LBA) to physical block addresses (PBA) (as mentioned in the document's "FTL Mapping Table Management"). The mapping table is stored in the simulated DRAM space and supports multi-layer mapping, including block mapping and page mapping.

[0071] When the firmware performs a write operation, the virtual driver dynamically allocates physical blocks based on the wear leveling algorithm and updates the mapping table. When there are insufficient free blocks, dirty blocks (containing valid and invalid data) are selected for data migration and block erasure, and the mapping relationship is updated.

[0072] Use WdfInterruptCreate to create a virtual interrupt object and register an interrupt service routine (ISR). When a simulated flash memory operation (such as read, write, or erase) completes or an exception occurs, the driver triggers an interrupt through WdfInterruptQueueDpcForIsr to notify the firmware. Use WdfDmaEnablerCreate to configure a DMA channel to support bulk data transfers.

[0073] 102. A command monitoring component is deployed in the user space of the operating system. The command monitoring component establishes a communication link with the virtual driver in the kernel space through a system call interface.

[0074] The command monitoring component (CMD MonitorAPP) is a .NET application running in user space and is developed using a C++ / CLI hybrid programming model. This component provides a graphical interface and a command line interface for managing, monitoring, and debugging virtual drivers in kernel space. Specifically, it integrates a compiler tool chain to compile the user-written FTL firmware code into an executable format and transfer it to the kernel space. In addition, it encapsulates the NVMe command set, sends test commands to the virtual driver, and receives the execution results. At the same time, the kernel driver's operation log is captured through ETW (Event Tracing for Windows) to display the firmware execution status and performance indicators in real time.

[0075] In addition, the command monitoring component communicates with the virtual driver through the device IOCTL (I / O Control Code). The virtual driver registers the device object (such as \\.\VirtualNVMeDrive), and the user space accesses the device through the CreateFile and DeviceIoControl functions. The IOCTL interface is used to transmit control commands (such as loading firmware, querying status), which is characterized by simple implementation and high security, but high latency (suitable for low-frequency control instructions). To achieve efficient data transmission, the virtual driver creates a shared memory area in the kernel space (using ZwCreateSection) and passes the handle to the user space through the device object. The command monitoring component maps the shared memory to its own address space through MapViewOfFile, and directly reads and writes data (such as firmware code and large amounts of test data).

[0076] Kernel event objects (Events) are used in conjunction with shared memory to achieve synchronization. When shared memory data is ready, the driver triggers the event using SetEvent, and the user space waits for the event using WaitForSingleObject, achieving low-latency notification.

[0077] The firmware loading process is as follows:

[0078] The command monitoring component compiles the firmware code and writes the binary data to shared memory. The "Load Firmware" command is sent to the virtual driver via IOCTL and an event object is set. After receiving the command, the virtual driver reads the firmware code from shared memory and performs a check (such as CRC32). After the check passes, the driver executes the firmware and notifies the user space of the loading completion through an event. The user sends NVMe commands (such as Read / Write) to the virtual driver through the monitoring component. The driver executes the command, writes the result (such as data, status code) to the shared memory, and triggers an event. The monitoring component captures the event, reads the result from the shared memory, and displays it.

[0079] Optionally, in some embodiments of the present application, the communication link is implemented in the following manner:

[0080] The device object is registered in kernel space and receives commands from user space via the IRP (I / O Request Packet) mechanism. The command monitoring component sends test commands to the virtual driver via system calls, including read and write operations, error injection commands, and status query commands. Based on this, a standardized system call interface enables efficient and stable cross-layer communication, supporting real-time debugging and data exchange.

[0081] Among them, the virtual driver uses WdfDeviceCreate in kernel space to create a device object (such as \\.\VirtualNVMeDrive) and registers it with the system through IoCreateDevice. Specifically, it can include setting device characteristics (such as FILE_DEVICE_DISK) and creating device symbolic links for user space programs to access. The driver creates an I / O queue through WdfIoQueueCreate to process IRPs (I / O Request Packets) from user space. The driver can define custom IOCTL codes (such as IOCTL_VIRTUAL_NVME_LOAD_FIRMWARE) and parse and execute user commands through the EvtIoDeviceControl callback function.

[0082] It should be noted that the IOCTL interface is used to transmit control instructions (such as loading firmware and querying status). Its process is as follows:

[0083] User space calls DeviceIoControl to send IOCTL code and parameters.

[0084] The kernel space driver receives the IRP and extracts the IOCTL code and data buffer.

[0085] The driver performs the corresponding operation (such as loading firmware into shared memory) and returns the result through IRP.

[0086] The command monitoring component accesses virtual drive devices through Windows APIs (such as CreateFile and DeviceIoControl). For large amounts of data (such as firmware code and test data), shared memory is used to transfer them, avoiding IOCTL buffer copying. IOCTLs are only used to pass control information (such as shared memory offsets and operation types), while actual data is accessed directly through memory mapping.

[0087] In addition, the driver supports asynchronous IRP processing, marking the request as cancelable through WdfRequestMarkCancelableEx, and using the Completion Queue to return the result to avoid blocking user space.

[0088] 103. Compile the firmware package in the user space of the operating system to generate an executable firmware package, and transmit the firmware package to the virtual driver in the kernel space through a communication link.

[0089] The Command Monitor component (CMD MonitorAPP) integrates a dedicated firmware compilation toolchain (such as GCC or a custom compiler). By configuring environment variables or the built-in compiler, the component can directly call compilation commands (such as gcc-m32-cfirmware.co firmware.o). It executes optimized compilation options for kernel space, such as disabling memory protection (-fno-stack-protector) and generating position-independent code (-fPIC). The Command Monitor component reads user-written firmware source code (such as an FTL algorithm implemented in C), performs syntax checking and preprocessing, and calls the compiler through CreateProcess to generate the target file (.o) and dependent libraries.

[0090] The virtual driver creates a shared memory region in kernel space (using ZwCreateSection) and passes the handle to user space via the device object. The command monitoring component maps the shared memory into its own address space using MapViewOfFile to obtain write permission.

[0091] After compilation is complete, the component calculates the firmware package checksum (such as CRC32) and writes it to the shared memory header. It notifies the virtual driver of the firmware's readiness through an IOCTL (such as IOCTL_VIRTUAL_NVME_LOAD_FIRMWARE), along with the shared memory offset and size. The virtual driver verifies the checksum and loads the firmware if it matches; otherwise, it returns an error code.

[0092] 104. Perform functional verification of the firmware package through a virtual driver, feed back the verification result to the command monitoring component, and iteratively modify the firmware code in the user space based on the feedback result until the firmware function meets the preset requirements.

[0093] The virtual driver receives the firmware binary code through shared memory, verifies the CRC32 checksum, and then loads it into the simulated DRAM space. The firmware entry point (such as the _start function address) is set, and firmware execution is initiated through a kernel thread or callback mechanism. The firmware can interact with the virtual driver and process read and write requests through simulated NVMe command interfaces (such as the Submit Queue and CompletionQueue).

[0094] Key functional simulations: (1) The firmware queries the mapping table based on the logical block address (LBA), and the virtual driver simulates physical block address (PBA) allocation and garbage collection. (2) The virtual driver injects simulated errors (such as NAND bit flips and ECC check failures) to verify the firmware's error recovery capabilities.

[0095] The virtual driver can maintain a state area in shared memory, which contains firmware execution results, performance indicators (such as read and write latency), error counters, etc.

[0096] Optionally, in some embodiments of the present application, the steps of iteratively modifying the firmware code include: commanding the monitoring component to parse log information fed back by the virtual driver to locate firmware defects; invoking a compiler in user space to incrementally compile the firmware code to generate an updated firmware package; and reloading the updated firmware package into the virtual driver via a communication link, triggering a new round of verification. This creates a closed-loop testing process, enabling rapid location and repair of firmware defects.

[0097] The virtual driver uses ETW (Event Tracing for Windows) to record key events during firmware execution, such as command processing time, mapping table changes, and error occurrence points. The status area in shared memory stores real-time statistical data (such as error counts and performance indicators), which are read periodically by the command monitoring component. The compiler output is displayed in real time on the monitoring component interface, and error information (such as syntax errors and undefined symbols) is located using color tags and line numbers. The command monitoring component transfers the new firmware package to the kernel space through shared memory, overwriting the original firmware area. The IOCTL_VIRTUAL_NVME_RELOAD_FIRMWARE command is sent to notify the virtual driver, along with the checksum and size of the new firmware. The virtual driver verifies the checksum, suspends the current operation, loads the new firmware, and resets the status.

[0098] Optionally, in some embodiments of the present application, the virtual driver supports simulation of multiple types of storage devices, the storage devices including USB flash drives, eMMC, UFS, and SSDs that are FTL protocol compatible, and the firmware testing method further includes;

[0099] Dynamically adjust the capacity, interface protocol (such as SATA, NVMe), and performance indicators of the simulated storage device based on preset parameters.

[0100] The virtual driver uses memory mapping technology to simulate the physical storage space of a flash memory chip. By modifying the range and size of the memory mapping, the capacity of the simulated storage device can be dynamically adjusted. For example, when initializing the virtual storage device, the allocated memory size is determined based on preset parameters. To increase the capacity, the allocated memory area is increased and remapped to simulate a larger storage capacity. Conversely, to reduce the capacity, the corresponding memory mapping area is reduced.

[0101] For example, based on the FTL (Flash Translation Layer) rule engine, when the capacity of the simulated storage device changes, the mapping table between logical addresses and physical block addresses also needs to be adjusted accordingly. For example, when the capacity increases, the mapping relationship between logical addresses and newly added physical block addresses needs to be replanned; when the capacity decreases, the logical address mapping corresponding to the reduced physical blocks must be properly handled to ensure correct data reading, writing, and management.

[0102] The virtual driver can simulate different interface protocols, such as SATA and NVMe. According to the preset parameters, the simulated protocol stack is switched within the virtual driver. For example, when the preset parameters specify the use of the NVMe protocol, the virtual driver enables the NVMe protocol stack simulation function, including processing NVMe standard commands (such as Identify, Read / Write, etc.), building data structures such as command queues and completion queues specified by the NVMe protocol, and simulating the behavior and response mechanism of NVMe devices; when switching to the SATA protocol, the relevant functions of the virtual driver are reconfigured according to the SATA protocol specification to process SATA commands and data transmission processes.

[0103] The virtual driver simulates the hardware functions of the memory controller, including interrupt response mechanisms and DMA transfer processes. By adjusting the parameters of these simulated hardware functions, performance indicators can be dynamically adjusted. For example, the bandwidth limit of simulated DMA transfers can be adjusted to simulate different transfer speeds; the interrupt response delay can be modified to simulate different hardware response speeds, thereby affecting overall read and write performance indicators.

[0104] After the firmware code is successfully loaded into the virtual driver, the virtual driver simulates hardware operations based on the loaded firmware code. For example, it simulates the hardware environment of a solid-state drive (SSD) controller, including simulating the NVMe protocol stack to process standard commands (such as Identify, Read / Write, etc.), simulating NAND Flash operations (such as Page Read / Program / Erase), and executing FTL (Flash Translation Layer) logic (such as logical address to physical address conversion, garbage collection, bad block management, etc.).

[0105] During the simulation of hardware operations, the virtual driver will record relevant performance indicators, such as operation delay, throughput, error rate, etc. These performance indicators will be sent to CMD Monitor APP through communication mechanisms such as shared memory + event notification, ETW (Event Tracing for Windows) logs, etc. CMD Monitor APP analyzes the received performance indicators and other relevant information (such as operation results), and compares them with pre-set standards or expected results to verify whether the firmware functions corresponding to the firmware code are normal and meet the design requirements. If anomalies or non-compliance are found, the firmware code can be further debugged and optimized, and then the above loading and verification process is repeated until the firmware functions meet expectations.

[0106] Optionally, in some embodiments of the present application, the step of “performing functional verification of the firmware package through a virtual driver” may specifically include:

[0107] Map the firmware code of the firmware package to the shared memory area through the shared memory mechanism;

[0108] Transfer to the virtual driver through the shared memory area and inform the virtual driver through the notification mechanism;

[0109] The virtual driver verifies the received firmware code and performs firmware function verification based on the firmware code after the verification passes.

[0110] Shared memory is an efficient inter-process communication method that allows different processes (primarily user-space command monitoring applications and kernel-space virtual drivers) to access the same physical memory area. This mechanism avoids multiple data copies between processes, significantly improving data transfer efficiency.

[0111] Because the shared memory area is accessible to both user space and kernel space, the virtual driver can directly read the firmware code from this area, enabling efficient transfer of firmware code from user space to kernel space. This approach reduces data transfer time and overhead compared to other communication methods.

[0112] Simply placing the firmware code into the shared memory area isn't enough; the virtual driver also needs to be informed of the availability of new firmware code. Therefore, a notification mechanism is needed to inform the virtual driver. This can be achieved through methods such as event notifications or ETW (Event Tracing for Windows). For example, when the command monitoring application maps the firmware code into the shared memory area, an event is triggered. The virtual driver listens for this event, and once the event is triggered, it knows that new firmware code needs to be processed.

[0113] After the virtual driver reads the firmware code from the shared memory area, it first verifies it. This verification ensures that the received firmware code has not been corrupted or erroneously transmitted. Common verification methods include calculating hash values ​​or checksums and comparing the calculated results with the expected values ​​provided by the sender. If the verification fails, it indicates a possible problem with the firmware code, and the virtual driver may refuse to load the code and provide an error message.

[0114] After verification, the virtual driver verifies the firmware functionality based on the firmware code. Built on the kernel-mode driver framework, the virtual driver can simulate hardware environments, such as the operation of a solid-state drive (SSD) controller. Following the logic of the firmware code, it simulates various hardware operations, such as command processing in the NVMe protocol stack, read, write, and erase operations in NAND Flash, and FTL (Flash Translation Layer) logic. During the simulation, the virtual driver records performance metrics such as latency, throughput, and error rate, and feeds these metrics back to the command monitoring application. Based on this feedback, the command monitoring application determines whether the firmware functionality meets expectations, thereby completing the verification of the firmware functionality.

[0115] Optionally, in some embodiments of the present application, the step of “performing firmware function verification according to the firmware code after verification is passed” may specifically include:

[0116] After receiving the logical operation sent by the command monitoring component, the virtual driver simulates the hardware operation according to the firmware code;

[0117] The virtual driver records performance indicators during the simulated hardware operation process and sends the performance indicators to the command monitoring component so that the command monitoring component can verify the firmware functions corresponding to the firmware codes.

[0118] When the virtual driver receives logical operation instructions from the command monitoring component, it executes the corresponding operation based on the pre-loaded firmware code. The firmware code defines the hardware device's behavior in various situations, such as how to handle read and write requests and how to store and retrieve data. Based on this firmware code, the virtual driver simulates the operation of the real hardware device at the software level. In the absence of actual hardware, the virtual driver can play the role of the hardware device to respond to and process various operation instructions.

[0119] As the virtual driver simulates hardware operations, it records a series of performance metrics related to these operations in real time. These metrics include, but are not limited to, operation latency (the time it takes from issuing an operation instruction to completing it), throughput (the amount of data processed per unit time), and error rate (the proportion of errors occurring during an operation). By recording these performance metrics, we can fully understand the performance of the virtual driver when simulating hardware operations, as well as the effectiveness of the firmware code in actual operation.

[0120] The virtual driver sends the recorded performance metrics back to the command monitoring component. After the command monitoring component receives these performance metrics, the command monitoring application (CMD Monitor App) analyzes and processes them. By comparing the actual recorded performance metrics with pre-set standards or expected values, the CMD Monitor App can determine whether the firmware functions implemented by the firmware code meet the requirements. For example, if the latency of a read operation is too high or the throughput does not meet expectations, it may mean that there is a problem with the firmware code's logic for handling read operations, which requires further optimization and debugging.

[0121] In this way, the command monitoring application uses performance indicators to verify the firmware functions corresponding to the firmware code, ensuring that the firmware can run normally and efficiently.

[0122] The above completes the firmware testing process of this application.

[0123] In one embodiment, the difference between the functions of the virtual driver of the present application and the conventional kernel virtual driver is specifically described:

[0124] 1. The role of the virtual driver in this application

[0125] In this application, the core role of the virtual driver is to simulate the behavior of the physical SSD controller and provide a virtualized hardware environment for firmware testing. Specific functions include:

[0126] (1) Hardware behavior simulation, simulating the SSD controller's NVMe protocol stack (such as processing Read / Write commands), FTL (Flash Translation Layer) logic, and NAND Flash operations (such as Page Read / Program / Erase).

[0127] (2) Dynamic firmware loading, through shared memory or memory mapping, allows command monitoring components (such as CMDMonitorAPP) to dynamically inject firmware code into the driver without burning ROM.

[0128] (3) Abnormal scenario simulation, actively triggering abnormal events such as bad blocks and power failure recovery to verify the firmware fault tolerance capability.

[0129] (4) Performance monitoring, recording indicators such as latency and throughput, and assisting in optimizing firmware algorithms (such as garbage collection strategies).

[0130] 2. Definition and typical use cases of conventional Windows kernel virtual drivers

[0131] Conventional kernel-mode virtual drivers (Virtual Drivers) do not directly operate physical hardware, but instead simulate devices or provide an abstraction layer. They are commonly used in the following scenarios:

[0132] (1) Virtual device emulation, such as virtual network cards (vNICs in Hyper-V) and virtual disks (VHD drivers), is used in virtualized environments.

[0133] (2) Protocol conversion, such as the USB / IP driver converts the USB protocol into network packets to achieve remote USB device sharing.

[0134] (3) Security isolation, such as sandbox drivers intercepting sensitive operations (file reading and writing, registry access) to protect the host system.

[0135] (4) Debugging and monitoring, such as ProcMon's driver component to monitor process behavior and Wireshark's WinPcap driver to capture network packets.

[0136] 3. The key difference between the two

[0137]

[0138] 4. Examples of technical implementation differences

[0139] (1) Interrupt simulation

[0140] This application: It is necessary to accurately simulate the MSI-X interrupt of the SSD controller and register the ISR (Interrupt Service Routine) and DPC (Deferred Procedure Call) through WdfInterruptCreate to ensure that the firmware can correctly handle asynchronous events.

[0141] Conventional virtual drive: There may be no need to interrupt simulation (for example, the virtual disk driver directly responds to I / O requests).

[0142] (2) User-mode communication

[0143] This application: To reduce latency, shared memory + event notification is used to synchronize firmware status, and IOCTL is used to send control instructions.

[0144] Conventional virtual drivers: usually use only IOCTL or simple Read / Write interfaces (such as virtual serial port drivers).

[0145] 5. Summary

[0146] Commonalities: Both are kernel-mode components, do not rely on physical hardware, and must comply with Windows driver development specifications (such as the KMDF / WDM framework).

[0147] Features: This application's virtual driver focuses on accurate hardware behavior simulation and dynamic firmware interaction, while conventional virtual drivers tend to focus on functional abstraction and system service extension. Understanding this distinction helps avoid overly complex designs (for example, there's no need to implement general virtualization functionality for SSD test drivers).

[0148] As can be seen from the above, the present application provides a firmware testing method, which creates a virtual driver in the kernel space of the operating system. The virtual driver simulates the hardware function of the memory controller, deploys a command monitoring component in the user space of the operating system, and the command monitoring component establishes a communication link with the virtual driver in the kernel space through the system call interface. The firmware package is compiled in the user space of the operating system to generate an executable firmware package, and the firmware package is transferred to the virtual driver in the kernel space through the communication link. The functional verification of the firmware package is performed by the virtual driver, and the verification result is fed back to the command monitoring component. Based on the feedback result, the firmware code is iteratively modified in the user space until the firmware function meets the preset requirements. In the firmware testing solution provided in the present application, there is no need for physical burning, so the firmware development results can be evaluated online. At the same time, it supports real-time compilation and modification, which greatly simplifies the testing process and improves efficiency. In this way, not only the time cost of repeated burning is reduced, but also the flexibility and response speed of the test are enhanced, which helps to accelerate product iteration and improvement.

[0149] To facilitate better implementation of the firmware-based testing method of the present application embodiment, the present application embodiment also provides a firmware testing device. The meanings of the terms are the same as those in the above-mentioned firmware-based testing method, and the specific implementation details can be referred to the description in the system embodiment.

[0150] See also Figure 2 , Figure 2 This is a schematic diagram of the structure of a firmware testing device provided in an embodiment of the present application, wherein the firmware testing device may specifically include a creation module 201, a deployment module 202, a compilation module 203, and a verification module 204, which may be specifically as follows:

[0151] A creation module 201 is configured to create a virtual driver in the kernel space of the operating system, wherein the virtual driver simulates the hardware function of the memory controller;

[0152] A deployment module 202 is configured to deploy a command monitoring component in the user space of the operating system, wherein the command monitoring component establishes a communication link with a virtual driver in the kernel space via a system call interface;

[0153] Compilation module 203, used to compile the firmware package in the user space of the operating system to generate an executable firmware package, and transmit the firmware package to the virtual driver in the kernel space through a communication link;

[0154] The verification module 204 is used to perform functional verification of the firmware package through the virtual driver, feed back the verification results to the command monitoring component, and iteratively modify the firmware code in the user space based on the feedback results until the firmware functions meet the preset requirements.

[0155] The embodiment of the present application provides a firmware testing device, wherein a creation module 201 creates a virtual driver in the kernel space of an operating system, and the virtual driver simulates the hardware function of a memory controller. A deployment module 202 deploys a command monitoring component in the user space of the operating system. The command monitoring component establishes a communication link with the virtual driver in the kernel space through a system call interface. The compilation module 203 compiles the firmware package in the user space of the operating system to generate an executable firmware package, and transmits the firmware package to the virtual driver in the kernel space through a communication link. The verification module 204 performs functional verification of the firmware package through the virtual driver, and feeds back the verification result to the command monitoring component. Based on the feedback result, the firmware code is iteratively modified in the user space until the firmware function meets the preset requirements. In the firmware testing solution provided in the present application, there is no need for physical burning, so the firmware development results can be evaluated online. At the same time, it supports real-time compilation and modification, thereby greatly simplifying the test process and improving efficiency. In this way, not only the time cost of repeated burning is reduced, but also the flexibility and response speed of the test are enhanced, which helps to accelerate product iteration and improvement.

[0156] The embodiment of the present invention further provides an electronic device 500, such as Figure 3 As shown, the electronic device 500 may integrate the above-mentioned firmware testing device, and may further include a radio frequency (RF) circuit 501, a memory 502 including one or more computer-readable storage media, an input unit 503, a display unit 504, a sensor 505, an audio circuit 506, a wireless fidelity (WiFi) module 507, a processor 508 including one or more processing cores, and a power supply 509. It will be understood by those skilled in the art that Figure 3 The structure of the electronic device 500 shown in the figure does not constitute a limitation on the electronic device 500, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0157] The RF circuit 501 can be used to receive and send signals during information transmission or calls. In particular, after receiving downlink information from the base station, it is handed over to one or more processors 508 for processing; in addition, uplink data is sent to the base station. Generally, the RF circuit 501 includes but is not limited to an antenna, at least one amplifier, a tuner, one or more oscillators, a subscriber identity module (SIM) card, a transceiver, a coupler, a low noise amplifier (LNA), a duplexer, etc. In addition, the RF circuit 501 can also communicate with the network and other devices through wireless communication. Wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Message Service (SMS), etc.

[0158] The memory 502 can be used to store software programs and modules. The processor 508 executes various functional applications and information processing by running the software programs and modules stored in the memory 502. The memory 502 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, a target data playback function, etc.); the data storage area may store data created according to the use of the electronic device 500 (such as audio data, a phone book, etc.). In addition, the memory 502 may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory 502 may also include a memory controller to provide the processor 508 and the input unit 503 with access to the memory 502.

[0159] The input unit 503 can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical, or trackball signal input related to user settings and function control. Specifically, in one embodiment, the input unit 503 may include a touch-sensitive surface and other input devices. A touch-sensitive surface, also known as a touch display or touchpad, can detect user touch operations on or near it (for example, operations performed by a user using a finger, stylus, or any other suitable object or accessory on or near the touch-sensitive surface) and drive corresponding connected devices according to a pre-set program. Optionally, the touch-sensitive surface may include a touch detection device and a touch controller. The touch detection device detects the user's touch direction and detects signals generated by the touch operation, transmitting the signals to the touch controller. The touch controller receives the touch information from the touch detection device, converts it into touch point coordinates, and then sends it to the processor 508. It can also receive and execute commands from the processor 508. In addition, touch-sensitive surfaces can be implemented using various types, such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch-sensitive surface, the input unit 503 may also include other input devices. Specifically, other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as a volume control key, a switch key, etc.), a trackball, a mouse, a joystick, and the like.

[0160] The display unit 504 can be used to display information input by the user or information provided to the user and various graphical user interfaces of the electronic device 500, which can be composed of graphics, text, icons, videos and any combination thereof. The display unit 504 may include a display panel. Optionally, the display panel may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch-sensitive surface may cover the display panel. When the touch-sensitive surface detects a touch operation on or near it, it is transmitted to the processor 508 to determine the type of touch event. The processor 508 then provides corresponding visual output on the display panel according to the type of touch event. Although in Figure 3 In the embodiment, the touch-sensitive surface and the display panel are used as two independent components to realize input and output functions, but in some embodiments, the touch-sensitive surface and the display panel can be integrated to realize input and output functions.

[0161] The electronic device 500 may also include at least one sensor 505, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel according to the brightness of the ambient light, and the proximity sensor may turn off the display panel and / or backlight when the electronic device 500 is moved to the ear. As a type of motion sensor, the gravity acceleration sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that recognize the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that the electronic device 500 can also be configured with, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be described in detail here.

[0162] Audio circuit 506, speaker, and microphone provide an audio interface between the user and electronic device 500. Audio circuit 506 can convert received audio data into electrical signals and transmit them to the speaker, which then converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuit 506 and converted into audio data. The audio data is then processed by processor 508 and transmitted via RF circuit 501 to, for example, another electronic device 500. Alternatively, the audio data can be output to memory 502 for further processing. Audio circuit 506 may also include an earphone jack to allow communication between external headphones and electronic device 500.

[0163] WiFi is a short-range wireless transmission technology. The electronic device 500 can help users send and receive emails, browse web pages and access streaming media through the WiFi module 507. It provides users with wireless broadband Internet access. Figure 3 A WiFi module 507 is shown, but it is understandable that it is not an essential component of the electronic device 500 and can be omitted as needed without changing the essence of the invention.

[0164] Processor 508 is the control center of electronic device 500. It connects all components of the phone using various interfaces and circuits. By running or executing software programs and / or modules stored in memory 502 and accessing data stored in memory 502, it executes various functions of electronic device 500 and processes data, thereby providing overall monitoring of the phone. Optionally, processor 508 may include one or more processing cores. Preferably, processor 508 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and application programs, while the modem processor primarily handles wireless communications. It is understood that the modem processor may not be integrated into processor 508.

[0165] The electronic device 500 also includes a power supply 509 (e.g., a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 508 via a power management system, thereby enabling the power management system to manage charging, discharging, and power consumption. The power supply 509 can also include one or more DC or AC power supplies, a recharging system, a power failure detection circuit, a power converter or inverter, a power data indicator, and other arbitrary components.

[0166] Although not shown, the electronic device 500 may also include a camera, a Bluetooth module, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 508 in the electronic device 500 will load the executable files corresponding to the processes of one or more application programs into the memory 502 according to the following instructions, and the processor 508 will run the application programs stored in the memory 502 to implement various functions:

[0167] A virtual driver is created in the kernel space of the operating system, and the virtual driver simulates the hardware functions of the memory controller; a command monitoring component is deployed in the user space of the operating system, and the command monitoring component establishes a communication link with the virtual driver in the kernel space through the system call interface; the firmware package is compiled in the user space of the operating system to generate an executable firmware package, and the firmware package is transferred to the virtual driver in the kernel space through the communication link; the function verification of the firmware package is performed through the virtual driver, and the verification result is fed back to the command monitoring component. Based on the feedback result, the firmware code is iteratively modified in the user space until the firmware function meets the preset requirements.

[0168] In the above embodiments, the description of each embodiment has its own focus. For the part that is not described in detail in a certain embodiment, please refer to the detailed description of the firmware testing method above and will not be repeated here.

[0169] As can be seen from the above, electronic devices in the embodiments of the present invention can evaluate firmware development results online without the need for physical programming. Simultaneously, they support just-in-time compilation and modification, greatly simplifying the testing process and improving efficiency. This approach not only reduces the time and cost of repeated programming but also enhances testing flexibility and responsiveness, helping to accelerate product iteration and improvement.

[0170] Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be accomplished by instructions, or by controlling related hardware through instructions. The instructions may be stored in a computer-readable storage medium and loaded and executed by a processor.

[0171] To this end, an embodiment of the present application further provides a storage medium on which a plurality of instructions are stored, wherein the instructions are suitable for loading by a processor to execute the steps in the above-mentioned firmware testing method.

[0172] The specific implementation of the above operations can be found in the previous embodiments and will not be repeated here.

[0173] The storage medium may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0174] Since the instructions stored in the storage medium can execute the steps in any firmware testing method provided in the embodiments of the present invention, the beneficial effects that can be achieved by any firmware testing method provided in the embodiments of the present invention can be achieved. Please refer to the previous embodiments for details and will not be repeated here.

[0175] The firmware testing method, device, system, and storage medium provided in the embodiments of the present invention are introduced in detail above. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method and core ideas of the present invention. At the same time, for those skilled in the art, according to the ideas of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the contents of this specification should not be understood as limiting the present invention.

Claims

1. A firmware testing method, characterized in that: include: Creating a virtual driver in a kernel space of an operating system, the virtual driver emulating hardware functions of a memory controller; Deploy a command monitoring component in the user space of the operating system, wherein the command monitoring component establishes a communication link with the virtual driver in the kernel space through a system call interface; Compiling the firmware package in the user space of the operating system to generate an executable firmware package, and transmitting the firmware package to the virtual driver in the kernel space through the communication link; Functional verification of the firmware package is performed through the virtual driver, and the verification result is fed back to the command monitoring component. Based on the feedback result, the firmware code is iteratively modified in the user space until the firmware function meets the preset requirements.

2. The firmware testing method according to claim 1, wherein: The steps of simulating the hardware function of the memory controller by the virtual driver include: Simulate the physical storage space of flash memory chips through memory mapping technology; Dynamically generate a mapping table between logical addresses and physical block addresses based on the FTL rule engine; Simulate the interrupt response mechanism and DMA transfer process of the memory controller.

3. The firmware testing method according to claim 1, wherein: The communication link is achieved in the following ways: Register the device object in kernel space and receive instructions from user space through the IRP mechanism; The command monitoring component sends test commands to the virtual driver through system calls, including read and write operations, error injection instructions, and status query instructions.

4. The firmware testing method according to claim 1, wherein: The step of iteratively modifying the firmware code includes: The command monitoring component parses the log information fed back by the virtual driver to locate firmware defects; Call the compiler in the user space to perform incremental compilation of the firmware code to generate an updated firmware package; The updated firmware package is reloaded into the virtual driver via the communication link, triggering a new round of verification.

5. The firmware testing method according to claim 1, wherein: The virtual driver supports the simulation of multiple types of storage devices, including USB flash drives, eMMC, UFS, and SSD FTL protocols. The firmware testing method further includes: Dynamically adjust the capacity, interface protocol (such as SATA, NVMe), and performance indicators of the simulated storage device based on preset parameters.

6. The firmware testing method according to claim 1, wherein: The method further comprises: In the mass production stage, the verified firmware package is converted into a hardware burning format through tools; Use mass production tools to burn the firmware package to the physical storage device.

7. The firmware testing method according to claim 1, wherein: The performing functional verification of the firmware package by the virtual driver includes: Mapping the firmware code of the firmware package to the shared memory area through a shared memory mechanism; Transmitting the data to the virtual driver through the shared memory area and informing the virtual driver through a notification mechanism; The received firmware code is verified by the virtual driver, and firmware function verification is performed according to the firmware code after the verification passes.

8. The firmware testing method according to claim 7, wherein: The performing of firmware function verification according to the firmware code after the verification is passed includes: The virtual driver simulates the hardware operation according to the firmware code after receiving the logical operation sent by the command monitoring component; The virtual driver records performance indicators during the simulated hardware operation process and sends the performance indicators to the command monitoring component so that the command monitoring component can verify the firmware function corresponding to the firmware code.

9. The firmware testing method according to claim 8, wherein: The virtual driver records performance indicators during the simulated hardware operation process and sends the performance indicators to the command monitoring component so that the command monitoring component verifies the firmware function corresponding to the firmware code, including: After the virtual driver adjusts the recorded performance indicators into data in a preset format, the adjusted performance indicators are written into the shared memory area, and an event signal is sent to the command monitoring component based on an event notification mechanism; When the command monitoring component receives the event signal, it reads a performance indicator from the shared memory area and verifies the firmware function corresponding to the firmware code based on the read performance indicator.

10. A firmware testing device, characterized in that: include: Creating a module for creating a virtual driver in a kernel space of an operating system, wherein the virtual driver simulates a hardware function of a memory controller; A deployment module is used to deploy a command monitoring component in the user space of the operating system, wherein the command monitoring component establishes a communication link with the virtual driver in the kernel space through a system call interface; A compiling module, configured to compile the firmware package in the user space of the operating system to generate an executable firmware package, and transmit the firmware package to the virtual driver in the kernel space via the communication link; A verification module is used to perform functional verification of the firmware package through the virtual driver, feed back the verification result to the command monitoring component, and iteratively modify the firmware code in the user space based on the feedback result until the firmware function meets the preset requirements.

11. The firmware testing device according to claim 10, wherein: The creation module is used to: Simulate the physical storage space of flash memory chips through memory mapping technology; Dynamically generate a mapping table between logical addresses and physical block addresses based on the FTL rule engine; Simulate the interrupt response mechanism and DMA transfer process of the memory controller.

12. The firmware testing device according to claim 10, wherein: The communication link is achieved in the following ways: Register the device object in kernel space and receive instructions from user space through the IRP mechanism; The command monitoring component sends test commands to the virtual driver through system calls, including read and write operations, error injection instructions, and status query instructions.

13. The firmware testing device according to claim 10, characterized in that: The step of iteratively modifying the firmware code includes: The command monitoring component parses the log information fed back by the virtual driver to locate firmware defects; Call the compiler in the user space to perform incremental compilation of the firmware code to generate an updated firmware package; The updated firmware package is reloaded into the virtual driver via the communication link, triggering a new round of verification.

14. The firmware testing device according to claim 9, wherein: The virtual driver supports the simulation of multiple types of storage devices, including USB flash drives, eMMC, UFS, and SSD FTL protocols. Also includes; Dynamically adjust the capacity, interface protocol (such as SATA, NVMe), and performance indicators of the simulated storage device based on preset parameters.

15. The firmware testing device according to claim 10, wherein: Also includes: In the mass production stage, the verified firmware package is converted into a hardware burning format through tools; Use mass production tools to burn the firmware package to the physical storage device.

16. The firmware testing device according to claim 10, wherein: The verification module is used to: Mapping the firmware code of the firmware package to the shared memory area through a shared memory mechanism; Transmitting the data to the virtual driver through the shared memory area and informing the virtual driver through a notification mechanism; The received firmware code is verified by the virtual driver, and firmware function verification is performed according to the firmware code after the verification passes.

17. The firmware testing device according to claim 16, wherein: The performing of firmware function verification according to the firmware code after the verification is passed includes: The virtual driver simulates the hardware operation according to the firmware code after receiving the logical operation sent by the command monitoring component; The virtual driver records performance indicators during the simulated hardware operation process and sends the performance indicators to the command monitoring component so that the command monitoring component can verify the firmware function corresponding to the firmware code.

18. The firmware testing device according to claim 17, wherein: The virtual driver records performance indicators during the simulated hardware operation process and sends the performance indicators to the command monitoring component so that the command monitoring component verifies the firmware function corresponding to the firmware code, including: After the virtual driver adjusts the recorded performance indicators into data in a preset format, the adjusted performance indicators are written into the shared memory area, and an event signal is sent to the command monitoring component based on an event notification mechanism; When the command monitoring component receives the event signal, it reads a performance indicator from the shared memory area and verifies the firmware function corresponding to the firmware code based on the read performance indicator.

19. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the firmware testing method according to any one of claims 1 to 9 are implemented.

20. A readable storage medium, characterized in that The readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the firmware testing method according to any one of claims 1 to 9.

Images