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:
To ensure that the kernel-device interface is
write a simplified driver
that contains dummy routine calls for
the basic, non-interrupt handling routines.
For DDI 8 drivers, code dummy routines for
For DDI drivers prior to version 8
and all ODDI drivers,
code dummy routines for the
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.
This simplified driver should contain an
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.
cmn_err(CE_CONT,"Open routine entered\n");
© 2005 The SCO Group, Inc. All rights reserved.
OpenServer 6 and UnixWare (SVR5) HDK - June 2005