10              5            11              6            12              7            13              8            14              9            15             10IRQs 0 - 7 are handled by PIC1 and IRQs 8 - 15 by PIC2.  PIC2 interrupts arecascaded into PIC1 at IRQ2 which is reflected in the above table.The Fully Nested Mode is used in the default configuration of this BSP.Fully Nested Mode.In this mode, interrupt requests are ordered in priorityfrom 0 through 7 (0 is the highest).  When an interrupt is acknowledged thehighest priority request is determined and its vector is placed on the bus.Additionally, a bit of the Interrupt Service (IS) register is set.  This bitremains set until the microprocessor issues an EOI command immediately beforereturning from the service routine.  While the IS bit is set, all furtherinterrupts of the same or lower priority are inhibited, while higher levelinterrupts are allowed.  The PICs in a PC typically operate in this mode(normal nested mode).  In this mode, while the slave PIC is beingserviced by the master PIC, the slave PIC blocks all higher priorityinterrupt requests.  Alternatively, to allow interrupts of a higher priority,enable the Special Fully Nested Mode.Special Fully Nested Mode: define PIC_SPECIAL_FULLY_NESTED_MODE.This mode is similar to the Fully Nested Mode with the following exceptions:1) When an interrupt request from a slave PIC is in service, the slave isnot locked out from the master's priority logic and further interruptrequests from higher priority IRs within the slave will be recognized bythe master and will initiate interrupts to the processor.  2) When exitingthe interrupt service routine, the software must check whether or not theinterrupt serviced was the only interrupt request from the slave.  If itwas the only interrupt request, a non-specific EOI is sent to the master.If not, no EOI is sent.The PIC(8259A) IRQ0 is hard wired to the PIT(8253) channel 0 in a PCmotherboard.  IRQ0 is the highest priority in the 8259A interruptcontroller.  Thus, the system clock interrupt handler blocks all lowerlevel interrupts.  This may cause a delay of the lower level interrupts insome situations even though the system clock interrupt handler finishes itsjob without any delay.  This is quite natural from the hardware pointof view, but may not be ideal from the application software standpoint.The following modes are supplied to mitigate this situation by providing thecorresponding configuration macros in the BSP.  The three modes aremutually exclusive.Early EOI Issue in IRQ0 ISR: define PIC_EARLY_EOI_IRQ0.In this mode, the EOI is issued before the IRQ0 system clock interruptservice routine starts the kernel work.  This lowers the IRQ0 ISR blockinglevel to the next lower level.  If no IRQs are in service, the next lowerlevel is the lowest level.  If IRQn is in service, the next lower levelcorresponds to the next lower priority.  As a result, the kernel work inthe system clock interrupt service routine can be interrupted by aninterrupt 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 clockservice 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 theinterrupt 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 MPspecification.  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 flagin the CPUID, this mode can be configured and used.To use this mode, define VIRTUAL_WIRE_MODE in config.hSymmetric IO Mode: One of three interrupt modes defined by the MPspecification.  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 processorindicated by APIC feature flag in the CPUID and the IO APIC in the chipsetis 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 ina future Tornado 2.x release.  Wind River Systems' Intel Architecture BSPscontinue to use the following END driver configuration mechanism as ofTornado 2.2 FCS.The BSP configNet.h file contains a static table, <endDevTbl>, thatspecifies END driver instances which must be loaded to the MUX viamuxDevLoad() when the network is initialized.  Each table entry of typeEND_TBL_ENTRY records information the muxDevLoad() routine requires.   TheEND_TBL_ENTRY is defined as follows:.CStypedef 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;.CEThe specified value and use of the END device <unit> number is significantto the BSP END driver configuration modules.  Among other things, the ENDunit number facilitates associating an END driver instance with a specificphysical device in the case of PCI network interface cards.  The END unitnumber 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 williterate the PCI bus in search of supported NICs.  Whenever a supportedPCI NIC is located on the bus, information on the device is stored in aninternal table.  These internal tables are indexed via END unit numbersduring END device initialization.The END unit numbering for each entry of a kind in the <endDevTbl> tableshould start with 0 and proceed up through positive integers for eachsuccessive entry.  For example, assuming that the system will have twophysical Am79c97x Ethernet devices and an END driver instanceassociated with each device, an additional entry should be added to the<endDevTbl> table as follows:.CSEND_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 @/    ...    };.CEThe muxDevLoad() routine will attempt to load two instances of theln97xEnd driver.  One instance will have END unit number 0, and theother will have END unit number 1.  END unit number 0 will be associatedwith the first Am79x97x device instance found on the PCI bus, while ENDunit 1 will be associated with the subsequent Am79c97x device instancefound on the PCI bus.Extending the example a bit, suppose that the system will have twophysical Am79x97x Ethernet devices and one Intel 82558 Ethernet device.The entries defined above could be left intact, while an entry for the82558 device would be included by virtue of defining the INCLUDE_FEI_ENDconfiguration constant.  The preprocessed table would define the followingentries:.CSEND_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},    ...    };.CEIn short, for a particular kind of driver and physical device on the PCIbus, END unit number <n> associates the END driver instance with the <n>thphysical device instance beginning with instance number 0.Note that the number of physical PCI devices configured for the systemis finite.  The system cannot load more END instances than physical devices.A constant in each sysXXXEnd.c configuration file specifies how manyphysical devices will be configured for a particular driver.  This valueand the associated data structures can be customized.  Read the sysXXXEnd.cfile associated with a particular driver for more information.In the case of ISA network interface cards, configuration software cannotdynamically determine memory, IO, and interrupt resources required for suchdevices.  As noted previously, the BSP does not support ISA PnP.  Moreover,the BSP predefines these values for, at most, one physical device instanceof each kind.  As a result, the configuration modules for ISA networkinterface cards assume that only one instance of the device will be loadedto the MUX.  Physical device information is not stored in a table indexedvia the END unit number.  Hence, END unit numbers for ISA network controllersare arbitrary.  The sysXXXEnd.c configuration modules for ISA NICs can becustomized to store information for multiple physical devices in a table andindex the table via END unit number in a manner similar to the configurationmodules for PCI NICs.  The tables for multiple ISA devices must be definedand constructed statically when a VxWorks system is compiled.The BSP sysXXXEnd.c driver configuration modules may not initialize an ENDdriver for all possible PCI vendor IDs, PCI device IDs, and PCI revision IDsassociated with compatible devices.  In many cases, this is because thedriver has not been tested on the particular device.  The PCI vendor,device, and revision IDs the driver will be configured for are specifieddirectly in the sysXXXEnd.c file associated with the driver.  In somecases, the header file associated with a driver may define PCI ID values.Refer to the board vendor's documentation and the appropriate sysXXXEnd.cand END driver header files in cases where the configuration module failsto 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_PCIdirective must be enabled in config.h.Furthermore, PCI_CFG_TYPE in pc.hmust be set to the correct configuration type.Values for PCI_CFG_TYPE must be one of:.TScenter;c cl l.Macro	meaning_PCI_CFG_FORCE	force user specified configurationPCI_CFG_AUTO	VxWorks does auto configuration. Currently unavailable.PCI_CFG_NONE	external agent does configuration.TEPCI defines two mechanisms. The newer method, and the default vxWorksmethod, is PCI_MECHANISM_1. Some older PCs might work better withthe old method, PCI_MECHANISM_2. If PCI is not working withyour older PC, change the first argument to pciConfigLibInitto 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.CEA 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 :.TScenter;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).TENeither 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 isspecified, 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