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.
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 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.
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 ...
After the Core IDE is loaded, it will try to figure out what IDE modules exist as follows:
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 | | | +------------------ memoryThe details of how the Core loads a module and resolves the module's references to Core symbols is described in another document.
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;}
TO BE DONE