Intel® is a trademark or registered trademark of Intel Corporation or its subsidiaries in the United States and other countries.
Java™ and all other Java-based marks are trademarks or registered trademarks of Oracle America, Inc. in the U.S. and other countries.
Microsoft®, Windows® and Windows Me® are registered trademarks of Microsoft Corporation; and Windows XP™ is a trademark of
Microsoft Corporation.
PICMG®, CompactPCI®, AdvancedTCA™ and the PICMG, CompactPCI and AdvancedTCA logos are registered trademarks of the PCI
Industrial Computer Manufacturers Group.
UNIX® is a registered trademark of The Open Group in the United States and other countries.
Notice
While reasonable efforts have been made to assure the accuracy of this document, Artesyn assumes no liability resulting from any
omissions in this document, or from the use of the information obtained therein. Artesyn reserves the right to revise this document
and to make changes from time to time in the content hereof without obligation of Artesyn to notify any person of such revision or
changes.
Electronic versions of this material may be read online, downloaded for personal use, or referenced in another document as a URL to
an Artesyn website. The text itself may not be published commercially in print or electronic form, edited, translated, or otherwise
altered without the permission of Artesyn.
It is possible that this publication may contain reference to or information about Artesyn products (machines and programs),
programming, or services that are not available in your country. Such references or information must not be construed to mean that
Artesyn intends to announce such Artesyn products, programming, or services in your country.
Limited and Restricted Rights Legend
If the documentation contained herein is supplied, directly or indirectly, to the U.S. Government, the following notice shall apply
unless otherwise agreed to in writing by Artesyn.
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (b)(3) of the Rights in
Technical Data clause at DFARS 252.227-7013 (Nov. 1995) and of the Rights in Noncommercial Computer Software and
Documentation clause at DFARS 252.227-7014 (Jun. 1995).
Contact Address
Artesyn Embedded Technologies Artesyn Embedded Technologies
Marketing CommunicationsLilienthalstr. 17-19
2900 S. Diablo Way, Suite 19085579 Neubiberg/Munich
Tempe, Arizona 85282Germany
The MOTLoad Firmware Package User’s Manual provides information on the MOTLoad
firmware. It is intended to be used in conjunction with a specific Artesyn board level product,
on which this firmware resides, such as the MVME5500, MVME3100, MVME6100, MVME7100,
ATCA-F102, and ATCA-C110. This manual provides general information on how to use the
firmware, as well as a detailed description of each command. It also provides information on
special features provided by MOTLoad (see Appendices).
This manual is divided into the following chapters and appendices.
Chapter 1, Introduction, includes an overview of the MOTLoad firmware, a brief description
of the firmware’s implementation and memory requirements, command types, utility
applications and tests
Chapter 2, Using MOTLoad, provides instructions on how to interact with the firmware
including a description of the command line interface, encompassing command line help
and command line rules; command history buffer, encompassing pseudo-VI Mode;
command line execution modes and MOTLoad manual page formats.
Chapter 3, MOTLoad Commands, provides a list of all current MOTLoad commands followed
by a detailed description of each command.
Appendix A, MOTLoad Non-Volatile Data, provides a description of the various types of non-
volatile data: VPD, GEV and SPD. Explanations and examples of existing VPD and GEV
commands are also provided. SPD is not covered at this time.
Appendix B, Remote Start, describes the remote interface provided by MOTLoad to the host
CPU via the backplane bus, which allows the host to obtain information about the target
board, download code and/or data, modify memory, and execute a downloaded program.
Appendix C, VME Configuration Parameters, describes how to manage VME configuration
parameters for VME-based products.
Appendix D, Auto Boot, provides information on how to auto boot an operating system
where no console is required.
Appendix E, Safe Start and Alternate Boot Image, describes MOTLoad’s Safe Start
mechanism and Alternate Boot Image support that enable customers to recover from
inadvertent board configurations.
Appendix F, Related Documentation, lists various documents related to specific devices and
industry specifications that are used in conjunction with the MOTLoad product.
June 2004A Standard Error Codes and Devices section was added to Chapter 2.
The following tests and commands were added to Chapter 3:
testThermoOp, testThermoQ, testThermoRange, csb csh csw and devShow.
A note was added to all memory tests, for example, testRam, specifying
how the memory is tested.
An error message field was added to applicable MOTLoad commands in
Chapter 3, MOTLoad Commands.
A warning was added to testDisk about being destructive.
The following commands were deleted from Chapter 3: mpuFork,
mpuShow, mpuSwitch, testFlash, testI2cRomRd, testI2cRomRdWr,
testUsbOscillator, and testUsbVok.
A Reserved GEVs section was added to Appendix A.
Auto boot instructions were added as an appendix, Appendix D, Auto Boot
July 2003The MOTLoad prompt throughout this document was changed to a generic
MOTLoad> from a specific product prompt, which will vary depending upon
which product was purchased.
Some command descriptions were modified and added to Chapter 3, as well
as corrections to font and text throughout to reflect more accurately screen
displays.
MOTLoad is a PowerPC firmware package developed for Artesyn’s Single Board Computers
(SBCs). The first boards using MOTLoad employ a Marvell GT64260A bridge. Subsequent
products will use MOTLoad in conjunction with the most recent industry designed bridge
devices. MOTLoad is continuously being developed and extended to support newly developed
Artesyn products. When new features are added and changes are made, this document will be
updated.
The main purpose of the MOTLoad firmware package is to serve as a board power-up and
initialization package, and to serve as a vehicle from which user applications can be booted.
Although MOTLoad was not specifically designed as a diagnostics application, the test suites
and the individual tests (with their various options) provide the user with a significant amount
of information that can be used for debug and diagnostic purposes. To use the MOTLoad
firmware package successfully, the reader should have some familiarity with the product and
firmware methodology.
Chapter 1
MOTLoad is controlled through an easy to use, UNIX-like, command line interface. Its format
was designed with the application-oriented needs of the end user in mind. Consequently, the
MOTLoad software package is similar to that of many end-user applications designed for the
embedded market, such as the currently available real-time operating systems. Functionally,
this design allows MOTLoad to detect typical system level product devices.
1.1.1MOTLoad Implementation and Memory Requirements
The implementation of MOTLoad and its memory requirements are product specific. Each of
the Artesyn SBCs are offered with a wide range of memory (for example, DRAM, external
cache, and flash). Typically, the smallest amount of onboard DRAM that an SBC has is 32 MB.
Each supported Artesyn product line has its own unique MOTLoad binary image(s). Currently
the largest MOTLoad compressed image is less than 1 MB. During board initialization, the
MOTLoad image is decompressed into DRAM, where it executes. A MOTLoad decompressed
image can be as large as 2.5 MB.
1.1.2MOTLoad Commands
MOTLoad supports two groups of commands (applications): utilities and tests. Both types of
commands are invoked from the MOTLoad command line in a similar fashion. Beyond that,
MOTLoad utilities and MOTLoad tests are distinctly different.
The definition of a MOTLoad utility application is very broad. Simply stated, it is a MOTLoad
command that is not a MOTLoad test. Typically, MOTLoad utility applications are applications
that aid the user in some way. From the perspective of MOTLoad, examples of utility
applications are: configuration, data/status displays, data manipulation, help routines,
data/status monitors, and so on.
Operationally, MOTLoad utility applications differ from MOTLoad test applications in several
ways:
Only one utility application may be operating at any given time (that is, multiple utility
applications can not be executing concurrently).
Utility applications may interact with the user. Most test applications do not.
1.1.4MOTLoad Tests
A MOTLoad test application determines whether or not the hardware meets a given standard.
Test applications are validation tests. Validation is conformance to a specification. Most
MOTLoad tests are designed to directly validate the functionality of a specific SBC subsystem
or component. It is possible for a board's component to fail in the user application but pass
specification conformance. These tests validate the operation of such SBC modules as:
dynamic memory, external cache, NVRAM, real time clock, and so on.
All MOTLoad tests are designed to validate functionality with minimum user interaction. Once
launched, most MOTLoad tests operate automatically without any user interaction. There are
a few tests where the functionality being validated requires user interaction (that is, switch
tests, interactive plug-in hardware modules, and so on). Most MOTLoad test results (errordata/status-data) are logged, not printed. Test results are not preserved and therefore not
available to user applications subsequent to their execution. All MOTLoad tests/commands are
described in detail in Chapter 3, MOTLoad Commands.
All devices that are available to MOTLoad for validation/verification testing are represented by
a unique device path string. Most MOTLoad tests require the operator to specify a test device
at the MOTLoad command line when invoking the test.
A listing of all device path strings can be displayed through the devShow command. If a SBC
device does not have a device path string it is not supported by MOTLoad and can not be
directly tested. There are a few exceptions to the device path string requirement, like testing
RAM, which is not considered a true device and can be directly tested without a device path
string. Refer to the devShow command page in this manual for more information.
Most MOTLoad tests can be organized to execute as a group of related tests (a test suite)
through the use of the testSuite command. The expert operator can customize their
testing by defining and creating a custom test suite(s). The list of built-in and user defined
MOTLoad test suites, and their test contents, can be obtained by entering: testSuite –d at
the MOTLoad prompt. All test suites that are included as part of a product specific MOTLoad
firmware package are product specific. For more information refer to the testSuite
command page in this manual.
Test results and test status are obtained through the testStatus, errorDisplay, and
taskActive commands. Refer to the appropriate command page(s) in this manual for more
information.
This chapter describes various command line characteristics, as well as the MOTLoad Manual
Page Format.
Interaction with MOTLoad is performed via a command line interface through a serial port on
the SBC, which is connected to a terminal or terminal emulator (for example, Window’s
Hypercomm). The default MOTLoad serial port settings are: 9600 baud, 8 bits, no parity.
2.1.1Command Line Interface
The MOTLoad command line interface is similar to a UNIX command line shell interface.
Commands are initiated by entering a valid MOTLoad command (a text string) at the MOTLoad
command line prompt and pressing the carriage-return key to signify the end of input.
MOTLoad then performs the specified action. The MOTLoad command line prompt is shown
below.
Chapter 2
Note: The generic command prompt designation of MOTLoad is for documentation purposes
only. The exact command prompt designation is determined by the product being purchased,
for example, MVME6100, MVME5500, and so on.
If an invalid MOTLoad command is entered at the MOTLoad command line prompt, MOTLoad
displays a message that the command was not found.
Example:
MOTLoad>
mytest
"mytest" not found
MOTLoad>
If the user enters a partial MOTLoad command string that can be resolved to a unique valid
MOTLoad command and presses the carriage-return key, the command will be executed as if
the entire command string had been entered. This feature is a user input shortcut that
minimizes the required amount of command line input. MOTLoad is an ever changing firmware
package, so user input shortcuts may change as command additions are made.
Copyright: Motorola Inc. 1999-2003, All Rights Reserved
MOTLoad RTOS Version 2.0
PAL Version 1.1 RM01
Mon Mar 10 12:01:28 MST 2003
Example:
MOTLoad>
ver
Copyright: Motorola Inc. 1999-2003, All Rights Reserved
MOTLoad RTOS Version 2.0
PAL Version 1.1 RM01
Mon Mar 10 12:01:28 MST 2003
If the partial command string cannot be resolved to a single unique command, MOTLoad will
inform the user that the command was ambiguous.
Example:
MOTLoad>
te
"te" ambiguous
MOTLoad>
2.1.2Command Line Help
Each MOTLoad firmware package has an extensive, product specific, help facility that can be
accessed through the help command. The user can enter help at the MOTLoad command line
to display a complete listing of all available tests and utilities.
Option arguments immediately follow (no spaces) the option
All commands, command options, device tree strings, and so on are case sensitive
Example:
MOTLoad> flashProgram –d/dev/flash0 –n00100000
2.1.4Command History Buffer
MOTLoad saves command line inputs into a command history buffer. Up to 128 previously
entered commands can be recalled, edited, and reentered at the command line. Once the
desired command appears on the command line it can be re-executed by pressing the
carriage-return key.
2.1.5pseudo-Vi Mode
MOTLoad supports a pseudo-VI editor command recall through the ESC and the j and k keys.
Ty pi ng
ESC
and then
k
moves backwards through the history command buffer and displays the preceding
commands. Typing
ESC
and then
j
moves forward through the history command buffer and displays the more recent commands.
After the
key may be pressed as often as needed to bring up the desired command from the command
history buffer.
2.1.6Command Line Execution Modes
MOTLoad utilities such as help always execute in the foreground. MOTLoad tests can be
executed in the foreground (sequentially) or in the background (concurrently) as background
tasks.
Using MOTLoad
Note Not all tests can execute in background mode. As an example, cache tests must run in
the foreground.
When a sequential test starts executing in the foreground, no new MOTLoad tests can execute
until the current test running in the foreground is complete. This does not apply to background
tests.
Example:
MOTLoad>
testRam
In concurrent test mode, each test gets a time sliced share of the CPU execution time. The
amount of user control over the background task time slicing operations is determined by the
underlying OS. The operator specifies concurrent test execution by ending the test command
line with the ampersand (&) character (prior to the carriage-return). The MOTLoad command
prompt reappears after a concurrent test is started.
After the MOTLoad prompt reappears, another test or utility may be started (in the foreground
or background execution mode) as long as it does not interfere (use the same computer
resources) with the operations of other test(s) running in background mode. The test
execution status of a test(s) running in background mode can be monitored through the use
of the taskActive and testStatus commands. Refer to the appropriate man pages for
more details.
2.1.7Copying/Transferring MOTLoad Images
Flash images can be copied between memory and flash, or between flash banks, by the use of
the flashProgram utility. Extreme care should be taken in this process to ensure that
accidental overwriting of the bootloader code and/or MOTLoad does not occur. It is advised
that you never program the boot block of the active flash bank (the one from which the board
was booted). This ensures that the bootloader image is never overwritten by flashProgram.
The bootloader resides in the boot block of each flash bank. If both images have been
overwritten, the board may be unbootable. Further, since flashProgram is a component
within MOTLoad, the user is not able to reprogram (reflash) the boot block to effect recovery.
28
The utility flashShow indicates which flash bank is the active flash bank and provides its base
address and size. Also refer to the Programmer’s Reference Guide and/or Installation and Use
manual for your board.
The boot block is the last (highest address) 1 MB of a flash bank. flashProgram writes to an
offset from the base (lowest address) of a flash bank. The source for the image being
programmed can be any addressable memory; for example, SDRAM, NVRAM, or flash.
All MOTLoad command pages follow the format described below.
Name
This field names the test or utility as it would appear on the MOTLoad command line. It also
provides a description of the command, for example:
errorDisplay - displays the Contents of the MOTLoad Test Error Status Table
Synopsis
This field shows command line usage or syntax of a command, test, or utility. This consists
of the name of the command, test or utility, and a list of all possible arguments/options, for
example:
errorDisplay [-eP*] [-nP*] [-sP*]
If an argument is optional, it is enclosed in a set of braces [ ], otherwise it is required.
If an asterisk (*) or other symbol follows an option, another argument is required with that
option.
The asterisk (*) symbol means that a number of valid numeric base conversion option
arguments are possible. Refer to the table titled Number Base Specifiers for more
information.
An attempt has been made to standardize the meaning of option arguments but the exact
meaning of an option and its arguments is test specific. Exact option information can be
displayed through the use of the help command or by referring the appropriate man page.
Parameter
This field describes each argument and option of the command, for example:
-a P*: Executive Process/Task Identifier of Entry to Display
-n P*: Number of Entries to Display
-s P*: Specific Entry Number (1 to n) to Display
Example
This field shows how the command, test, or utility is typically used. The command line
invocation of the command, test, or utility and the subsequent displayed results are
shown. In some cases extensive examples are provided, for example: