target.nr

vxworks的BSP开发配置文件

card.


.SS "VME Access"
The board is a PCI board.  VME is not supported.


.SS "PCI Access"
The configuration access method is via accesses to areas in the
memory map that IXM1200 maps onto Type 0 and Type 1
configurations.  By default, the SDRAM memory is mapped to PCI
memory address 0, so that virtual address 0 is mapped to PCI
memory address 24 MB.  See section "Cache/MMU considerations" for
more details.


.SS "Boot Devices"
By default, VxWorks is booted on this board by running the bootrom
image from Flash memory, and then loading the VxWorks kernel via
the network driver.


.SS "ROM considerations"
Intel ships the boards with Flash memory parts containing several
different systems that can be booted. At the start of Flash
memory, the initial boot code examines GPIO[1:0] to determine which OS
can be booted. This is described in Section "Jumpers". If the Boot
Manager is selected, then the user can enter into a dialog to
determine the boot parameters. This takes place over the serial port
at 9600 Baud.  For further details, see
.I Intel IXDP1200 Network Processor Development Platform System User's Manual.

By default, the Flash image is broken into the following blocks:

.TS E
expand;
.cf3 s
lf3 lf3
l l .
.ne 5
Flash Blocks
.sp .25
Start Addr	Description
_
0000 0000	Boot Manager / Flash Utility
0000 8000	Boot Parameters (NVRam)
0000 C000	Diagnostics
0002 0000	Unused
0004 0000	VxWorks
0014 0000	Cygmon
0016 0000	Unused
0020 0000	Angel / UCOS
.TE

Flash parts containing a valid Boot Manager / Flash Utility can be
reprogrammed in-situ by running the FUTIL.EXE program on a host
connected to the board via a serial line. For further details, see
.I Intel IXDP1200 Network Processor Development Platform System User's Manual.

The image that is programmed into the Flash must be a raw binary
image. These can be made by making the *.bin targets in
Makefile. Additionally, if a complete Flash boot image is to be
made, the VxWorks image must be relocated to address 0x60000 and
an appropriate branch loaded at 0. This can be done for VxWorks alone
by building the *.ful targets. Alternately, a separate utility may be used
to combine the various images into one Flash image.

Note that the compressed vxWorks bootrom image, bootrom.bin, is
not currently recommended for use with this target due to
additional image compression done by Intel's FUtil Flash Utility.
Using this image may result in an error message from the FUtil host
program such as "Error doing inflate" or in a bootrom image that
does not work.  Use its uncompressed counterpart, bootrom_uncmp.bin.

.SS "Flash Memory as NVRAM"
Intel has allocated the block of Flash extending from address
0x8000 to 0xC000 as non-volatile storage.


.SH "SPECIAL CONSIDERATIONS"

.SS "Make Targets"
The image loaded into Flash memory must be a raw binary
image.  These targets are defined with a ".bin" extension.
Additionally, complete VxWorks boot images must be loaded at the
the appropriate address with a branch loaded at zero. These targets
are defined with a ".ful" extension. The corresponding targets
defined by the Makefile are:

.TS E
expand;
cf3 s s
lf3 lf3 lf3
l l l .
.ne 5
Make Targets
.sp .25
Original Target	Binary Target	Full Target
_
bootrom	bootrom.bin	bootrom.ful
bootrom_res	bootrom_res.bin	bootrom_res.ful
bootrom_uncmp	bootrom_uncmp.bin	bootromu.ful
vxWorks_rom	vxWorks_rom.bin	rom.ful
vxWorks.st_rom	vxWorks.st_rom.bin	st_rom.ful
vxWorks.res_rom_nosym	vxWorks.res_rom_nosym.bin	vxWorks_res_rom_nosym.ful
vxWorks
vxWorks.st
.TE

.SS "Programming the Flash"
If the boot manager / Flash utility image stored in the Flash is
corrupted, then the only recourse is to either remove the
Flash parts and program them externally. It is therefore recommended
that when updating the Flash, this region should be skipped unless
there is a defined need to update the boot manager / Flash utility.

.SS "Delivered Objects"
There are several VxWorks internal routines that needed to be
modified for this BSP.

Additionally, several VxWorks include files needed to be modified
to support the 28F800 series of Flash memory parts. These include:
    mem/FlashMem.c
    drv/mem/flash28.h

And the MMU file:
    arch/arm/mmuArmLib.h


.SS "Special routines"
The routine sysLedsReadWrite() is used to control the LEDs on the
board.  For further information, see the man entry for this
routine.

The routines sysRead16() and sysWrite16() are provided to allow C
code to use the LRDH and STRH instructions explicitly (16-bit
load/stores).  For further information, see the source code in
sysALib.s.

The routine ixmVersion() returns the Intel IXM version number, which
relates this BSP version with other tools in the IXM suite.

The routine sysCpuIDGet() returns the CPU ID. The low order 4-bits
gives the revision number of the CPU.

The routine sysBoardIDGet() returns the Board ID. For the IXM1200,
this is 0x808610AB.

.SS "NetROM"
The IXM1200 board may be booted via NetROM.

To boot with NetROM, Switch SW2, bit FL/~NR should be set OFF. With
this setting, the NetROM will appear at the Flash address, and the
Flash will not be visible.

.SS "Divide by Zero Exception"
The ARM architecture does not provide for an integer divide by
zero exception.  Therefore, no exception is generated when an
integer divide by zero is performed programmatically.


.SS "Bus Error Exception"
The only Data Abort exceptions that the board can generate are
caused by the MMU during accesses to un-mapped memory.


.SS "Cache/MMU considerations"
The extra state VM_STATE_CACHEABLE_MINICACHE is available on the
IXM1200, which is not available on other ARM CPUs (with the
exception of the SA1100). Setting pages to this state using
vmStateSet() will result in those pages being cached in the
mini-cache, and not in the main data cache.  Calling
cacheInvalidate(DATA_CACHE, ENTIRE_CACHE) will also invalidate the
mini-cache, but in all other aspects, no support is provided for
the mini-cache, and the user is entirely responsible for ensuring
cache coherency.

No support is provided to the read-buffer, but it is invalidated
during BSP startup.

The IXM1200 cannot support a memory mapping where RAM is present
over the exception vectors without using the MMU.  In doing so, it
must provide a mapping where physical and virtual addresses are
not the same.  In order for the mmuLib/cacheLib code to support
this, the BSP has to provide routines to map between virtual and
physical addresses.  See the man entries for the BSP routines
sysVirtToPhys() and sysPhysToVirt() for details.

The default mapping remaps the top part of SDRAM to virtual
address 0, so that the exception vectors lie in RAM.  This then
requires the Flash memory to be remapped to a higher address to
make room for the SDRAM.  Since a large amount of SDRAM is to be
used by the MicroEngines for packet data, and since this data must
be non-cacheable when accessed by the ARM core, the bottom part of
SDRAM is mapped in a separate virtual memory range that is not
adjacent to the portion of SDRAM used by VxWorks, and this range
is marked as non-cacheable.

The default physical to virtual mapping is defined as:

.TS E
expand;
cf3 s s
lf3 lf3 lf3
l l l .
.ne 5
Physical to Virtual Address Mapping
.sp .25
Physical Addresses	Virtual Addresses	Comments
_
C0000000-C7000000	C0000000-C7000000	SDRAM used by MicroEngines
C7000000-C8000000	00000000-01000000	SDRAM used by VxWorks
00000000-00600000	08000000-08600000	Flash Memory
.TE

The remaining address ranges are either mapped flat or are
invalid.

.SS "Validation Test Suite Failures"
In the test "bootline.tcl", the boot commands test fails due to a
problem with the test. This is because of an assumption that the
processor has a particular endian status.

The test "busTas.tcl" is not applicable.

The divide by zero test in "error1.tcl" fails because the ARM hardware
does not support a divde-by-zero exception.

The UDP packet echo test in "network.tcl" fails due to a problem in
the test, not in the BSP.

The tests in "scsi.tcl" are not applicable as the board does not
support SCSI. The loopback tests in "serial.tcl" are not applicable
because there is only one serial port.

In "timestamp.tcl", the disable timestamp test is not supported. The
timestamp timer cannot be stopped.

.SH "BOARD LAYOUT"

The diagram below shows the relevant jumpers on the production board
for a VxWorks configuration.  The default configuration is
illustrated (a Host Bridge with separate PCI Arbiter).

.bS
+--^------^^^^^^^^^^^^^--^^^^^----^^----------------------------------+
| SW1      100 Base-T    82559  Serial                                |
|  _                                                                  |
| |S|                                                                 |
| |W|                                                                 |
| |2|                                                                 |
| |_|                        _____                                    |
|                           |     |                                   |
|                           | CPU |                            ___    |
|                           |_____|                           |   |   |
|                                                             Flash   |
|                                                             |___|   |
|                                                                     |
|                                                     ---NetROM---    |
++     _                  +-------------------------------------------+
 |||||| |||||||||||||||||||
.bE


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


.SH "BIBLIOGRAPHY"

.I "Intel IXDP1200 Network Processor Development Platform System User's Manual"