198 lines
5.1 KiB
Plaintext
198 lines
5.1 KiB
Plaintext
SpeedRacer Diagnostics Plan
|
|
---------------------------
|
|
|
|
I. Overview
|
|
|
|
1. Bring-up diags
|
|
|
|
Bringup diagnostics are for the ISD hardware and O/S groups to
|
|
verify the proper operation of new system hardware. In many cases,
|
|
these diags are inappropriate for both manufacturing, and end
|
|
users.
|
|
|
|
|
|
2. Power-on diags
|
|
|
|
Power-on diagnostics are those executed by the boot prom when
|
|
the system is powered-on. These diagnostics are a sanity check
|
|
of the system functionality necessary to boot Irix.
|
|
|
|
|
|
3. Field diags
|
|
|
|
Field diags are directed at field engineers and end users who
|
|
wish to isolate system problems on systems that are unable
|
|
to boot Irix. Current field diags take too long, and include
|
|
many useless legacy tests.
|
|
|
|
We need to determine a small set of field diagnostics that
|
|
exercise most components in the system in a relatively short
|
|
period of time (e.g. 30 minutes). These diagnostics should
|
|
be focused on elements of the system that are difficult to
|
|
test under Irix (e.g. memory and cache), or are needed to boot
|
|
the system, so that more extensive diagnostics can be run.
|
|
|
|
|
|
4. Manufacturing diags
|
|
|
|
We will let manufacturing deal with mfg diagnostics. We will
|
|
make available to them a library of field/bringup diagnostics
|
|
that are used by the O/S group, and a means of building IDE.
|
|
Mfg will have a separate directory on the source tree for
|
|
developing their diagnostics.
|
|
|
|
Of course, we will work with mfg and CSD to determine which
|
|
diagnostics will be part of power-on, and the field version
|
|
of IDE.
|
|
|
|
|
|
5. Miscellaneous
|
|
|
|
The ISD O/S group intends to undertake the redesign of IDE with
|
|
two goals:
|
|
|
|
To provide a more modular implementation of IDE, so diags
|
|
can be added without impacting the size and development of
|
|
the base IDE.
|
|
|
|
To provide a simpler user interface to the base IDE.
|
|
|
|
|
|
II. Tests
|
|
|
|
1. Bring-up diags
|
|
|
|
The execution environment for bring-up diags isn't entirely
|
|
determined, but it will consist of both
|
|
|
|
- Executing IDE diagnostics from a special prom image, and
|
|
- Loading IDE from an external device (Ethernet or SCSI)
|
|
|
|
Power-on diags are a subset of the shipped power-on diags.
|
|
(See (2. Power-on diags) below.) They are run from the prom.
|
|
|
|
Emulation will be the first tool to debug and bring-up diagnostics:
|
|
we do not intend to first simulate the code.
|
|
|
|
The main emulation system will be built in stages, and the
|
|
diagnostic development will reflect that.
|
|
|
|
|
|
A. Main Emulation System Diags
|
|
|
|
Phase 1: R4K, Cache, Memory, Heart, Bridge, Prom, Serial
|
|
|
|
CPU/FPU
|
|
Caches
|
|
No new diags necessary: link existing diags to ide (R4K) [herve]
|
|
|
|
|
|
Memory
|
|
Port of current memory tests [anouchka]
|
|
|
|
ECC
|
|
Port of current ECC tests and design of new heart-specific tests
|
|
[anouchka]
|
|
|
|
Heart
|
|
Level 1 Heart diags [kkn, anouchka]
|
|
|
|
Bridge
|
|
Level 1 Bridge diags [kkn, anouchka]
|
|
|
|
System (Heart/Bridge)
|
|
Level 1 System diags [kkn, anouchka]
|
|
|
|
Phase 2: Same as Phase 1 with SCSI and/or Ethernet
|
|
|
|
SCSI
|
|
New scsi diag [robertn]
|
|
|
|
Ethernet
|
|
New ethernet diag [ddh]
|
|
|
|
PCI
|
|
New tests focused on PCI features [kkn, anouchka]
|
|
|
|
System (Heart/Bridge)
|
|
Level 2 System diags [kkn, anouchka]
|
|
|
|
Phase 3: Same as Phase 2 with Xbow
|
|
|
|
System (Heart/Bridge/Xbow)
|
|
Level 3 System diags [TBD, anouchka]
|
|
|
|
Phase 4: Same as Phase 3 with T5
|
|
|
|
CPU/FPU
|
|
New T5 diags [necessary? port from Shiva?]
|
|
|
|
Caches
|
|
New diags for T5 systems [TBD, dwong]
|
|
|
|
|
|
B. IOC3 Emulation System Diags
|
|
|
|
The IOC emulation is currently planned as a parallel effort,
|
|
separately from the Main Emulation effort.
|
|
|
|
IOC3 [TBD, anouchka]
|
|
|
|
Serial [TBD, dwong]
|
|
|
|
Ethernet [TBD]
|
|
|
|
Keyboard/Mouse [TBD, jeffs]
|
|
|
|
Parallel [TBD, pap]
|
|
|
|
|
|
C. Real System Diags
|
|
|
|
The base diagnostics used for the real power-on are the
|
|
union of all the above diagnostics. There will be a few late
|
|
additions:
|
|
|
|
T5-MP
|
|
|
|
Graphics
|
|
|
|
Audio
|
|
|
|
Other Digital Media
|
|
|
|
|
|
2. Power-on diags
|
|
|
|
A subset of the shipped power-on diags will be used for bring-up.
|
|
Diags needed early are marked with (*).
|
|
|
|
Really early diags - before memory initialization
|
|
|
|
*pon_heart - walking 1 on heart register to verify that the memory
|
|
controller does not have any stuck bit [anouchka]
|
|
*pon_regs - checking the datapath to onboard device registers
|
|
as part of IOC bring-up (needed only later) [anouchka]
|
|
|
|
*pon_addr - walking 0/1 test across address lines [dwong]
|
|
*pon_data - walking 0/1 test across data lines [dwong]
|
|
|
|
More diags (from pon_morediags())
|
|
|
|
pon_graphics - black box to us, except for size/time policing [gfx]
|
|
pon_caches - cache diags [dwong]
|
|
scsi - scsi diags (ctlr, drives, what?) [robertn]
|
|
kbd/mouse ctlr, kbd, mouse - kbd/mouse diags [jeffs]
|
|
|
|
NOTE: in the pon directory, pon_hndlr, pon_io, and pon_subr.s support
|
|
the power on diags but are not diagnostics themselves.
|
|
|
|
|
|
3. Field diags
|
|
|
|
The goal is to add a simple gui to the field diags that would give
|
|
the user an idea of coverage/length before the tests are initiated.
|
|
We will trim the volume of shipped diags to a small extensively
|
|
tested set.
|
|
|