target.nr

vxworks bsp for pc pentium3 开发环境为tornado2.2 for pentium。

The PIC(8259A) IRQ0 is hard wired to the PIT(8253) channel 0 in a PC
motherboard.  IRQ0 is the highest priority in the 8259A interrupt
controller.  Thus, the system clock interrupt handler blocks all lower
level interrupts.  This may cause a delay of the lower level interrupts in
some situations even though the system clock interrupt handler finishes its
job without any delay.  This is quite natural from the hardware point
of view, but may not be ideal from the application software standpoint.
The following modes are supplied to mitigate this situation by providing the
corresponding configuration macros in the BSP.  The three modes are
mutually exclusive.

Early EOI Issue in IRQ0 ISR: define PIC_EARLY_EOI_IRQ0.
In this mode, the EOI is issued before the IRQ0 system clock interrupt
service routine starts the kernel work.  This lowers the IRQ0 ISR blocking
level to the next lower level.  If no IRQs are in service, the next lower
level is the lowest level.  If IRQn is in service, the next lower level
corresponds to the next lower priority.  As a result, the kernel work in
the system clock interrupt service routine can be interrupted by an
interrupt with a higher priority than the blocking level.

Special Mask Mode in IRQ0 ISR: define PIC_SPECIAL_MASK_MODE_IRQ0.
In this mode, the Special Mask Mode is used in the IRQ0 system clock
service routine.  This lowers the blocking level to the specified level
(currently hard coded to the lowest level in i8259Intr.c).

Automatic EOI Mode: define PIC_AUTO_EOI.
This mode provides no nested multi-level interrupt structure in PIC1.
The EOI command is automatically sent to the master PIC at the end of the
interrupt acknowledge cycle.  Thus, no software intervention is needed.

P6 (PentiumPro, II, III) and P7 (Pentium4) family processor has new interrupt 
controller APIC/xAPIC (Advanced Programmable Interrupt Controller) which 
consists of Local APIC/xAPIC (on-chip) and IO APIC/xAPIC (on chipset).
They are used in two additional interrupt modes that are configurable in BSP.  

Virtual Wire Mode: One of three interrupt modes defined by the MP
specification.  In this mode, interrupts are generated by the 8259A 
equivalent PICs, but delivered to the BSP by an APIC that is programmed to 
act as a "virtual wire"; that is, the APIC is logically indistinguishable 
from a hardware connection.  This is a uniprocessor compatibility mode.
If the Local APIC exist in the processor indicated by APIC feature flag
in the CPUID, this mode can be configured and used.
To use this mode, define VIRTUAL_WIRE_MODE in config.h

Symmetric IO Mode: One of three interrupt modes defined by the MP
specification.  In this mode, the APICs are fully functional, and 
interrupts are generated and delivered to the processors by the APICs.  
Any interrupt can be delivered to any processor.  This is the only 
multiprocessor interrupt mode.  If the Local APIC exist in the processor
indicated by APIC feature flag in the CPUID and the IO APIC in the chipset
is available, this mode can be configured and used.  The PIRQ[n] is 
directly handled by the IO APIC in this mode.
To use this mode, define SYMMETRIC_IO_MODE in config.h

.SS "Serial Configuration"
Refer to the board vendor's documentation.

.SS "SCSI Configuration"
Refer to the board vendor's documentation.

.SS "Network Configuration"
Please note that the following END driver configuration mechanism,
particularly with respect to the use of <endDevTbl>, will be obsolete in
a future Tornado 2.x release.  Wind River Systems' Intel Architecture BSPs
continue to use the following END driver configuration mechanism as of
Tornado 2.2 FCS.

The BSP configNet.h file contains a static table, <endDevTbl>, that
specifies END driver instances which must be loaded to the MUX via
muxDevLoad() when the network is initialized.  Each table entry of type
END_TBL_ENTRY records information the muxDevLoad() routine requires.   The
END_TBL_ENTRY is defined as follows:

.CS
typedef struct end_tbl_entry
    {
    int          unit;                           /@ device unit number @/
    END_OBJ * (* endLoadFunc) (char *, void *);  /@ the load function @/
    char *       endLoadString;                  /@ the load string @/
    BOOL         endLoan;                        /@ buffer loaning flag @/
    void *       pBSP;                           /@ BSP private @/
    BOOL         processed;                      /@ processed flag @/

    } END_TBL_ENTRY;
.CE

The specified value and use of the END device <unit> number is significant
to the BSP END driver configuration modules.  Among other things, the END
unit number facilitates associating an END driver instance with a specific
physical device in the case of PCI network interface cards.  The END unit
number is not used this way in the case of ISA devices, as explained below.

The BSP configuration modules for PCI network interface cards (NIC)s will
iterate the PCI bus in search of supported NICs.  Whenever a supported
PCI NIC is located on the bus, information on the device is stored in an
internal table.  These internal tables are indexed via END unit numbers
during END device initialization.

The END unit numbering for each entry of a kind in the <endDevTbl> table
should start with 0 and proceed up through positive integers for each
successive entry.  For example, assuming that the system will have two
physical Am79c97x Ethernet devices and an END driver instance
associated with each device, an additional entry should be added to the
<endDevTbl> table as follows:

.CS
END_TBL_ENTRY endDevTbl [] =
    {
    ...
    #ifdef INCLUDE_LN_97X_END
        {0, LN_97X_LOAD_FUNC, LN_97X_LOAD_STR, LN_97X_BUFF_LOAN,
        NULL, FALSE},

        {1, LN_97X_LOAD_FUNC, LN_97X_LOAD_STR, LN_97X_BUFF_LOAN,
        NULL, FALSE},
    #endif /@ INCLUDE_LN_97X_END @/
    ...
    };
.CE

The muxDevLoad() routine will attempt to load two instances of the
ln97xEnd driver.  One instance will have END unit number 0, and the
other will have END unit number 1.  END unit number 0 will be associated
with the first Am79x97x device instance found on the PCI bus, while END
unit 1 will be associated with the subsequent Am79c97x device instance
found on the PCI bus.

Extending the example a bit, suppose that the system will have two
physical Am79x97x Ethernet devices and one Intel 82558 Ethernet device.
The entries defined above could be left intact, while an entry for the
82558 device would be included by virtue of defining the INCLUDE_FEI_END
configuration constant.  The preprocessed table would define the following
entries:

.CS
END_TBL_ENTRY endDevTbl [] =
    {
    ...
        {0, FEI82557_LOAD_FUNC, FEI82557_LOAD_STRING, FEI82557_BUFF_LOAN,
        NULL, FALSE},

        {0, LN_97X_LOAD_FUNC, LN_97X_LOAD_STR, LN_97X_BUFF_LOAN,
        NULL, FALSE},

        {1, LN_97X_LOAD_FUNC, LN_97X_LOAD_STR, LN_97X_BUFF_LOAN,
        NULL, FALSE},
    ...
    };
.CE

In short, for a particular kind of driver and physical device on the PCI
bus, END unit number <n> associates the END driver instance with the <n>th
physical device instance beginning with instance number 0.

Note that the number of physical PCI devices configured for the system
is finite.  The system cannot load more END instances than physical devices.
A constant in each sysXXXEnd.c configuration file specifies how many
physical devices will be configured for a particular driver.  This value
and the associated data structures can be customized.  Read the sysXXXEnd.c
file associated with a particular driver for more information.

In the case of ISA network interface cards, configuration software cannot
dynamically determine memory, IO, and interrupt resources required for such
devices.  As noted previously, the BSP does not support ISA PnP.  Moreover,
the BSP predefines these values for, at most, one physical device instance
of each kind.  As a result, the configuration modules for ISA network
interface cards assume that only one instance of the device will be loaded
to the MUX.  Physical device information is not stored in a table indexed
via the END unit number.  Hence, END unit numbers for ISA network controllers
are arbitrary.  The sysXXXEnd.c configuration modules for ISA NICs can be
customized to store information for multiple physical devices in a table and
index the table via END unit number in a manner similar to the configuration
modules for PCI NICs.  The tables for multiple ISA devices must be defined
and constructed statically when a VxWorks system is compiled.

The BSP sysXXXEnd.c driver configuration modules may not initialize an END
driver for all possible PCI vendor IDs, PCI device IDs, and PCI revision IDs
associated with compatible devices.  In many cases, this is because the
driver has not been tested on the particular device.  The PCI vendor,
device, and revision IDs the driver will be configured for are specified
directly in the sysXXXEnd.c file associated with the driver.  In some
cases, the header file associated with a driver may define PCI ID values.
Refer to the board vendor's documentation and the appropriate sysXXXEnd.c
and END driver header files in cases where the configuration module fails
to initialize a PCI END driver for a specific physical device on the bus.

.SS "VME Access"
This BSP has no VME access

.SS "PCI Access"
In order to use PCI the INCLUDE_PCI
directive must be enabled in config.h.
Furthermore, PCI_CFG_TYPE in pc.h
must be set to the correct configuration type.
Values for PCI_CFG_TYPE must be one of:

.TS
center;
c c
l l.
Macro	meaning
_
PCI_CFG_FORCE	force user specified configuration
PCI_CFG_AUTO	VxWorks does auto configuration. Currently unavailable.
PCI_CFG_NONE	external agent does configuration
.TE

PCI defines two mechanisms. The newer method, and the default vxWorks
method, is PCI_MECHANISM_1. Some older PCs might work better with
the old method, PCI_MECHANISM_2. If PCI is not working with
your older PC, change the first argument to pciConfigLibInit
to PCI_MECHANISM_2 in sysLib.c:
.ne 7
.CS
#ifdef  INCLUDE_PCI
    pciConfigLibInit (PCI_MECHANISM_1, PCI_CONFIG_ADDR, PCI_CONFIG_DATA,
NONE);
#if     FALSE
    pciConfigLibInit (PCI_MECHANISM_2, PCI_CONFIG_CSE, PCI_CONFIG_FORWARD,
                     PCI_CONFIG_BASE);
#endif  /* FALSE */
.CE
.ne 22
.SS "Boot Devices"
The supported boot devices are:
	
.CS
    \f3xx\f1 - Ethernet (any one of the many adaptors described above)
.CE
.CS
    \f3pcmcia=<slot number>\f1 - PCMCIA ATA device
        slot number is one of:
            0 = PCMCIA slot 0
            1 = PCMCIA slot 1
	Note: Supported PCMCIA boot cards are the 3COM Etherlink III PC card
	and a PCMCIA ATA card
.CE
.CS
    \f3fd=<drive number>,<diskette type>\f1 - Diskette
        drive number is one of:
            0 = default; the first diskette drive (drive A:)
            1 = the second diskette drive (drive B:)
        diskette type is one of:
            0 = default; 3.5" diskette
            1 = 5.25" diskette
.CE
.CS
    \f3ata=<controller number>,<drive number>\f1 - ATA/IDE drive
        controller number is one of:
            0 = controller described in the first entry of 
                the ataResources table
            1 = controller described in the second entry of 
                the ataResources table
        drive number is one of:
            0 = first drive on the controller
            1 = second drive on the controller
.CE

A boot EPROM (type 27020 or 27040) is supported 
with Blunk Microsystems' ROM Card 1.0. 
For information on booting from these devices, 
see the Blunk Microsystems documentation.
The program romcard.s, a loader for code programmed in to the EPROM,
is provided to support 
VxWorks with the ROM Card.
In addition, the following configurations are defined in 
the Makefile to generate Motorola S-record format from 
bootrom_uncmp or from vxWorks_boot.st :
.TS
center;
l l.
romcard_bootrom_512.hex	boot	ROM image for 27040 (512 KB)
romcard_bootrom_256.hex	boot	ROM image for 27020 (256 KB)
romcard_vxWorks_st_512.hex	bootable VxWorks image for 27040 (512 KB)
.TE
Neither the ROM Card nor the EPROM is distributed with VxWorks.
For more information visit http://www.blunkmicro.com/

.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 apply only to Ethernet devices

.SS "ROM Considerations"
Not applicable to this BSP

.SH "SPECIAL CONSIDERATIONS"
.SS "Delivered Objects"
.ne 20
.TS
center;
c c
l l.
Object Name	Description
_
vxWorks	T{
An image with no target shell or target symbol table. Network support
is included and initialized.
T}
VxWorks.st	T{
A fully linked standalone image, including a target based
shell, symbol table, and network interface.  Note that the
network interface is not initialized.  There is no WDB agent.
T}
bootrom_uncmp.bin	T{
An uncompressed bootrom image which will run in upper memory by default.
T}
bootrom.bin	T{
A compressed bootrom image which will run in upper memory by default.
T}
mkboot.o	A VxWorks utility for creating boot disks.
.TE

.SS "Make Targets"
The BSP supports the following make targets:

.TS E
expand;
cw(1i) cw(2i) c
lw(1i) lw(2i) l.
Image Name	Description	Comments
=
vxWorks_rom.bin	T{
A high memory uncompressed bootable vxWorks image.
T}
vxWorks.st_rom.bin	T{
A high memory compressed bootable vxWorks.st image.
T}
bootrom.bin	T{
A high memory compressed bootrom.
T}
bootrom_uncmp.bin	T{
A high memory uncompressed bootrom.
T}
vxWorks	The standard "Tornado-style" VxWorks image.