Developing Test Code for x86
wiley
I am looking for information on hardware testing code
development. The current code is written in C. The main
thing I want to do is improve testing coverage. That is...
stress the chipsets, North/Southbridge, x86 CPU, memory,
IO, video, audio, serial and USB.
I have found loads of info on software testing and "basic"
hardware information. I have met with some of the
chipset venders and requested their testing methods.
They agreed to provide feedback and I hope to have
that soon. I am hoping to find API's for proven procedures
and OS independent.
Currently the devices run a POSIX based RTOS but will
include Win32 so I will be porting the code.
TIA,
Steve
Adam Anderson
information aswell.
I can supply some pascal Serial hardware interogation routines.
wiley wrote:
--
TUNRA Industrial Electronics Division
1st Floor IDC Building
University Drive Callaghan
NSW 2308 Australia
Tel: (+61 2) 4967 1811
Fax: (+61 2) 4967 4946
EMail: aand...@mail.newcastle.edu.au
URL: http://www.newcastle.edu.au/tunra/tied/
MarcW
start.
I will be interested in how you will test low-level hardware with the
test code running within an OS, especially Windows (Win32) which
restricts access to most of the hardware as part of its desire to keep
applications from interfering with each other and the OS.
Typically, hardware diagnostics code does not run under an OS. If it
does, the test code (in some, most? cases) is a joke, since by the time
the POST, BIOS, OS boot, OS, has run and loaded, quite a bit of the
hardware in the system is running OK otherwise you would not be able to
ask the OS to load your program and have it do so.
There are exceptions (which I why I didn't say 'all' above).
I have written hardware diagnostics and PC-DOS was sufficient to use to
load my programs because once my program was loaded it was easy to take
over the machine and have access to whatever hardware I needed and to
not have to worry about an OS interfering or upsetting the test,
possibly causing failures to be reported where there were none or
failing to detect and report real failures.
(Although in one case I didn't have the luxury of using DOS but had to
implement a test program and modify the boot sector loader program to
boot and load some very special test code to even bypass PC-DOS).
In some cases (memory and video cards) the test code resided in ROM and
was invoked during the POST and ran before the OS was loaded, even
before most of the POST ran. In testing system boards, CPU cards, the
test code resided in ROM. Even this requires the hardware work to some
level otherwise even code in ROM will not be loaded correctly and
executed.
The test programs loaded by DOS were real programs, test programs, but
were geared at testing hardware not completely used by the OS during
boot up. They were used to verify the boards had no manufacturing
defects (though they were also used in some cases to qualify parts when
it became necessary to seek other vendors for components) prior to
shipping the hardware to the customers.
Sincerely,
MarcW.
Mark Leyden
the BIOS to see what areas of the hardware were covered by the existing
POST. Any areas that were not fully covered have been re-written. (This
requires a BIOS licence...)
MarcW <marc....@wordnet.att.net> wrote in message
news:3824E1AC...@wordnet.att.net...
> Getting reference manuals for the chip sets you want to test is a good
> start.
>
> I will be interested in how you will test low-level hardware with the
> test code running within an OS, especially Windows (Win32) which
> restricts access to most of the hardware as part of its desire to keep
> applications from interfering with each other and the OS.
This is a problem with NT, as the protected mode prevents access to the
hardware from the application layers. The answer is to write a Device Driver
to provide the necessary interface between the application layer and the
hardware - requires a DDK.
> Typically, hardware diagnostics code does not run under an OS. If it
> does, the test code (in some, most? cases) is a joke, since by the time
> the POST, BIOS, OS boot, OS, has run and loaded, quite a bit of the
> hardware in the system is running OK otherwise you would not be able to
> ask the OS to load your program and have it do so.
>
> There are exceptions (which I why I didn't say 'all' above).
One of those being the monitoring of hardware...
The testing we are implementing is broken into three areas:
1. Manufacturing Diagnostics (more than likely not to ship in the final
unit)
2. BIOS or POST Diagnostics (will execute on power up)
3. Online Diagnostics (will run in the background or initiated by the user
under NT)
The diagnostics approach for each of these have subtle differences - all
depends on the goals of the testing...
Regards,
Mark.
wiley
>
> 1. Manufacturing Diagnostics (more than likely not to ship in the final
> unit)
So you have them change the BIOS on the line? If the BIOS passes off
to the OS, most hardware must be there so that would be the logical place
to put the tests. Unfortunally, that won't work for our system. Our current
tests are mostly of the verification type using system calls with QNX then
deleted at the end of the line.