1. Device Function Drivers
2. Device Filter Drivers
3. Software Drivers
4. File System Filter Drivers
5. File System Drivers
There are two models: WDM model and WDF model.
WDM model(Kernel-mode driver framework)
WDM drivers are trusted kernel-mode components, so the system provides limited checks on driver input. In contrast, the WDF model focuses on the requirements of the driver, and the framework library handles most of the interaction with the system.
WDF Model
The Windows Driver Framework (WDF) model focuses on driver requirements. The framework library handles most interactions with the system, simplifying driver development. By providing an automated framework, the WDF model reduces the complexity of low-level operations and improves development efficiency.
Why Does Microsoft Recommend the WDF Model?
Microsoft recommends developers use the WDF model because it provides a more efficient, secure, and maintainable way to develop drivers, especially suitable for newly developed drivers.
Two development methods in the WDF model:
Suitable for scenarios that require direct hardware interaction and have high performance requirements, such as hardware device drivers and file system drivers.
Suitable for drivers for USB devices, external devices, etc., that do not require direct hardware interaction.
Common Development Method: KMDF (Kernel-Mode Driver)
In practical development, KMDF is the most commonly used driver development method. It allows direct access to hardware resources and is suitable for driver development requiring high performance and low latency.
1. VS2022
2. SDK (Download according to the target board system version)
3. Driver Toolkit (WDK)
VS2022 Installation: Select either "Desktop Development with C++" or "Visual Studio Extension Development".
SDK and WDK can be installed via online resources.
Please refer to the following tutorial:
1. Start Visual Studio.
2. Select "Create New Project" or select Project from the File menu.
3. In the right pane of the Create New Project dialog box, select Kernel Mode Driver (KMDF), and then click Next.
4. Enter the project name, location, and solution name, then click Create.
5. Begin writing device-specific code to complete driver development. otherwise, the driver cannot be installed.
During the debugging phase, the target machine needs to be configured in test mode; otherwise, driver installation will fail.
bcdedit /set testsigning on
If you no longer need test mode, you can exit using the following command:
bcdedit /set testsigning off
Copy the compiled driver folder to the target machine.
In the driver folder of the target machine, locate and right-click the XXX.inf file.
Select "Install" to complete the driver installation.
Unlike debugging ordinary applications, driver debugging requires examining the driver's process logs to determine and analyze whether it is functioning correctly.
Microsoft tools are needed:
To install a driver in production mode, it must be signed.
The following are detailed information and steps regarding driver signing to help you successfully perform a production installation after debugging.
Driver Signing Requirements
When installing drivers in Official Mode, the system requires the driver to be signed. Signing can be provided by Microsoft or a third-party organization. Specific signing methods are as follows:
●Advantages: Broad compatibility and trustworthiness, suitable for developers who want to widely distribute drivers.
●Disadvantages: The signing process is cumbersome and usually incurs a fee.
●Advantages: Usually lower cost and simpler process.
●Disadvantages: Compared to Microsoft signing, trustworthiness and compatibility may be slightly inferior.
The price of signing varies depending on the organization providing the service. Microsoft signing is generally more expensive, but third-party signing is more flexible and can be chosen according to needs.
When mounting an external device via the I2C/SPI bus, the device must first be declared in the motherboard's ASL (ACPI Source Language) code.
Only then will the system's Device Manager recognize and display the new device.
The specific device addition process will be detailed in the subsequent I2C/SPI/NFC development section.
Development Phase: Device Injection in Test Mode
During the device debugging and development phase, the target system can be in test mode, where new devices can be added without flashing the BIOS. By injecting device information into the registry, the system can recognize the new device and perform testing.
This process is only effective in test mode.
The following steps are implemented on the target machine
1. Read the BIOS configuration from the registry cache and save it as the DSDT0000.bin file
Open a command prompt (as administrator) and execute the following command:
asl.exe /tab=DSDT /c
2. Decompile the DSDT0000.bin file to generate DSDT0000.dsl (ASL CODE file)
Execute the following command to decompile the file:
.\iasl.exe -ve .\DSDT0000.bin
3. Modify the DSDT0000.dsl file and add new device information
Open the DSDT0000.dsl file and add new device information as needed. Detailed examples of what to add will be provided in the I2C/SPI/NFC development section.
4. Compile the modified DSDT0000.dsl to generate the DSDT0000.aml file.
Compile the file to generate the new AML file:
.\iasl.exe -ve .\DSDT0000.dsl
5. Write DSDT0000.aml to the registry cache.
.\asl.exe /loadtable DSDT0000.aml
6. Enable test mode, ignore signature.
Execute the following command to enable test mode:
Bcdedit /set testsigning on
7. Restart the system.
After restarting the system, the new device will appear in Device Manager for further debugging.
To disable the ASL code and restore the system to its state before the device was added, perform the following steps:
.\asl.exe /loadtable DSDT0000.aml -d
Once the new device is debugged, its information needs to be updated in the BIOS code. Compile and generate the BIOS firmware and re-flash the BIOS to officially add the device to the system.