target.nr

WINDRIVER SBC7410 BSP

.TS
expand tab(|);
l lw(4i)
l lw(4i) .
sysNvRam.c|non-volatile RAM library for parallel eeprom
sysFlash.c|Flash access routines - StrataFlash
sysGt64260IntrCtl.c|GT64260 interrupt controller driver
sysGt64260Pci.c|GT64260 PCI bus driver
sysGt64260Timer.c|GT64260 aux and timestamp timer driver
sysSerial.c|prepares serial driver ns16550sio
sysLed.c|system LED driver
sysNet.c|prepares PCI Ethernet driver "fei", "gei" and "wancom"
sysTffs.c|system TFFS integration module
strataFlash.c|Intel StrataFlash MTD for TFFS.
sysACache.s|PowerPC 750/755/7400/7410 L2 cache library
sysFei82557End.c|"fei" driver glue module
sysGei82543End.c|"gei" driver glue module
sysWancomEnd.c|"wancom" driver glue module, plus LXT972 PHY MII register driver
wancomEnd.c|GT64260 fast ethernet END driver
.TE

The BSP configures an NS 16550 compatible UART to implement a console device and the 
GT64260 ethernet 0/1 ports as an Ethernet devices. An Intel 8255x PCI card can optionally
be configured as well.

.SS "Support for L1 Cache Locking"
L1 cache locking is available for MPC750, MPC755, MPC7400 and
MPC7410. The cache lock routine can be used to lock the entire data
or instruction cache with a specified memory region. 


.SS "Support for L2 Cache"
L2 Cache is available for MPC750, MPC755, MPC7400 and MPC7410. Callback function
pointers for L2 cache Global Invalidation, L2 Cache Enable, L2 Cache
Flush and L2 Cache Disable are intialized in sysHwInit().


.SS "Support for L2 Cache Locking"
L2 cache locking is supported on MPC750, MPC755, MPC7400 and MPC7410. On these
CPUs L2 is implemented as an unified cache. The L2 cache lock library
can be used to lock data or instructions in the L2 cache.


.SS "Support for AltiVec"
MPC7400 and MPC 7410 support an altiVec sub-system that implements
vector processing. Support for altiVec is now available, but an
altiVec aware compiler must be used to create applications that
use altiVec instructions. The altiVec support can be enabled by
defining INCLUDE_ALTIVEC in config.h


.SS "Default Memory Map"
The default memory map is enforced by the GT64260.
.CS
        Memory Map from CPU point of view

Chip Select	    Start               Size         Access to
---------------------------------------------------------------------
SCS0 (R/W)	0x0                256MB (min)   SDRAM SODIMM
SCS1 		Not used
SCS2 		Not used
SCS3 		Not used
Internal Regs  	0x14000000	    64KB	 Internal Registers

CPCI PCI interface: (INCLUDE_PCI_CARD_IN_BACKPLANE)

PCI0 MEM0	0x12000000	    32MB	 PCI memory
PCI0 MEM1	0xF2000000	    32MB	 PCI memory
PCI0 MEM2	0xF4000000	    32MB	 PCI memory
PCI0 MEM3	0xF6000000	    32MB	 PCI memory
PCI0 I/O	0x10000000	    32MB	 PCI I/O

On-board (local) PCI interface: (INCLUDE_PCI_STANDALONE)

PCI1 MEM0	0x22000000	    32MB	 PCI memory
PCI1 MEM1	0x24000000	    32MB	 PCI memory
PCI1 MEM2	0x26000000	    32MB	 PCI memory
PCI1 MEM3	0x28000000	    32MB	 PCI memory
PCI1 I/O	0x20000000	    32MB 	 PCI I/O

CS0  (R/W)	0x1C000000	     8MB	 EEPROM, LEDs and GP 
CS1  (R/W)	0x1C800000	     8MB	 Mailbox
CS2  (R/W)	0x1D000000	    16MB	 UART
CS3  (R/W)	0x1E000000	    16MB         CPIO
BOOTCS (R/W)    0xFF000000	    16MB      	 Boot Flash
.CE


.SS "Shared Memory"
.PP
N/A


.SS "Using the vPROBE/vICE to download the vxWorks image directly to RAM"
when using vPROBE/vICE to download the vxWorks image directly to RAM you need
to remember that the CS & main CPU initialization are done by the emulator and 
not by the bootrom (romInit.s), because the reset symbol is "sysInit" and not
the reset vector (0xFFF00100). Because this the code will execute only the 
module "sysALib.s", and it will not execute the module "romInit.s". If you will 
not use the correct register file the vxWorks image will not run correctly.

NOTE: romInit.s will need to be modified accordingly to support this capability.

				 
.SS "SDRAM Size"
.PP
Boards and bsp are supplied with a 256Meg SDRAM SODIMM.

The BSP divides the 256Meg SDRAM into a 32Meg section and a (256-32) USER_RESERVED_MEM
section. The reason for this has to do with the EABI compilation option of a 24 bit 
address. The default compilation options generates a 'bl' for branch instructions. This 
increases performance, but places a 32Meg address limit on the code.
  
There are two 'work arounds' to this limitation.
 
    1.) recompile all the source with the -mlongcall compilation flag
    2.) add remaining 32Meg to the memory pool vi the memAddToPool() function.
  
Option #1 would require all the libraries, driver, and the BSP to be 
recompiled with the -mlongcall compiler option. This results in a number
of code changes; the most obvious code change is branches are implemented
via brlr instruction verses the bl instruction.
  
Option #2, the perferred option, requires the USER_RESERVED_MEM and
the memAddToPool() constructs be used to specify the remaining 32Meg
to be added to the memory pool. Consult WindTech Note WTN41 for details 
on specifying user memory.


.SS "Network Configuration"
All boards come with two on-board 10/100 ethernet ports via the GT64260.
The BSP should be configured with INCLUDE_WANCOMEND to initialize these
two ports. In addition, the BSP supports an Intel fei NIC in the local
PCI slot via the PCI-1 interface of the GT64260. In order to configure
the BSP for this use INCLUDE_FEI82557END. The Ethernet drivers automatically 
senses and configures the port as 10baseT or 100baseT.


.SS " NVRAM Support" 
The wrSbc7410 board contains a CAT28LV64 64K-Bit CMOS PARALLEL EEPROM; boot 
parameters are stored on this device. Ethernet MAC addresses for wancom0 and
wancom1 are also stored in the EEPROM. Use the boorom 'N' command
to modify the ethernet MAC address for wancom0.


.SS "Ethernet Address"
If an Intel 55x PCI NIC is used, the Media Access Control (Ethernet) address 
for each port is obtained from a serial ROM contained in the Intel 82557/9 NIC. 
The ethernet MAC addresses for the on-board GT64260 ports must be set by modifying
bspEnetAdrs[] in sysWancomEnd.c or by using the bootrom program and the 'N'
command to modify the MAC address for wancom0.  Note that a deficiency in bootConfig.c
prevents use of the 'N 1' command to modify the MAC address for wancom1.  sysEnetAddrSetUnit()
may be used to set the address for wancom1.

Notes on use of the 'N' command:

1) The current ethernet address will be displayed in reverse order.

2) The actual values of the last three bytes won't be displayed when you're prompted
 to change them, but the values shown are the defaults that will be saved if you don't 
 provide a new value.
 
3) The new ethernet address is displayed correctly after you modify the 3 bytes. 

Example:
.bS
[VxWorks Boot]: N
Current Ethernet Address is: 03:02:01:a0:1e:00
Modify only the last 3 bytes (board unique portion) of Ethernet Address.
The first 3 bytes are fixed at manufacturer's default address block.
00- 00
a0- a0
1e- 1e
1e- 4
a0- 5
00- 6

New Ethernet Address is: 00:a0:1e:04:05:06
.bE

The first three bytes of the MAC address (0x00, 0xa0, 0x1e) are a Wind River specific prefix
that should be kept as-is. If for some reason you need to change them, 
change the  macro in config.h:

.bS
    #define	ENET_DEFAULT 0x1ea00000    /* 00:a0:1e:xx:xx:xx */
.bE

Note that this macro only sets the first 3 bytes when the 'N' command is used.
If it is changed, the bootrom must be rebuilt and the flash must 
be reprogrammed (see items 2 and 3 under Introduction).
The user must change the last three bytes to three 
unique bytes (i.e., bytes not used by any other Wind River Ethernet 
connection on your network). Check with your system administrator if you 
do not know this information.

The wrSbc7410 has 2 builtin ethernet ports.  The 'N' command described
above sets the MAC address of unit0, the first ethernet port.  The MAC
address for unit1, the second ethernet port, is automatically defined
as unit0 MAC address plus 1.

Beginning in 2003, all Wind River hardware development boards
with builtin ethernet interfaces will have pre-programmed MAC addresses.

.SS "ROM Considerations"
bootrom.bin and bootrom_uncmp.bin are provided with this BSP. The bootrom is 
configured to a ROM base address of 0x0. When programing the bootrom to the 
FLASH an offset of 0xFFF00100 needs to be given, also it's configured to use 
the 16 MByte on board Flash ROM and the on-board GT64260 wancom END driver as the
boot devices and the RS232 as console device. The bootrom takes approximately 10 
seconds to boot.


.SS "BOOT FLASH"
The BSP is configured to use the 1MByte of the 16MB flash at 0xFF000000 as boot
flash. Up to the remainder of flash is configured for the use of TFFS by using
the constants INCLUDE_TFFS_VOLn where n = 0,1,2 or 3. Volume 0 is 8MB, Volume
1 is 4MB, Volume 2 is 2MB and Volume 1 is 1MB for a maximum of 15MB. If any
TFFS bank is not configured it can be used for general flash and can be accessed
with the Stratflash driver in sysFlash.c.


.SS "Serial Configuration"
The NS 16550 UART is configured as UART devices with 8 data bits, 1 stop
bit, hardware handshaking, and parity disabled and is available via 
J22. J22 uses HSI's standard 4-wire connection.


.SS "Serial Connections"
This VxWorks wrSbc7410 board uses a simple 3 wire connection and standard 
phone jacks where pin 1 = RIN, pin 2 = TOUT, pin 3 = NC, and pin 4 = GND.


.SS "SCSI Configuration"
There is no direct SCSI interface on this board. SCSI, if desired, can
be available via the PCI slot / PMC connector on the board. Adding
this capability will require integration of the appropriate SCSI driver
to this BSP.


.SS "VME Access"
N/A


.SS "PCI Access"
Two 32/64-bit address, 32/64-bit data interfaces are available
on the wrSbc7410 board and they comply with PCI Local Bus Specification, 
Revision 2.x. PCI-0 is used when the wrSbc7410 is plugged into the 
I/O expand unit and in the CPCI connector.  PCI-1 is used when the 
board is used in a standalone mode of operation. Either the 32/64 bit
PCI connector -or- the 32/64 bit PMC connector on the board may be 
used.  JP51 must be installed when using the local PCI connectors.
JP51 must be removed when the board is used in the I/O expand unit.
See the memory map for the default PCI memory map.

Note that this BSP manually configures either PCI-0 or PCI-1. The
BSP does not use auto configuration. This may be added in a later
release of this BSP.


.SS "Interrupts"
The GT64260/GT64260A interrupt controller is an extremely limited
and primitive interrupt controller. The interrupt controller driver
supplied with this BSP is simple in concept: it services 1 interrupt
at a time and then exits. Interrupts are locked out during processing
of any system interrupt.  This is because interrupts are not saved
or queued by the processor.  This simple design has been exercised
but may cause problems with designs utilizing more of the GT64260
internal units. An upgrade design for the interrupt controller is to
implement a handler that sends all interrupt events to a message
queue (e.g., similar to our network drivers and tNetTask) so that
interrupt events can be handled in task time.  This upgrade has 
the advantage of "pending" interrupt events via the message queue
and is a more robust design.

Example code for the interrupt controller perused looped through
interrupt cause bits in the CPU mask register in the interrupt
handler thereby causing massive blocking of interrupts (most
notably the decrementer or system clock interrupt). The current
design was chosen to eliminate this problem.  See the file
sysGt64260IntrCtl.c for specific details.

Finally, some interrupt events are multiplexed on single interrupt
vectors (timers, dma and GPP interrupts). In these instances 
the muxed interrupt in the CPU Mask register is enabled during
setup and the local interrupt mask register is used by the various
drivers to enable / disable the interrupts. Note that the 
interrupt handler uses the intPrioTbl[] structure in the interrupt
controller driver to know how to handle each type of interrupt in
the system. Please read the comments there in order to add new
interrupts to the BSP.

Interrupts from the General Purpose Port, Timers and DMA are handled
differently by the interrupt controller as they are muxed interrupts
and share vectors. For example GPP bits 0-7 share one interrupt
vector.  The interrupt controller's intConnect routine will chain
muxed interrupts to the shared interrupt vector.  The user has the
choice of having the interrupt controller handler clearing the 
interrupts (see intPrioTbl[] in sysGt64260IntrCtl.c) or clearing
the interrupts in the interrupt service routine.  The interrupt