Driver testing and debugging

Testing the hardware

In addition to testing and debugging the driver, you must also test the hardware device itself. While the area of developing, testing, and debugging the hardware is beyond the scope of this documentation, the following guidelines are suggested:

Very early in the development process, you should get the equipment and do some basic tests on its integrity, such as ensuring that it can be powered up without problems and access registers on the peripherals. If the device does not pass these tests, it can be returned to the vendor for further development while you write the driver.
Write a stand-alone board exerciser that runs at the firmware level (not under the operating system) to detect hardware bugs. This is an interactive program that is used to exercise a board under controlled conditions. The device should pass these tests before you attempt to test it with your driver.
Test the diagnostics that are hard-coded on the board by corrupting the hardware and booting the system. Check that the diagnostics detect the corruption and that the messages are sufficient to indicate the maintenance that is required. Power-up diagnostics should verify sanity at a gross level. Demand-phase diagnostics should be used for more extensive checks on the board, such as identifying marginal or intermittent errors.

To ensure that the kernel-device interface is functioning properly, write a simplified driver that contains dummy routine calls for the basic, non-interrupt handling routines. For DDI 8 drivers, code dummy routines for _load(D2), config(D2), open(D2), close(D2), and biostart(D2) routines. For DDI drivers prior to version 8 and all ODDI drivers, code dummy routines for the init(D2), start(D2), open(D2), close(D2), read(D2), and write(D2) routines. For example:

   qq_open()
   
       {
       cmn_err(CE_CONT,"Open routine entered\n");
       }

This simplified driver should contain an ioctl(D2) routine that gives user program control to each control bit in the control status register (CSR). This lets you test each hardware function and ensure that the hardware is performing in the proper operational sequence.