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:
In order to accommodate for the storage of data generated by one or more MOTLoad
commands that are not given a specific memory path or location, MOTLoad employs a
temporary memory buffer, known as the User Download Buffer.
The size of the User Download Buffer is 2 MB. Commands will fail if the user attempts to load
more than 2 MB into the buffer. In cases where more than 2 MB are needed, the user should
use the malloc command (malloc <size>) to create a buffer of suitable size.
Typing malloc <size> on the command line where size is the number of bytes requested
causes MOTLoad to allocate an area of RAM that can be used by the user. The address of the
start of the RAM buffer area is returned to the user. An address of "0" indicates that the
request failed.
Using MOTLoad
2.4Standard Error Codes and Devices
This section describes error message formats and a generalized listing of error number (errno)
values. As with any code application, MOTLoad is continually being revised and new error
messages may appear.
In some cases, the message format may vary slightly from the above. For these messages, the
format and meaning is identified under the Error Messages section for the affected command.
When the operation attempts to open a device but encounters a failure during the open
process, the open message is displayed and identifies the complete device name (for example,
/dev/ide0/hdisk0).
When a general IOCTL command fails, the ioctl value identifies the failing I/O operation of a
specific device type; for example, block, terminal, tape, and so on. For an example set of IOCTL
codes, refer to the IOCTL Codes (Block) table (below). It is not necessary to know all the codes
for each type of device since the individual error message sections define the meaning of each
ioctl error message.
Error numbers (errno) can be derived from either the standard I/O error codes as listed in the
Standard Error Codes (errno) table or from driver-/device-specific errors. Error codes unique to
either the driver or the device are greater than 0x00010000. Currently, only the standard I/O
error codes are used for utilities.
2.4.3Standard Error Codes (errno)
Using MOTLoad
The following table lists the standard error codes (errno):
IOSTD_ERROR_DEVICE_NOT_FOUND1/* device not found */
IOSTD_ERROR_FD_TABLE_FULL2/* file descriptor table full */
IOSTD_ERROR_FD_NOT_FOUND3/* file descriptor not found */
This chapter lists the current valid MOTLoad commands. The remainder of the chapter
describes each command in detail.
3.1.1MOTLoad Command List
The following table provides a list of all current MOTLoad commands. Products supported by
MOTLoad may or may not employ the full command set. Typing help at the MOTLoad
command prompt displays all commands supported by MOTLoad for a given product.
Note The command prompt designation for this manual is MOTLoad; however, the command
prompt for your specific version of MOTLoad is the product designator for your particular
board, for example, MVME6100, MVME5500.
as—provides access to the one-line assembler. By default, the memory location to place the
user entered PowerPC assembly instructions is the User Download Buffer.
Synopsis
as [-a]
Parameter
-a Ph: Assembly Address (Default = User Download Buffer)
Example
The following example depicts a typical result of entering the as command.
MOTLoad Commands
MOTLoad> as –a00560000
00560000 00000000 word 0x00000000? lwz r3, 0x0(x3)
-- the above line will be replaced with the following -00560000 80630000 lwz r3,0x0(r3)
Error Messages
Error messages returned from the as command take one of the following forms depending
upon whether it is a known error.
Assembler Error: <error_message>
where <error_message> is one of the following:
An Operand has a Length of Zero
Unknown Mnemonic
Excessive Operand(s)
Missing Operand(s)
Operand Type Not Found
Operand Prefix
Operand Address Misalignment
Operand Displacement
Operand Sign Extension
Operand Data Field Overflow
Operand Conversion
Operand Sign Extension
Operand Data Field Overflow
Operand Conversion
bdTempShow—displays the current board temperature(s). The information displayed may
vary dependent upon the hardware.
Synopsis
bdTempShow
Parameters
none
Example
The following example shows a typical result of entering the bdTempShow command:
44
MOTLoad> bdTempShow
Cpu TAU Temp=030C Therm Sensor = 27.0C
MOTLoad>
The TAU value has a variation of 25C; however, the DS1621 thermal sensor has an accuracy
of 0.5C. This sensor is usually located on the secondary side of the board, centered near the
lower edge.
blkVe—verifies the number of blocks, specified by the user, between the source device to the
destination device. This command only operates on ’block devices’.
Synopsis
blkVe -a -b [-n] [-s]
Parameters
-a Ps: Device Name of Source
-b Ps: Device Name of Destination
-n Ph: Number of Blocks (Default = 1)
-s Ph: Starting Block Number (Default = 0)
Example
The following example indicates a typical display when using the blkVe command.
blkWr—writes the number of blocks, specified by the user, from the memory address to the
specified device. This command only operates on ’block devices’.
Synopsis
blkWr [-d] [-m] [-n] [-s] [-t]
Parameters
-d Ps: Device Name (Default = /dev/fd0)
-m Ph: Memory Address (Default = User Download Buffer)
-n Ph: Number of Blocks (Default = 1)
-s Ph: Starting Block Number (Default = 0)
-t 0: Display Elapsed Time
54
Example
The following example indicates a typical display when using the blkVe command.
MOTLoad> blkWr -d/dev/ide0/hdisk0 -n20 -t
blkWr(): number of bytes = 00004000 (&16384)
blkWr(): number of micro-seconds = 00000283 (&643)
blkWr(): bytes/second = (not measurable)
bvb, bvh, bvw—verifies the contents of a memory block for a specific data pattern, as specified
by the command-line options. Only non-matching data patterns are displayed.
Synopsis
bvb/bvh/bvw -a -b -d [-i]
Parameters
-a Ph: Starting Address of Block
-b Ph: Ending Address of Block
-d Ph: Verify Data Pattern
-i Ph: Fill Data Increment (Default = 00000000/0000/00)
MOTLoad Commands
Example
The following example indicates a typical display when using the bsb, bsh, and bsw
commands.
cdDir—displays the contents of a CDROM that is formatted with an ISO9660 file system (8.3
naming convention). Caveats: Symbolic links are not supported. ISO9660 extensions are not
supported (e.g., RockRidge).
Synopsis
cdDir [-ddevicename] [-fpathname] [-v]
Parameters
-d Ps: Device Name (Default = /dev/ide0/cdrom1)
-f Ps: File Name. (specify preceding ’*’ for wildcard)
-v 0: Full Listing.
60
Example
The following example indicates a typical display when using the cdDir command.
cdGet—copies (GETs) the specified file from a CDROM that is formatted with an ISO9660 file
system (8.3 naming convention). Caveats: Symbolic links are not supported. ISO9660
extensions are not supported (for example, RockRidge). If the specified file name matches
more than one file on the CD, the first matching file encountered is loaded.
Synopsis
cdGet [-ddevicename] -ffilename [-laddress]
Parameters
-d Ps: Device Name (Default = /dev/ide0/cdrom1)
-f Ps: File Name.
-l Ph: Load Address (Default = User Download Buffer.
62
Example
The following example indicates a typical display when using the cdGet command.
csUserAltBoot—checksums user boot images specified in the alternate boot image header at
the beginning of files to be programmed into flash memory. As part of the process, the
command executes validity checks to insure the integrity of the boot image header before
calculating the checksum. Files up to six megabytes can use this command to provide the
checksum needed by MOTLoad in order to pass program execution to the user defined image.
Synopsis
csUserAltBoot [-a]
Parameters
-a Ph: Starting Address (Default = User Download Buffer)
Example
The following examples show typical results of entering the csUserAltBoot command.
-p Ps: PReP Boot Device Type List (Format Example = Floppy/CDROM/Disk)
-v 0 : Verbose Mode
70
Note When the -p option is specified, the values specified by the -f option are ignored.
Example
The following example indicates a typical display when using the diskBoot command.
MOTLoad> diskBoot -f/dev/fd0\l\boot.bin
---the above method can also be accomplished by defining a GEV variable as
follows--MOTLoad> gevEdit mot-boot-path
(Blank line terminates input.)
/dev/fd0\l\boot.bin
docBoot—Boots the kernel image stored in the binary partition of the Disk on Chip (DoC).
Note The DoC binary partitions can be read or programmed only in multiples of their block
size. Hence, the size specified should be a multiple of the block size. The block size can be
obtained by using the -v option. For example, in case of M-System H1 DoC, the block size is 512
KB.
Synopsis
docRead [-a] [-d] [-e] [-p] [-s] [-x] [-v]
Parameters
MOTLoad Commands
-a Ph: Boot File Load Address (Default=User Buffer)
-d Ps: DoC Device Name (Default=/dev/doc0)
-e Ph: Boot File Execution Address (Default=0)
-p Ph: Binary Partition Number (Default=0)
-s Ph: Size (Default=12 MB)
-x Ph: Start Block in Current Binary Partition (Default=0)
-v 0: Verbose Mode
Example
The following example indicates a typical display when using the docBoot command.
Found a 1024 MB DiskOnChip on address 0xA0000000
Found a Binary partition with:
- Partition Size is 41943040
- Unit size is 524288
Read successful
Section Loaded: Address =01923000, Size =000041FC, Name =.text
Section Loaded: Address =01928000, Size =00288000, Name =.data
Using kernel command line from mot-/dev/doc0-0-bootargs=console=ttyS1,9600 root =/dev/tffsa1 rw
docProgram—Programs an image residing in the RAM into the binary partition of the DoC.
Note The Disk On Chip (DoC) binary partitions can be read or programmed only in multiples
of their block size. Hence, the size specified should be a multiple of the block size. The block size
can be obtained by using the -v option. For example, in case of M-System H1 DoC, the block size
is 512 KB.
Synopsis
docProgram [-a] [-d] [-p] [-s] [-x] [-v]
Parameters
MOTLoad Commands
-a Ph: Source Address (Default=User Buffer)
-d Ps: DoC Device Name (Default=/dev/doc0)
-p Ph: Binary Partition Number (Default=0)
-s Ph: Size (Default=12 MB)
-x Ph: Start Block (Default=0)
-v 0 : Verbose Mode
Example
The following example indicates a typical display when using the docProgram command.
docRead—reads the contents of the specified binary partition into the RAM.
Note The Disk On Chip (DoC) binary partitions can be read or programmed only in multiples
of their block size. Hence, the size specified should be a multiple of the block size. The block size
can be obtained by using the -v option. For example, in case of M-System H1 DoC, the block size
is 512 KB.
Synopsis
docRead [-a] [-d] [-p] [-s] [-x] [-v]
Parameters
MOTLoad Commands
-a Ph: Load Address (Default=User Buffer)
-d Ps: DoC Device Name (Default=/dev/doc0)
-p Ph: Binary Partition Number (Default=0)
-s Ph: Size (Default=12 MB)
-x Ph: Start Block (Default=0)
-v 0: Verbose Mode
Example
The following example indicates a typical display when using the docRead command.
downLoad—decodes and downloads an S-Record from the host into the target MOTLoad
machine’s memory. (Refer to Using MOTLoad on page 23.) The serial-port device name (device
path file name) can be the full path name to the S-Record. This file in MOTLoad must have read
permission enabled.
Note that S-Records cannot be downloaded through the console port.
Synopsis
downLoad [-a] [-b] [-d]
Parameters
-a P*: Destination Memory Address (Default = User Download Buffer)
-b Pd: Baud Rate (Default = 9600)
-d Ps: Device Path Name (Default = /dev/com2)
78
Example
The following example indicates a typical display when using the downLoad command.
ds—provides access to the one-line disassembler. By default, the memory location to
disassemble PowerPC assembly instructions is the User Download Buffer.
Synopsis
ds [-a] [-n]
Parameters
-a Ph: Disassembly Address (Default = User Download Buffer)
-n Pd: Number of Instructions (Default = 8)
Example
80
The following example indicates a typical display when using the ds command.
errorDisplay—displays the MOTLoad test error status table (log). The error status table
contains test error information and task related information from previously executed tests
that failed and logged the failure information in the error log. Most of the fields in this table are
described below. The user can, through the -a option (in hexadecimal values), and the -n and s options, (in decimal values), specify which error log entry(ies) to display. In addition to the
information below, each error displays a unique test specific message.
Synopsis
errorDisplay [-a] [-n] [-s]
Parameters
-a P*: Executive Process/Task Identifier of Entry to Display
execProgram—executes a program that has been downloaded into the memory of a SBC
running MOTLoad firmware. This allows the user to run executable programs without having
to overwrite any existing programs in the Flash ROM. Immediately prior to transferring control,
MOTLoad:
>> disables network interfaces
>> disables all interrupts
>> locks, flushes, invalidates, and disables any enabled caches
>> clears the MPU, MSR register
>> clears the MPU.SPR275 register (ECD pointer)
>> illuminates the board fail light
Synopsis
execProgram [-e] [-l] [-s] [-x]
Parameters
-e Ph: Execution Address Offset (Default = 0)
-l Ph: Load Address (Default = User Download Buffer)
-s Ph: Program/Object Size (Default = 2 MB)
-x Ph: Execution Argument (Default = 0)
Example
The following example indicates a typical display when using the execProgram command.
flashLock—sets sector protection on specified flash device on a given Artesyn single-board
computer. Protection is set on a per-sector basis on the device’s flash ROM as specified by the d, -n, and -o parameters.
Synopsis
flashLock [-d] [-i] [-n] [-o] [-v]
Parameters
-d Ps : Flash Memory Device Name (Default = /dev/flash0)
1.Size option (-n) is specified in bytes. Devices typically set protection at the sector level.
Minimum number of bytes that are set is determined by sector size and Flash
configuration.
2.Since not all Flash devices support a software protection mechanism, not all MOTLoad
products include the command
flashProgram—flashes an image into the specified Flash device on a given Artesyn single
board computer. The image is flashed (written) into the device’s flash ROM as specified by the
-d, -n, and -s parameters.
Synopsis
flashProgram [-d] [-i] [-n] [-o] [-s] [-v]
Parameters
-d Ps : Flash Memory Device Name (Default = /dev/flash0)
-i 0 : Disable Interactive Confirmation
-n Ph : Number of Bytes to Program (Default = $00100000)