| 61 | A MOTLoad test application determines whether or not the hardware |
| 62 | meets a given standard. Test applications are validation tests. Validation is |
| 63 | conformance to a specification. Most MOTLoad tests are designed to |
| 64 | directly validate the functionality of a specific SBC subsystem or |
| 65 | component. These tests validate the operation of such SBC modules as: |
| 66 | dynamic memory, external cache, NVRAM, real time clock, etc. |
| 67 | All MOTLoad tests are designed to validate functionality with minimum |
| 68 | user interaction. Once launched, most MOTLoad tests operate automatically without any user interaction. There are a few tests where the |
| 69 | functionality being validated requires user interaction (that is, switch tests, |
| 70 | interactive plug-in hardware modules, etc.). Most MOTLoad test results |
| 71 | (error-data/status-data) are logged, not printed. All MOTLoad |
| 72 | tests/commands have complete and separate descriptions (refer to the |
| 73 | MOTLoad Firmware Package User’s Manual for this information). |
| 74 | All devices that are available to MOTLoad for validation/verification |
| 75 | testing are represented by a unique device path string. Most MOTLoad |
| 76 | tests require the operator to specify a test device at the MOTLoad |
| 77 | command line when invoking the test. |
| 78 | A listing of all device path strings can be displayed through the devShow |
| 79 | command. If an SBC device does not have a device path string, it is not |
| 80 | supported by MOTLoad and can not be directly tested. There are a few |
| 81 | exceptions to the device path string requirement, like testing RAM, which |
| 82 | is not considered a true device and can be directly tested without a device |
| 83 | path string. Refer to the devShow command description page in the |
| 84 | MOTLoad Firmware Package User’s Manual. |
| 85 | |
| 86 | |