VxWorks BSP Reference : mv2100
mv2100 - Motorola
This reference entry provides board-specific information necessary to run VxWorks. Before using a board with VxWorks, verify that the board runs in the factory configuration by using vendor-supplied ROMs and jumper settings and checking the RS-232 connection.
This BSP encompasses only the MVME2100 board.
The MVME2100 board is a single-board computer based on the PowerPC MPC8240 microprocessor.
MVME2100
The BAT registers are not supported in the current cache management strategy.
The MVME2100 boards have two sets of flash EEPROM (FLASH). Bank A consists of two 32-pin PLCC sockets which can be populated with up to 1024KB of FLASH memory. It resides at address 0xFFF00000 and is restricted to 8 bits in width. This memory contains Motorola's PPC1-Bug. Bank B may be populated with four 512Kx16 FLASH devices to obtain 4MB of 64-bit wide expansion FLASH memory or four 1Mx16 FLASH devices to obtain 8MB of 64-bit wide FLASH memory. The expansion FLASH memory starts at address 0xFF000000. FLASH is soldered in on the back of the boards. The VxWorks boot kernel resides in the soldered FLASH. See Hardware Details: ROM Considerations for information about loading and writing the boot kernel image to the soldered FLASH.These boards have non-volatile RAM; thus, boot parameters are preserved whenever the system is powered off.
To load VxWorks, and for more information, follow the instructions in the Tornado User's Guide: Getting Started.
The following jumpers are relevant to VxWorks configuration:
For details of jumper configuration, see the board diagram at the end of this entry and in the hardware manual.
Jumper Function Description J2 System controller Install the jumper across pins 2 and 3, if you wish to operate in "automatic" system controller mode [factory configuration]. Install the jumper across pins 1 and 2, if the board is not to be the system controller under any circumstances. And remove the jumper if the board is to be the system controller in all cases. J9 ROM controller Remove the jumper across pins 1 and 2 to select the socketed FLASH. Install the jumper from pins 1 and 2 to select the soldered FLASH. [factory configuration]. J9 User Configurable The remaining jumpers in the J9 jumper bank have no preset function and can be configured by users as necessary. Note that ROM controller jumpers should be set to select socketed FLASH until VxWorks boot code is written to soldered FLASH, after which the jumpers should be restored to the factory configuration of soldered FLASH.
The following subsections list all supported and unsupported features, as well as any feature interaction.
The following features of the MVME2100 board are supported:
Feature Description Processor MPC8240 (MPC603 based); 66.67 and 83.33MHz bus clock FLASH 1MB socketed (8-bit wide); 4 or 8MB expansion (64-bit wide) DRAM 32, 64, 96MB ECC Synchronous DRAM (SDRAM) Memory Model Both CHRP and PReP models are supported NVRAM 8KB (MK48T59Y) Peripherals one 16550-compatible async serial debug port; DEC21143 10/100Base-TX Ethernet interface PCI Interface 32-bit address, 32-bit data; complies with PCI Local Bus Specification, Revision 2.1 VME Interface 32-bit address, 32-bit data PCI bus interface; A32/A24/A16, D32/D16/D08 master and slave; programmable interrupter and interrupt handler; full system controller function; four 32-bit mailbox registers; four location monitors; eight semaphores Miscellaneous RESET switch
The following features of the MVME2100 board are not supported:
Feature Description RTC MK48T59/559; only NVRAM portion is used DMA Channels 2 Independent DMA Channels I2O Interface I2O compliant messaging interface PCI Interface 64-bit data VME Interface D64(MBLT); programmable DMA controller with linked list support Miscellaneous ABORT switch, 4 status LEDs
None known.
This section details device drivers and board hardware elements.
The device drivers and libraries included with this BSP are:
i8250Sio - Intel 8250 UART driver (debug port) ppcDecTimer - PowerPC decrementer timer driver (system clock) dec21x40[End].obj - 10baseT/100baseTX DEC 21x40 Ethernet driver byteNvRam - byte-oriented generic non-volatile RAM driver kahluaEpic - Motorola Kahlua EPIC interrupt controller driver pciConfigLib - PCI configuration library universe - Tundra Universe II chip VME-to-PCI interface driver sysI2cDrv - Kahlua I2C interface driver
This BSP supports the END (Enhanced Network Driver) as the only network interface for Tornado 2.
This BSP supports ECC memory on the MVME2100. The default configuration is for the ECC support to be disabled so the default BSP will run in all board memory configurations. To enable ECC support, INCLUDE_ECC must be changed from undef to define.
This BSP supports SENS (Scalable Enhanced Network Stack) only. There is a problem with using shared memory booting and Tornado 1.0.1 SENS. Wind River has provided a patch for SPR 21838 which has been included in the mv2100 BSP, but additional configuration is required to install it. This fix must NOT be done on Tornado 2.0!
To configure the BSP to run with Tornado 1.0.1 SENS so shared memory booting works, install SENS in the Tornado 1.0.1 build area and make the following adjustments in the "mv2100" subdirectory and rebuild:
- 1)
- From the "mv2100" subdirectory perform:
mv ../all/bootConfig.c ../all/bootConfig.c.orig mv ../all/bootInit.c ../all/bootInit.c.orig cp ./tornado_1.0.1/bootConfig.c ../all/bootConfig.c cp ./tornado_1.0.1/bootInit.c ../all/bootInit.c- 2)
- From the "mv2100" subdirectory perform:
mv ../../src/config/usrNetwork.c \\ ../../src/config/usrNetwork.c.orig cp ./tornado_1.0.1/usrNetwork.c ../../src/config/usrNetwork.c- 3)
- Rebuild the bootroms and kernel and reflash the bootroms.
On-board RAM for these boards always appears at address 0x0 locally. Its slave address on the VMEbus is set by registers in the Universe ASIC. Local RAM-to-VMEbus mapping is defined in config.hDynamic memory sizing is supported. By default, LOCAL_MEM_AUTOSIZE is defined so memory is auto-sized at hardware initialization time. If auto-sizing is not selected, LOCAL_MEM_SIZE must be set to the actual size of DRAM memory available on the board to ensure all memory is available and VME addressing occurs properly. The default fixed RAM size is set to 16MB (see LOCAL_MEM_SIZE in config.h).
The MV2100 supports two memory mappings. The default for the MV2100 BSP is the CHRP map, the optional mapping is PReP. The mappings are selected by defining or undefinig the macro CHRP_ADRS_MAP, which will determine the setting of the ADDRESS_MAP bit in the Kahlua Processor Interface Configuration Register 1. At power-on the bit is configured by sampling the MAA(0) signal. The default hardware/software setup is for CHRP.
The following tables describe the CHRP address mappings. Most of the address maps are fixed by hardware and the base addresses cannot be modified by the user.Table I. CHRP Map From CPU Point of View.
Start Size Access to 0x00000000 LOCAL_MEM_SIZE (16MB min) DRAM LOCAL_MEM_SIZE (0x40000000 - LOCAL_MEM_SIZE) Unused DRAM space 0x40000000 1GB Reserved 0x80000000 0x7CFFFFFF PCI Memory Space 0x80000000 0x72000000 VME Space (see Table II ) 0xF2000000 128MB Dynamic PCI Mem space 0xFCF00000 1MB Kahlua registers 0xFD000000 16MB PCI ISA Memory Space 0xFE000000 64KB PCI ISA I/O Space 0xFE800000 4MB PCI I/O Space 0xFEC00000 32MB Configuration Addr Reg. 0xFEE00000 16MB Configuration Data Reg. 0xFEF00000 16MB PCI interrupt Ack. 0xFF000000 8MB 32/64 bit FLASH/ROM 0xFF800000 8MB 8/32/64 bit FLASH/ROM Table II. CHRP CPU to VME Map.
The master (outgoing VME) window address mappings are as follows:
VME Master Address Space Size Local Base Address VME Base Address A32 128MB 0x80000000 0x08000000 A24 16MB 0xF0000000 0xXX000000 A32 (Mailbox) 4KB 0xF1000000 0xF1000000 A16 64KB 0xF1FF0000 0xXXXX0000 Table III. CHRP Map on PCI Bus.
PCI MEM Space Access Start Size Access to 0x00000000 1GB (max) DRAM space 0x40000000 1GB (fixed) Reserved 0x80000000 2GB-48MB PCI MEM space 0x80000000 1.75GB (max) VME A32 master space 0xF0000000 16MB (std) VME A24 master space 0xF1000000 64KB (std) VME mailbox (A32) space 0xF1FF0000 64KB (std) VME A16 master space 0xF2000000 128MB (max) Dynamic PCI Mem space 0xFCF00000 1MB (fixed) Kahlua registers 0xFD000000 16MB (max) DRAM space 0xFE000000 16MB (fixed) Reserved 0xFF000000 8MB (max) 32/64 bit FLASH ROM space 0xFF800000 8MB (max) 8/32/64 bit FLASH ROM space
PCI I/O Space Access Start Size Access to 0x00000000 64KB ISA I/O space 0x00010000 8MB-64KB Reserved 0x00800000 4MB PCI I/O space 0x00C00000 4GB-12MB Reserved Table IV. CHRP Map on VMEbus.
The slave (incoming VME) window address mappings are as follows:
VME Slave Address Space Size VME Base Address Local Base Address A16 (none) A24 (none) A32 128MB 0x08000000 0x00000000 A32 (Mailbox) 4KB 0xFB000000 (none)
The following table describes the modified PowerPC Reference Platform (PReP) address maps created from the CPU point of view. Tornado-compatible mapping deviates only slightly from the model.
Start Size Access to 0x0 LOCAL_MEM_SIZE (16MB min) DRAM LOCAL_MEM_SIZE (0x80000000 - LOCAL_MEM_SIZE) [Not used] 0x80000000 8MB PCI ISA I/O space 0x80800000 8MB Direct PCI Config. Space 0x81000000 (1GB - 32MG) PCI I/O space 0xC0000000 16MB PCI ISA MEM space 0xC1000000 (1GB - 32MG) PCI MEM space 0xC1000000 128MB Dynamic PCI Mem space 0xEFE00000 1MB Kahlua registers 0xFF000000 16MB ROM space
The pseudo-PReP memory model does not offer much address space for mapping VME master windows. Only 128MB of A32 space is available. The 128MB window can be mapped anywhere in VME A32 space by setting the macro VME_A32_MSTR_BUS in config.h. The full A16 and A24 master window address spaces are mapped into the system.
The master (outgoing VME) window address mappings are as follows:
The slave (incoming VME) window address mappings are as follows:
VME Master Address Space Size Local Base Address VME Base Address A16 64KB 0xEFFF0000 0xXXXX0000 A24 16MB 0xE0000000 0xXX000000 A32 128MB 0xD8000000 0x08000000 A32 (Mailbox) 4KB 0xF0000000 0x40000000
VME Slave Address Space SIZE VME Base Address Local Base Address A16 (none) A24 (none) A32 128MB 0x00000000 0x00000000 A32 (Mailbox) 4KB 0x40000000 0x00001000 (UNIV II LM Reg)
The default pseudo-PReP mapping from the PCI bus point of view is:
PCI MEM Space Access Start Size Access to 0x00000000 16MB (max) PCI ISA MEM space 0x01000000 (1GB - 32MB) PCI MEM space 0x01000000 128MB (max) Dynamic PCI MEM space 0x18000000 16MB (std) VME A32 master space 0x20000000 16MB (max) VME A24 master space 0x2FE00000 1MB (fixed) Kahlua registers 0x2FFF0000 64KB (max) VME A16 master space 0x80000000 16MB (min) DRAM space
PCI I/O Space Access Start Size Access to 0x00000000 64KB PCI ISA I/O space 0x00010000 8MB-64KB Reserved 0x00800000 1GB-16MB PCI I/O space 0x3F800000 3GB+8MB Reserved Remember to set LOCAL_MEM_SIZE to the actual amount of DRAM on the board if auto-sizing is not selected. Failure to do so can cause unpredictable results for A32 masters and slaves.
In config.h, #define the VME window variables.
In sysLib.c, edit the sysPhysMemDesc[] page table to modify the A32 VME window if you modify the sysBatDesc[] BAT register table. The BAT registers allow mapping of up to 1GB of data address space. Although the BAT registers are not supported in the current cache management strategy, you can use them for non-cacheable, data-only address regions, like the VME A32 address space.
On all boards, shared memory across the backplane can also be used as a network interface. The name of the shared memory is sm.Shared memory network communications requires a signaling method and a method of mutually exclusive memory resource access. Signalling can be done using software polling or interrupts. By default, mailbox interrupts are used and SM_INT_TYPE is set to SM_INT_MAILBOX_1. To use polling, #define SM_INT_TYPE as SM_INT_NONE.
There are master and slave windows into VME address space to access the VME mailbox registers so that each CPU can send and receive shared memory interrupts using single-byte mailboxes. The windows map a 4KB region in A32 space at address 0xFB000000 + (0x1000 * CPU #) into the Universe chip registers. This configuration allows one processor to generate a SIG1 interrupt in another processor by accessing the other processor's mailbox register and setting the SIG1 bit. Each CPU has a master window covering the A32 addresses 0xFB000000 through 0xFB00ffff representing CPU numbers 0 through 15. Each CPU's slave window maps the appropriate address for that CPU to the Universe chip's register set.
Shared memory resource mutual exclusion (spin lock) is implemented using test-and-set (TAS) and clear operations on byte-sized semaphores. If the #define SM_TAS_TYPE is set to SM_TAS_SOFT, only a software TAS routine is used. Software TAS is usually good enough for shared memory networking; however, VxMP requires the use of hardware TAS. Enable hardware TAS by setting SM_TAS_TYPE to SM_TAS_HARD. Hardware TAS and clear operations are performed by the sysBusTas( ) and sysBusTasClear( ) routines, respectively, and invoke pseudo-atomic operations.
True atomic operations are those which cannot be preempted at the hardware level and appear on a bus as a single-cycle instruction. Pseudo-atomic operations are composed of multiple instruction cycles executed on a bus that is locked (owned) by the processor executing the instructions.
The routine sysBusTas( ) performs pseudo-atomic TAS operations by disabling interrupts (to prevent deadlocks) and locking ownership of the VMEbus. This routine waits up to 10 microseconds to lock the bus. If bus ownership has not been achieved at the end of this period, the routine returns FALSE, the same as it would if the semaphore had already been set.
VMEbus ownership is necessary for a couple of reasons. First, there is no hardware support to propagate PowerPC atomic TAS instructions to the Universe chip. Second, these boards have no support for propagating true atomic VME RMW cycles to local processor memory.
To ensure proper clearing of the semaphore, use the sysBusTasClear( ). This routine also disables interrupts and locks the VMEbus while accessing the semaphore. It waits up to 10 microseconds to gain bus ownership. But, even if the bus is not owned after this period, the routine attempts to clear the semaphore.
If one board uses software TAS, then all boards on a shared memory backplane must use it.
When hardware TAS is enabled, special consideration must be given to the overall system design and board locations in the VME card rack. If all VME boards on a backplane use the special hardware TAS methods utilized in this BSP, there should be no problems. If boards with differing TAS/RMW capabilities are used together, then either the first (master) board, which hosts the shared memory, must use the hardware TAS method utilized in this BSP, or the shared memory must reside on a separate VME global memory board.
As an example of a hardware TAS system that cannot work, consider using a Motorola MVME162 as the master board and an MVME2100 as a slave. The mv162 BSP assumes that support exists for atomic TAS/RMW cycles on to and off of all boards in the system. Furthermore, the local 68040 CPU can access and alter its memory between VMEbus cycles. Therefore, this system configuration does not work because there is no way to ensure atomic access to a semaphore by the MVME2100 board.
The Embedded Programmable Interrupt Controller (EPIC) sets system interrupt priorities and serves as controller of all external interrupts. Each of its 16 interrupt control registers can be programmed with a relative priority from 15, the highest, to 0, the lowest. A priority of zero effectively disables the interrupt. All of the 16 control registers have been hardwired to a particular interrupt source. The EPIC interrupt controller will operate in the serial interrupt mode.The external interrupt vector numbers and priority assignments are:
For further details, refer to the appropriate board's reference guide.
Vector# EPIC Priority Interrupt Source 0 0 Not Used 1 14 DEC21143 Ethernet Controller 2 9 PMC/PC-MIP Type I Slot 0 3 8 PC-MIP Type I Slot 1 4 7 PC-MIP Type II Slot 0 5 6 PC-MIP Type II Slot 1 6 0 Not Used 7 13 PCI Expansion Interrupt A/Universe II (LINT0) 8 13 PCI Expansion Interrupt B/Universe II (LINT1) 9 13 PCI Expansion Interrupt C/Universe II (LINT2) a 13 PCI Expansion Interrupt D/Universe II (LINT3) b 0 Not Used c 0 Not Used d 5 16550 UART e 4 Front panel Abort Switch f 3 RTC/IRQ There are only four PCI bus interrupts: A, B, C, and D. They are shared among all PCI bus devices and do not have levels. PCI bus interrupts are wired directly to the EPIC and, therefore, have pre-assigned system vector numbers and interrupt levels. The user enables one or more PCI interrupts and connects vectored ISRs to the system by following these steps:
- 1)
- Identify the PCI interrupt letter(s) as required by the application. Based on this, identify the associated system interrupt level from the following tables:
Primary PCI Bus
----------------
A = PMC_INT_LVL1
B = PMC_INT_LVL2
C = PMC_INT_LVL3
D = PMC_INT_LVL4Secondary PCI Bus
-----------------
A = PMC_INT_LVL4
B = PMC_INT_LVL3
C = PMC_INT_LVL2
D = PMC_INT_LVL1
- 2)
- Define the vector for each PCI interrupt as follows: INT_VEC_IRQ0 + PMC_INT_LVLx where x is 1, 2, 3, or 4, as determined above.
- 3)
- In the application code, perform intConnect( ) for each vector and its associated ISR.
- 4)
- Perform sysIntEnable( ) for each identified system interrupt level.
- 5)
- When the application has finished, perform sysIntDisable( ) for each identified level.
To simplify the addition of PCI-based add-in cards, the BSP provides a PCI auto-configuration library. When INCLUDE_AUTOCONF is defined, the BSP will automatically locate and configure installed PCI devices. When INCLUDE_AUTOCONF is not defined, add-in PCI devices will not be located or configured.If PCI auto-configuration is selected, the auto-cofiguration library will be called from sysHwInit to discover and configure the installed PCI devices and bridges. Device configuration includes the following PCI information:
- Base Address Registers (BARs)
- Space in the address map is dynamically allocated to each valid BAR detected. Allocation pools are maintained for the following PCI address spaces:
16-Bit PCI I/O 32-Bit PCI I/O PCI Memory I/O (non-prefetchable memory) PCI Memory (pre-fetchable)
- Interrupt Routing
- The correct interrupt vector number is placed in the intLine register of the device's PCI header. To connect to the devices's interrupt, simply call intConnect with the value read from intLine.
- PCI Header Completion
- The PCI auto-configuration library fills in the remainder of the PCI header as follows:
Cache Line Size = _CACHE_ALIGN_SIZE/8
Latency Timer = PCI_LAT_TIMER
Command Register = I/O enabled, Memory enabled and Bus Master enabled.
- PCI-to-PCI Bridge Configuration
- PCI-to-PCI bridges encountered during PCI auto-configuration will be configured as necessary and devices detected behind the bridge will be configured as described above. Bridge configuration consists of the following:
Primary Bus Number, Secondary Bus Number and Subordinate Bus Number are filled in according to the bridge's position in the system.
I/O Base and Limit registers are configured as required to forward PCI transactions to PCI devices detected and configured beyond the bridge.
Memory Base and Memory Limit regsiters are configured as required to forward PCI transactions to PCI devices detected and configured beyond the bridge.
Prefetchable Memory Base and Prefetchable Memory Limit are configured as required to forward PCI transactions to PCI devices detected and confured beyond the bridge.
Command Register = I/O enabled, Memory enabled and Bus Master enabled.
Cache Line Size = _CACHE_ALIGN_SIZE/8
Primary Latency Timer = PCI_LAT_TIMER
Secondary Latency Timer = PCI_LAT_TIMER
The single serial port on the MVME2100 board family is implemented as a SCC 16550 UART. The RJ-45 jack is placed on the front panel of the board and is configured as a DTE connection.By default, the serial port is configured as asynchronous, 9600 baud, with 1 start bit, 8 data bits, 1 stop bit, no parity, and no hardware or software handshake. Hardware handshake using RTS/CTS is a supported option.
SCSI is not available on the MVME2100 board family.
All boards have one Ethernet port which is 10baseT and 100baseTX compatible. The MVME2100 boards have an RJ45 jack on their front panel for connection to this facility.The Ethernet driver automatically senses and configures the port as 10baseT or 100baseTX.
The Media Access Control (Ethernet) address for each port is obtained from a serial ROM contained in the DEC21143 chip. If the address is not found in serial ROM, the driver attempts to read it from NVRAM.
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:
#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_SIZEDMA 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.
The 32-bit PCI bus is fully supported under the 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 mv2100_pciXxx.The PCI address mappings are affected by the VME address model selected. See SPECIAL CONSIDERATIONS.
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.
The supported boot devices are:sm - shared memory
dc - Ethernet (10baseT or 100baseTX)
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.
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:
cd target/config/mv2100 make clean make bootrom_uncmp cp bootrom_uncmp.bin /tftpboot/boot.binPower 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.
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:
Socketed ROM has an address of 0xFFF00000 Soldered FLASH has an address of 0xFF000000At 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 set 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.
PPC1-Bug>set 1016971302Using niot, the Client IP Address, Server IP Address, and Gateway IP Address must be set up for the user's specific environment:
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>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 /tftpboot directory name:
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>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:
PPC1-Bug>pflash 4000:fff00 fff00100To put it into soldered FLASH:PPC1-Bug>pflash 4000:fff00 ff000100When the command is finished, power down the board and configure the ROM jumper, then power the board back up.
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.
This section describes miscellaneous information concerning this BSP and its use.
The delivered objects are: bootrom.hex, vxWorks, vxWorks.sym, and vxWorks.st.
The make targets are listed as the names of object-format files. Append .hex to each to derive a hex-format file name.
------------------------------ 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)
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:
clkFreqMhz = MEMORY_BUS_SPEED;
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.
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.
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.
______________________________ ______________________________ | 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 switchKey:
| 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
Tornado User's Guide: Getting Started, VxWorks Programmer's Guide: Configuration
Motorola MVME2100 Series Single Board Computer Programmer's Reference Guide Motorola Computer Group Online Documentation, http://library.mcg.mot.com/mcg/boards Motorola PowerPC 8240RISC Microprocessor User's Manual, Motorola PowerPC Microprocessor Family: The Programming Environments, DECchip 21140 PCI Fast Ethernet LAN Controller Hardware Reference Manual, SGS-Thompson MK48T59/559 CMOS 8K x 8 TIMEKEEPER SRAM Data Sheet, Zilog SCC (Serial Communications Controller) User's Manual, Tundra Universe User Manual, Tundra Universe Device Errata, ANSI/VITA 1-1994 VME64 Specification, ANSI/IEEE 1014-1987 Versatile Backplane Bus: VMEbus, IEEE P1386 Draft 2.0 - Common Mezzanine Card Specification (CMC), IEEE P1386.1 Draft 2.0 - PCI Mezzanine Card Specification (PMC), Peripheral Component Interconnect (PCI) Local Bus Specification, Rev 2.1, PCI to PCI Bridge Architecture Specification 2.0,