145 lines
6.3 KiB
HTML
145 lines
6.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
|
|
<HTML VERSION="2.0">
|
|
<HEAD>
|
|
<!-- WEBMAGIC VERSION NUMBER="2.0.1" -->
|
|
<!-- WEBMAGIC TRANSLATION NAME="ServerRoot" SRC="/var/www/htdocs/" DST="/" -->
|
|
<!-- WEBMAGIC TRANSLATION NAME="ProjectRoot" SRC="./" DST="" -->
|
|
<TITLE> Modular IDE: General Information</TITLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<P><A HREF="modular.html"><IMG SRC="/images/diags.gif" WIDTH="100" HEIGHT="75" BORDER="2" SGI_FULLPATH="/var/www/htdocs/images/diags.gif"> </A></P>
|
|
<H1>Modular IDE: General Information </H1>
|
|
<HR>
|
|
<H3>Problem with current IDE </H3>
|
|
<P>IDE is program that executes diagnostic tests for various hardware pieces
|
|
in standalone mode. Currently, IDE consists of one large binary that contains
|
|
a multitude of tests for various hardware pieces and the library functions
|
|
that are needed to perform these tests. The main problem with the current
|
|
IDE is that it is difficult to maintain because no one developer understands
|
|
all of the various hardware tests contained in IDE. Also, since no one organization
|
|
really "owns" IDE, it is difficult to keep this large IDE program bug free. </P>
|
|
<P></P>
|
|
<H3>Solution with Modular IDE </H3>
|
|
<P>The solution is to modularize IDE so that IDE is split into a Core IDE binary
|
|
which contains the common library code needed to run IDE and the various
|
|
IDE modules needed to test the actual hardware pieces and products. With
|
|
this solution, different groups (like audio, cpu, graphics, video, etc)
|
|
can develop, test, and ship their IDE modules individually. </P>
|
|
<P><!-- CORE ------------------------------------------------------></P>
|
|
<H3>Core IDE </H3>
|
|
<P>Core IDE is the main IDE binary which contains the library functions (ie
|
|
like libsc & libsk) needed to run and load the various IDE modules. Core
|
|
IDE is loaded at a fixed memory location. Core IDE runs IDE tests by loading
|
|
an IDE module at another fixed address, executing the IDE module's script
|
|
(a user will still be able to get an IDE prompt while executing a module),
|
|
and finally unloading the IDE module. <!-- Modules ------------------------------------------------------></P>
|
|
<H3>IDE Modules </H3>
|
|
<P>Here is a list of envisioned IDE modules. Note that these loosly correspond
|
|
to today's *_diagcmds files. For example, in stand/arcs/ide/IP22 we have
|
|
the following diagcmds files: cpu_diagcmds, gr2_diagcmds, mgras_diagcmds,
|
|
ng1_diagcmds, opt_diagcmds, vid_diagcmds, vino_diagcmds ... </P>
|
|
<OL>
|
|
<LI>module_cpu: CPU tests / tlb / cache / builtin IO
|
|
<LI>module_audio: audio tests
|
|
<LI>module_graphics: graphics tests
|
|
<LI>module_video: video tests
|
|
<LI>module_compression: compression tests
|
|
<LI>module_manufacturing: tests for manufacturing
|
|
<LI>etc ...
|
|
</OL>
|
|
<P><!-- Looking for IDE Modules -------------------------------------></P>
|
|
<H3>Where will Core IDE look for IDE modules ? </H3>
|
|
<P>After the Core IDE is loaded, it will try to figure out what IDE modules
|
|
exist as follows: </P>
|
|
<OL>
|
|
<LI>If Core IDE was loaded from disk:
|
|
<OL>
|
|
<LI>Core IDE will search the disk for all files named module_*. /stand, /usr/stand,
|
|
and the volume header will be searched. The first place that is searched
|
|
is the same as where Core IDE came from (we know from which device Core
|
|
IDE was loaded ...)
|
|
<LI>In production mode (ie field), Core IDE will execute a core script which
|
|
is responsible for executing the found modules in some order.
|
|
<LI>In development mode (ie shell), Core IDE will list the found module_* modules
|
|
and go to the ">>" prompt. User will then have a "load" command to execute
|
|
IDE modules. "list" and "info" commands will also be offered (described <A HREF="#newcmds">below</A>).
|
|
</OL>
|
|
<LI>If Core IDE was loaded via bootp() over the net, we will automatically go
|
|
into development mode (ie shell). The user can then use the "load" command
|
|
to execute IDE modules over the net. Note: we can't get a listing of IDE
|
|
modules since bootp/tftp dont support directory listings.
|
|
</OL>
|
|
<P><!-- New builtin Core IDE commands -------------------------></P>
|
|
<H3><A NAME="newcmds">New builtin Core IDE commands </A></H3>
|
|
<DL>
|
|
<DT>load:
|
|
<DD>loads and executes an IDE module
|
|
<DT>list:
|
|
<DD>lists all module_* modules on same device as Core IDE was loaded from
|
|
<DT>list <device>:
|
|
<DD>same as list but on arbitrary device. Note: for bootp(), could try to "poll"
|
|
for a standard list of modules ...
|
|
<DT>info module_name:
|
|
<DD>Read the beginning of an IDE module and get & print some string that explains
|
|
what this module does, what tests it contains, and <A HREF="#version">versioning</A> information.
|
|
</DL>
|
|
<P><!-- Loading -------------------------------------></P>
|
|
<H3>Loading Mechanism </H3>
|
|
<P>IDE modules will be loaded & executed in a non-relocatable one-at-a-time
|
|
fashion above the IDE core: </P>
|
|
<PRE>
|
|
^
|
|
| +------------------
|
|
| | IDE module
|
|
| +------------------
|
|
| <- space for future Core IDE growth ...
|
|
| +------------------
|
|
| |
|
|
| | Core IDE
|
|
| |
|
|
| +------------------
|
|
|
|
memory
|
|
|
|
<P> The details of how the Core loads a module and resolves the
|
|
module's references to Core symbols is described in another
|
|
<A HREF="load.html">document</A>.
|
|
|
|
</PRE>
|
|
<H3>Comments on Loading: </H3>
|
|
<DL>
|
|
<DT>Why non-relocatable ?
|
|
<DD>Some IDE modules (like memory tests) need to know where in memory they reside
|
|
cause they trash memory during testing ...
|
|
<DT>Problem with one-at-a-time loading:
|
|
<DD>Suppose that a tlb() test resides in the module_cpu module and that a graphics
|
|
test gr1() resides in the module_graphics module. Then the following will
|
|
not be possible when executing the module_graphics module:
|
|
<PRE>
|
|
<CODE> while (1) {</CODE>
|
|
<CODE> tlb;</CODE>
|
|
<CODE> gr1;</CODE>
|
|
<CODE> }</CODE>
|
|
</PRE>
|
|
<P>The workaround would be to also include the tlb() test in the module_graphics
|
|
module or to allow SOME tests (good candiates would be tests which are used
|
|
by other modules) to be included in Core IDE ... </P>
|
|
<P>Note that one could also make sure that something like the following will
|
|
work: </P>
|
|
<P></P>
|
|
<PRE>
|
|
<CODE> while (1) {</CODE>
|
|
<CODE> load module_cpu; tlb;</CODE>
|
|
<CODE> load module_graphics; gr1;</CODE>
|
|
<CODE> }</CODE>
|
|
</PRE>
|
|
<P></P>
|
|
</DL>
|
|
<P><!-- Versioning -------------------------------------></P>
|
|
<H3><A NAME="version">Versioning </A></H3>
|
|
<P><B>TO BE DONE </B></P>
|
|
<HR>
|
|
<ADDRESS><A HREF="http://gork/mail-form.html">stojanof@engr.sgi.com</A></ADDRESS>
|
|
</BODY>
|
|
</HTML>
|