Modular IDE: General Information


Problem with current IDE

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.

Solution with Modular IDE

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.

Core IDE

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.

IDE Modules

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 ...

  1. module_cpu: CPU tests / tlb / cache / builtin IO
  2. module_audio: audio tests
  3. module_graphics: graphics tests
  4. module_video: video tests
  5. module_compression: compression tests
  6. module_manufacturing: tests for manufacturing
  7. etc ...

Where will Core IDE look for IDE modules ?

After the Core IDE is loaded, it will try to figure out what IDE modules exist as follows:

  1. If Core IDE was loaded from disk:
    1. 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 ...)
    2. In production mode (ie field), Core IDE will execute a core script which is responsible for executing the found modules in some order.
    3. 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 below).
  2. 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.

New builtin Core IDE commands

load:
loads and executes an IDE module
list:
lists all module_* modules on same device as Core IDE was loaded from
list <device>:
same as list but on arbitrary device. Note: for bootp(), could try to "poll" for a standard list of modules ...
info module_name:
Read the beginning of an IDE module and get & print some string that explains what this module does, what tests it contains, and versioning information.

Loading Mechanism

IDE modules will be loaded & executed in a non-relocatable one-at-a-time fashion above the IDE core:

  ^
  |       +------------------
  |       | IDE module
  |       +------------------
  |                            <- space for future Core IDE growth ...
  |       +------------------
  |       |
  |       | Core IDE
  |       |
  |       +------------------

memory

The details of how the Core loads a module and resolves the module's references to Core symbols is described in another document.

Comments on Loading:

Why non-relocatable ?
Some IDE modules (like memory tests) need to know where in memory they reside cause they trash memory during testing ...
Problem with one-at-a-time loading:
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:
  while (1) {
    tlb;
    gr1;
  }

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 ...

Note that one could also make sure that something like the following will work:

  while (1) {
    load module_cpu; tlb;
    load module_graphics; gr1;
  }

Versioning

TO BE DONE


stojanof@engr.sgi.com