target.nr

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

.CE

You may also use a hard disk to boot VxWorks.   You must boot from a 
primary bootable partition on the primary disk as seen by the PC BIOS.  

It is recommended that you use FDISK or a similar utility to create 
the primary bootable partition.   The reason is that FDISK uses 
PC BIOS calls to create the disks master boot record.  The BIOS is 
responsible for loading the boot loader during the boot process.   
Therefore, a utility that uses the BIOS to write partitions, such as 
FDISK, is recommended.  

The partition and file system on the disk may be either FAT12, or FAT16, 
or VxWorks proprietary VXLONGNAMES file system.  FAT32 is not supported 
by the boot loader.  If you need FAT32, make a small primary boot partition 
that is FAT16, and a second larger partition that is FAT32 atop the 
remainder of the disk.

To create a bootable hard disk, replace "c:" for "a:" in the 
above example.  When you use c:, vxsys.com will ask you the following:

.CS
That's a hard disk!  Are you sure (y/n)? 
.CE

You should enter a "y" to indicate approval of the operation.
Be aware that this will prevent other operating systems from 
booting on the disk.

.SS "Creating bootable diskettes from vxWorks"

The usage of the three VxWorks boot utilities is as follows:
.ne 15
.CS
STATUS mkbootFd
    (
    int drive,    /* destination drive number: (0 - 3)  */
    int fdType,   /* type of floppy disk: (0 - 1)       */
    char *in      /* source file name                   */
    )

STATUS mkbootAta 
    (
    int ctrl,     /* dest. controller number: (0 - 1)   */
    int drive,    /* dest. drive number: (0 - 1)        */
    char *in      /* source file name                   */
    )

STATUS mkbootTffs
    (
    int drive,       /* drive number: (0 - TFFS_MAX_DRIVES - 1) */
    int removable,   /* removable or not: (TRUE - FALSE)        */
    char *in         /* source file name                        */
    )
.CE
All routines return OK on success and ERROR if there is an error while
copying the image from the source onto the disk.  The source code for
these routines is in the BSP file mkboot.c

EXAMPLES:

Example 1: Creating a boot floppy disk using mkbootFd:

The floppy disk is in drive 0 (or a:), the diskette is of type 0,
and the image file name is `bootrom.sys':
.CS
    -> mkbootFd 0, 0, "bootrom.sys"
.CE
Example 2: Creating a bootable hard disk using mkbootFd:

The hard disk is on ATA controller 0 and is drive number 0
(or c:). The image file name is `bootrom.sys':
.CS
    -> mkbootAta 0, 0, "bootrom.sys"
.CE
Example 3: Creating a bootable TrueFFS disk using mkbootTffs:

The TrueFFS disk is drive 0 (or c:), that is a non removable drive.
The image file name is `bootrom.sys':
.CS
    -> mkbootTffs 0, 0, "bootrom.sys"
.CE

These boards do not have non-volatile RAM; thus, boot parameters are not
preserved whenever the system is powered off.  However, static boot
parameters can be set in the boot disk by setting the boot parameter line
DEFAULT_BOOT_LINE in config.h.

The Bootrom Utilities

vxsys.com drive:

This command installs a VxWorks bootstrap loader in a drive boot sector. 
The drive can be either a diskette (drive A:), or a hard disk that is 
searched by the BIOS bootstrap.  The VxWorks bootstrap loader searches for
the file bootrom.sys in the root directory and loads it directly into
memory at linear address 0x8000.  Execution then jumps to romInit() at 0x8000.

NOTE: After a bootstrap loader is installed in the disk boot sector, you do not
need to repeat the vxsys operation for new ROM images.  Just copy a new boot
image to the disk that has already had a boot sector installed.

vxld.bin

vxld.bin is neither a command nor a program, rather it is a copy of the
boot sector installed onto a disk or diskette by vxsys.com.  It is
separately included to facilitate creating boot diskettes from Solaris or
Linux as well as allowing support for some alternative third-party boot
loaders.

mkboot drive: source_file

This command is an MS-DOS batch file that uses vxsys.com to install the VxWorks
bootstrap loader in the drive boot sector, and then uses copy to transfer
source_file to drive:bootrom.sys. It also runs the MS-DOS utility chkdsk to
check whether bootrom.sys is contiguous.

vxload.com [image_file]

This command is used during an MS-DOS session to load and execute the
VxWorks image, typically the bootrom image. It can be more
convenient or quicker than loading the image via the PC boot cycle. 
vxload takes a parameter, the image file name.  vxload.com is not
compatible with any version of Microsoft Windows, it is only supported
under MS-DOS. 


VxWorks low memory images run within a memory range from 0x8000 to 0xa0000.
This restricts the size of the memory pool available to drivers in such
images.  The INCLUDE_ADD_BOOTMEM configuration option in config.h enables
runtime code which will add a specified amount of upper memory (memory above
physical address 0x100000) to the memory pool of an image in lower memory.
This option cannot be used on systems with less than 4MB of memory.

The default value for ADDED_BOOTMEM_SIZE, the amount of memory to add
to a lower memory image's memory pool, is 2MB.  This value may be increased,
but one must ensure that the pool does not overlap with the downloaded
vxWorks image when the INCLUDE_ADD_BOOTMEM option is used for lower memory
boot images.  If there is an overlap, then loading the vxWorks runtime
image will corrupt the added memory pool.

The calculation for determining the ADDED_BOOTMEM_SIZE value is:

.CS
    (RAM_LOW_ADRS + vxWorks image size) < (memTopPhys + ADDED_BOOTMEM_SIZE)
.CE

Where <memTopPhys> is calculated in the BSP sysLib.c file.


.SS "New Reboot Mechanism"
The new mechanism saves the brand new bootrom image to the top of
the physical memory in sysPhysMemTop(), and restores it when reboot
in sysToMonitor().  The saved image is protected by the MMU during
runtime of the VxWorks.  This mechanism is independent of the BIOS
boot devices, is faster and simpler than the current method.  It 
also preserves the boot line.  This reboot mechanism assumes that 
the brand new bootrom image is kept in the lower memory when it is 
saved.  That means the bootrom image need to be located in the 
upper memory.  To do this, the RAM_LOW_ADRS and RAM_HIGH_ADRS need 
to be changed in both config.h and Makefile in the BSP.  Then build 
the bootrom and VxWorks image with defining FAST_REBOOT macro.  The 
recommended RAM_LOW_ADRS is 0x00608000, RAM_HIGH_ADRS is 0x00408000.
The FAST_REBOOT macro can be defined statically in config.h or 
dynamically in the command line as "make EXTRA_DEFINE=-DFAST_REBOOT".  
This macro is defined automatically for the BSPs configured for the
Asymmetric Multi Processing, such as ones suffixed with _bp or _ap.
The memory size LOCAL_MEM_SIZE may need to be increased for larger 
page sizes.  Note that the bootrom image in your boot device needs 
to be updated before downloading the new VxWorks image that contains 
this mechanism.


.SS "Jumpers"
Refer to the board vendor's documentation.

.SH "FEATURES"
Since this is a generic BSP for generic PC style motherboards,
your board may or may not have all of these features, and your
board may have some features not discussed here.
Your board vendor's documentation should be used in conjunction 
with this section.

.SS "Supported Features"
Supported features are discussed below in the "Devices" section
under the "HARDWARE DETAILS" heading.

.SS "Unsupported Features"

This BSP does not support ISA PnP (Plug and Play). Such devices can
be supported if PnP is disabled and the device parameters (IO address,
Memory address, IRQ, DMA channel etc) are set to match those in the
BSP driver configuration. If the device uses soft-configuration
instead of jumpers, an appropriate utility program, usually available
from the device manufacturer, should be used to set the device parameters.

.SS "Feature Interactions"
Refer to the board vendor's documentation.

.SH "HARDWARE DETAILS"
This section documents the details of the device drivers and board
hardware elements.

.SS "Devices"
Drivers included with this BSP are for both on-board chips
and for separate adaptor cards that can be used with the
motherboard.
Refer to the vendor's documentation for both the motherboard and
any adaptor cards used. Vendor documentation for on-board
chips may be necessary also.

Note that for all ISA drivers, the I/O base address,
memory address, and interrupt level must match those in config.h
or pc.h.

In the table below, drivers ending in the .c extension are
delivered in source form; the other drivers are delivered
in object form only.
    
.TS
center;
l l.
i8250Sio.c	Intel UART tty driver
i8237Dma.c	8237 DMA driver
pcConsole.c	console driver
i8042Kbd.c	Intel keyboard controller
i8048Kbd.c	Intel keyboard controller
m6845Vga.c	Motorola M6845 VGA controller
nec765Fd.c	nec765 floppy disk controller
ataDrv.c	IDE/ATA hard disk controller
ataShow.c	IDE/ATA hard disk controller show routines
aic7880Lib.o	AHA-2940 PCI SCSI Adapter card
i8253Timer.c	Intel 8253 timer driver
loApicTimer.c	Intel Pentium/2/3/4 Local APIC/xAPIC Timer library
i8259Intr.c	Intel 8259 PIC
loApicIntr.c	Intel Pentium/2/3/4 Local APIC/xAPIC driver
loApicIntrShow.c	Intel Pentium/2/3/4 Local APIC/xAPIC driver show routine
ioApicIntr.c	Intel IO APIC/xAPIC driver
ioApicIntrShow.c	Intel IO APIC/xAPIC driver show routine
nullNvRam.c	null NVRAM library
nullVme.c	null VMEbus library
pciConfigLib.c	PCI configuration space access support for PCI drivers
pciIntLib.c	PCI shared interrupt support
pcmciaLib.c	PCMCIA driver
pcmciaShow.c	PCMCIA driver show routine
fei82557End.o	Intel EtherExpress PRO100B PCI END driver
gei82543End.o	Intel PRO1000X/F/XT/XF PCI END driver
ln97xEnd.o	AMD Am79C97X PCI END driver
elt3c509End.o	3COM 3C509 END driver
el3c90xEnd.o	3COM 3C90x PCI END driver
ultraEnd.o	SMC Elite Ultra END driver
dec21x40End.o	DEC 21x4x PCI END driver
ne2000End.o	Novell/Eagle 2000 END driver
lptDrv.c	Parallel port driver
.TE

Below are some brief notes on each driver.
For more details refer to the
entry for each driver in the Libraries section of the 
.I "VxWorks Reference Manual".

.IP "i8250Sio"
Intel 8250 Universal Asynchronous 
Receiver Transmitter (UART) tty driver.
Used for the serial ports

.IP "i8237Dma"
Driver for the ISA DMA controller.
This is used in nec765Fd.c, which also
serves as a good application example.

.IP "pcConsole, i8042Kbd and i8048Kbd"
Driver for the on-board Intel 8042 and 8048 keyboard controllers
To use these controllers
the INCLUDE_PC_CONSOLE directive must be enabled in config.h.  
The macro
PC_KBD_TYPE should be defined in config.h as PC_PS2_101_KBD to include
i8042Kbd.c, and as PC_XT_83_KBD to include i8048Kbd.c.

.IP "m6845Vga"
Driver for the Motorola M6845 VGA controller.
To use this controller, define INCLUDE_PC_CONSOLE in config.h.

.IP "nec765Fd"
Driver for the nec765 floppy disk controller.
To use this driver, the INCLUDE_FD directive must be enabled in
config.h.

.IP "ataDrv and ataShow"
Driver for the IDE/ATA hard disk controller.  
To use this driver, the INCLUDE_ATA directive must be enabled in config.h. 
Note that the old INCLUDE_IDE directive is replaced by INCLUDE_ATA,
and that vxsys() is replaced by mkbootFd() and mkbootAta().

By default, with INCLUDE_ATA, vxWorks is set up for one ATA hard disk
device on the primary ATA controller and one drive on a secondary
controller.  If a system has more than two controllers or more than one
drive per controller, then configuration constants in config.h, and
possibly the <ataResources> table in sysLib.c, must be modified to support
additional drives and controllers.

For example, suppose that the system's ATA controller zero has two
physical drives.  Modify the ATA0_NUM_DRIVES constant in config.h such
that the defined value is 2, instead of the default value of 1:

.CS
    /@ config.h @/
    ...
    #define ATA0_NUM_DRIVES (2)
    ...
.CE

Note that the BSP config.h and sysLib.c files predefine ATA configuration
values and <ataResources> table entries for at most two controllers.  Such
a limited configuration will not be representative of every target system.

Consider the case of a system with a hard disk on the primary controller,
a CD-ROM device on a secondary controller, and a PCMCIA device on a third
controller.  The default <ataResources> table must be modified such that
ataDrv can initialize and use all of the controllers on such system.
Specifically, one should define additional configuration constants which
are then used to initialize a third controller entry in the <ataResources>
table in a manner similar to the following:

.ne 34
.CS
...
ATA_RESOURCE ataResources[ATA_MAX_CTRLS] =
    {
    /@ ATA controller zero resources @/
    {
    /@ ATA 0 initializers ... @/
    },

    /@ ATA controller one resources @/
    {
    /@ ATA 1 initializers ... @/
    },