target.nr

vxworks mv2100 vxworks BSP

.SS "VME Access"
VMEbus accesses can be classified as either master or slave.  A master access
is one in which the accessing processor has bus mastership (it owns the bus)
and is addressing resources on another VME board (the slave board).  The
master addresses the off-board resources through a memory mapping mechanism
which assigns portions of the local address space to the various VME address
spaces.  These local memory regions are windows onto the VMEbus.  Each
window is individually configured with a set of base addresses -- one for the
local bus, the other for the VMEbus -- and a window size.

A slave access is one in which slave VME processors allow access to
their resources from the various VME address spaces through slave windows.

The normal VxWorks default is to enable the slave access windows only on
CPU 0, as part of the routine sysProcNumSet().  Otherwise, slave accesses
are normally not permitted.

The default configuration maps all local memory onto VME A32.  There are no A24
or A16 slave windows.

There is no support for the A64/D64 VME extensions.

To disable any VME master or slave window, just set the appropriate
VME_Axx_xxx_SIZE macro (in config.h) to 0.  Only the macros in config.h are
considered user options.  Macros in mv2100.h should not be changed by
the user.

There are two addressing models: the default pseudo-PReP address model and
optional CHRP.  The optional CHRP memory model is not supported.

The following lists the window parameters that the user may change in config.h
for both models:

.CS
    #define VME_A32_MSTR_BUS  0x08000000
    #define VME_A32_MSTR_SIZE 0x08000000  /* (128MB) */
    #define VME_A24_MSTR_BUS  0x00000000
    #define VME_A24_MSTR_SIZE 0x01000000  /* (16MB) */
    #define VME_A16_MSTR_SIZE 0x00010000  /* (64KB) */

    #define VME_A32_SLV_LOCAL LOCAL_MEM_LOCAL_ADRS
    #define VME_A32_SLV_BUS   VME_A32_MSTR_BUS
    #define VME_A32_SLV_SIZE  LOCAL_MEM_SIZE
.CE

DMA support is implemented as a synchronous "VxWorks driver",
that is, the calling task will be blocked until the DMA transfer has
terminated.  However, the driver itself is a polled driver, and it will
not relinquish the CPU waiting for an interrupt; instead, it will enter
a busy loop periodically sampling the DMA transfer status for termination.
A major intended use of this driver is to transfer TCP/IP packets
(packet size approx. 2K).  In light of its' intended use and to keep this
driver as simple as possible, only direct-mode operations will be
implemented, that is, linked-list mode will not be supported.

This driver is strictly non-sharable; however, it contains no guards
to prevent multiple tasks from calling it simultaneously.  It assumes
that the application layer will provide atomic access to this driver
through the use of a semaphore or similar guards.

As a precaution,
it is recommended by the Tundra User's Manual that the calling
task set up a background timer to prevent an infinite wait
caused by a system problem.  Also, tasks transferring large
blocks of data should lower their priority level to allow other
tasks to run, and tasks transferring small blocks of data
should use bcopy() instead of calling this driver.

.SS "PCI Access"
The 32-bit PCI bus is fully supported under the 
.I PCI Local Bus Specification, Revision 2.1. 
The 64-bit extensions are not supported.  All configuration space accesses 
are made with BDF (bus number, device number, function number) format calls 
in the pciConfigLib module.  For more information, refer to the reference
entries 
.I mv2100_pciXxx.

The PCI address mappings are affected by the VME address model selected.  See 
.I SPECIAL CONSIDERATIONS.

.SS "BSP Configuration"
Most BSP configuration values are taken from on-board Vital Product Data
(VPD) and Serial Presence Detect (SPD) serial EEPROMs. If invalid VPD or SPD
information is suspected or reported, defining TOLERATE_CONFIG_ERRORS in
config.h may permit operation using default parameters. The use of
TOLERATE_CONFIG_ERRORS is intended for use during debug only as it hard-codes
non-optimized SDRAM timing and other VPD information. Since the SDRAM timing is
configured by the Bootrom, changing the state of TOLERATE_CONFIG_ERRORS requires
rebuilding the Bootrom image and re-flashing.

.SS "Boot Devices"
The supported boot devices are:

    \f3sm\f1 - shared memory
    \f3dc\f1 - Ethernet (10baseT or 100baseTX)

.SS "Boot Methods"
The boot methods are affected by the boot parameters.  If no password is
specified, RSH (remote shell) protocol is used.  If a password is specified,
FTP protocol is used, or, if the flag is set, TFTP protocol is used.

These protocols are used for both Ethernet and shared memory boot devices.

.SS "ROM Considerations"

Socketed vs. Soldered ROMs

Pins 1 & 2 of Jumper J9 are used to tell the software whether to boot
from the soldered FLASH or not.  If the jumper is installed, the code
executing from the socketed ROMs will jump to the soldered FLASH and
continue execution.  If there is nothing in the socketed ROMs, then
this jump will not occur and the board will not function.

The factory default is to have the jumper installed which selects
the soldered FLASH parts.  To make the VxWorks bootrom code run from
the socketed ROM parts, the jumper must be removed.

The define FLASH_BOOT in config.h must be setup based on which type
of ROM the bootrom will reside in:

if the bootrom is in Soldered Flash then define FLASH_BOOT.
if the bootrom is in Socketed ROM then undef FLASH_BOOT. (default)

Use the following command sequence on the host to re-make the BSP boot ROM:
.CS    
    cd target/config/mv2100
    make clean
    make bootrom_uncmp
    cp bootrom_uncmp.bin /tftpboot/boot.bin
.CE

Power down the board and configure the ROM jumper to select the PPC1-Bug.
Connect the Ethernet and console serial port cables, then power the board back
up.

.SS "Flashing the Boot ROM Using Motorola PPC1-Bug:" 
Before you power-up the MVME2100, make sure the ROM/FLASH jumper (J9) is
set appropriately.  This assumes that the PPC1-Bug resides in the ROM
selected and that the flashing will occur to the other ROM.  To select
the Soldered Flash ROM, install a jumper across pins 1 and 2 of J9.  To
run out of the Socketed ROM, remove the jumper from pins 1 and 2 of J9.

The base addresses of the socketed ROM and soldered FLASH are:
.CS
   Socketed ROM has an address of 0xFFF00000
   Soldered FLASH has an address of 0xFF000000
.CE

At the PPC1-Bug prompt, start the system clock then set up the network transfer
from a TFTP host using `niot'.  To start the system clock, the \f3set\f1
command must be used.  The format is: set MMDDYYhhmm  where MM is month, DD is
day of month, YY is year, hh is hour (24-hour format), and mm is minutes.  This
command starts the system clock and sets the current date and time.

.CS
   PPC1-Bug>set 1016971302
.CE

Using `niot', the Client IP Address, Server IP Address, and Gateway IP Address
must be set up for the user's specific environment:

.CS
   PPC1-Bug>niot
   Controller LUN =00?
   Device LUN     =00?
   Node Control Memory Address =00FA0000?
   Client IP Address      =123.123.10.100? 123.321.12.123
   Server IP Address      =123.123.18.105? 123.321.21.100
   Subnet IP Address Mask =255.255.255.0?
   Broadcast IP Address   =255.255.255.255?
   Gateway IP Address     =123.123.10.254? 123.321.12.254
   Boot File Name ("NULL" for None)     =? .

   Update Non-Volatile RAM (Y/N)? y
   PPC1-Bug>
.CE

The file is transferred from the TFTP host to the target board using
the `niop' command.  Important: You must have a TFTP server running on your
host's subnet for the `niop' command to succeed.  The file name must be set to
the location of the binary file on the TFTP host.  The binary file must be
stored in the directory identified for TFTP accesses, but the file name is
a relative path and does not include the \f3/tftpboot\f1 directory name:

.CS
   PPC1-Bug>niop
   Controller LUN =00?
   Device LUN     =00?
   Get/Put        =G?
   File Name      =? boot.bin
   Memory Address =00004000?
   Length         =00000000?
   Byte Offset    =00000000?

   PPC1-Bug>
.CE

After the file is loaded onto the target, the "pflash" command is used
to put it into socketed ROM or soldered FLASH parts.

To put it into socketed ROM:
.CS
   PPC1-Bug>pflash 4000:fff00 fff00100
.CE

To put it into soldered FLASH:
.CS
   PPC1-Bug>pflash 4000:fff00 ff000100
.CE

When the command is finished, power down the board and configure the ROM
jumper, then power the board back up.

NOTE: The value of FLASH_BOOT in config.h must be set appropriately
for the bootrom image being flashed, otherwise the bootrom
will not execute.  See ROM Considerations for more details on setting
up FLASH_BOOT correctly.

.SH "SPECIAL CONSIDERATIONS"
This section describes miscellaneous information concerning this BSP and its
use.

.SS "Delivered Objects"
The delivered objects are: `bootrom.hex', `vxWorks', `vxWorks.sym', and
`vxWorks.st'.

.SS "Make Targets"
The make targets are listed as the names of object-format files.  Append `.hex'
to each to derive a hex-format file name.

.TS E
exxpand;
=
`bootrom'
`bootrom_uncmp'
`bootrom_res_high'  (`bootrom_res' does not build)
`vxWorks' (with `vxWorks.sym')
`vxWorks_rom'
`vxWorks.st'
`vxWorks.st_rom'
`vxWorks.res_rom_res_low' (`vxWorks.res_rom' does not build)
`vxWorks.res_rom_nosym_res_low' (`vxWorks.res_rom_nosym' does not build)
_
.TE

.SS "Special Routines"
For these boards, the value of the CPU clock speed is read from the Vital
Product Data (VPD) information using the macro MEMORY_BUS_SPEED which is 
defined in mv2100.h.  For example:

.CS
   clkFreqMhz = MEMORY_BUS_SPEED;
.CE

.SS "VME Interrupt Vectors"
Interrupt vectors chosen to generate normal VME interrupts under program
control must be even numbers.  VME interrupt service routines (ISRs) servicing
VME interrupts received by the Universe chip need only be able to service
even vector numbers.

The Universe chip used on this board can be configured to generate VME bus
interrupts in response to DMA status, PCI bus conditions, and by specific
command from software.  During the VME interrupt acknowledge (IACK) cycle,
the STATUS/ID register of the Universe chip transmits an 8-bit interrupt
vector to the VME bus.  The seven most significant bits are the vector number
(hence the need for even vector numbers) and the least significant bit (LSB) is
set according to how the Universe is configured to respond to the IACK cycle.
If the interrupt was generated by software and the IACK cycle is received, the
Universe can be configured to send an acknowledging interrupt (SW_IACK)
back to the software over the PCI bus.  If the SW_IACK interrupt is enabled,
the LSB is set to 0, otherwise, it is set to 1.

Note that, if software specifies an odd number as the interrupt vector to be
transmitted during the IACK cycle, the STATUS/ID register will truncate it to
an even number.  Also, if any interrupting VME device sends an odd vector
number, the vector number returned by the Universe to an ISR is truncated to
an even vector number.  There is no configuration option to compensate for this
feature of the Universe chip.

.SS "Known Problems"
Older generation VME backplanes often do not have slot 1 (the system controller
slot) hard-wired for interrupt acknowledge (IACK) daisy chain operation,
leaving this to be done by a board plugged in to the slot.  Because the
MVME2600 family of Motorola boards does not do this, VME interrupts may not
be sensed by an MVME2600 board used as a system controller in an old VME
backplane.  New VME backplanes usually have the left-most slot P1 connector
hard-wired so that pin A20 (IACK) is connected to A21 (IACKIN).  On old VME
backplanes, the user must add a jumper between pins A20 and A21 on the wire wrap
pins behind the P1 connector of slot 1.

In the routine sysEpicIntHandler (file: kahluaEpic.c), a sysDecDelay call
is required to handle an error condition for Kahlua(MPC8240) Revision 
1.0/1.1 chips (Errata #2 on Kahlua Errata Sheet - Version 1.0.3).  The delay
is needed to prevent the same interrupt from occurring twice.

There is a possibility that during the power on procedure for the board,
the bootrom will hang if the reset button is pressed.  An error message
"Unable to read Vital Product Data" will be displayed on the console.  To
recover from this condition, either re-power the board or hold the reset
button in for a period of 5 seconds.


.SH "BOARD LAYOUT"
The diagram below shows flash EEPROM locations and jumpers relevant to VxWorks
configuration:

For the MVME2100 boards, the debug and 10baseT/100baseTX ports appear on the
front panel.

.ne 4i

.bS
______________________________               ______________________________
|             P1             |    MVME2100   |             P2              |
|                            ----------------                              |
|                          No Transition Module                            |
|                                                                          |
| J2 (SCON)                                                                |
| U                                                                   J9   |
|                                                           +----+  16..15 |
|                                                          X|    |    ..   |
|                                                          U|    |    ..   |
|                                                          2+----+    ..   |
|                                                           +----+    ..   |
|                                                          X|    |    ..   |
|                                                          U|    |    ..   |
|                                                          1+----+   2--1  |
|                                                                          |
|                                                                          |
|                                                                          |
|                                                                          |
|                                                                          |
|                                                                          |
|                                                                          |
|                                                                          |
|                                                                          |
|                          10/100BaseT  Serial                             |
|______________________________-----____-----______________________________|
                       Abort switch *  * Reset switch
.bE
    Key: 
    |   vertical jumper installed
    :   vertical jumper absent
    --  horizontal jumper installed
    ..  horizontal jumper absent
    0   switch off
    1   switch on
    U   three-pin vertical jumper, upper jumper installed
    D   three-pin vertical jumper, lower jumper installed
    L   three-pin horizontal jumper, left jumper installed
    R   three-pin horizontal jumper, right jumper installed

.SH "SEE ALSO"
.tG "Getting Started,"
.pG "Configuration"

.SH "BIBLIOGRAPHY"
.iB "Motorola MVME2100 Series Single Board Computer Programmer's Reference Guide"
.iB "Motorola Computer Group Online Documentation, http://library.mcg.mot.com/mcg/boards"
.iB "Motorola PowerPC 8240RISC Microprocessor User's Manual,"
.iB "Motorola PowerPC Microprocessor Family: The Programming Environments,"
.iB "DECchip 21140 PCI Fast Ethernet LAN Controller Hardware Reference Manual,"
.iB "SGS-Thompson MK48T59/559 CMOS 8K x 8 TIMEKEEPER SRAM Data Sheet,"
.iB "Zilog SCC (Serial Communications Controller) User's Manual,"
.iB "Tundra Universe User Manual,"
.iB "Tundra Universe Device Errata,"
.iB "ANSI/VITA 1-1994 VME64 Specification,"
.iB "ANSI/IEEE 1014-1987 Versatile Backplane Bus: VMEbus,"
.iB "IEEE P1386 Draft 2.0 - Common Mezzanine Card Specification (CMC),"
.iB "IEEE P1386.1 Draft 2.0 - PCI Mezzanine Card Specification (PMC),"
.iB "Peripheral Component Interconnect (PCI) Local Bus Specification, Rev 2.1,"
.iB "PCI to PCI Bridge Architecture Specification 2.0,"