API Reference: Libraries

Top

# kontron_ktq45

#### NAME

> kontron_ktq45 - Kontron KTQ45/Flex/ATXE

#### DESCRIPTION

> This manual describes the KTQ45/Flex/ATXE board made by KONTRON Technology A/S. The board will also be denoted KTQ45.

> Make sure you are using the most current version of the BIOS for the board.

#### INDEX

>      1.0 INTRODUCTION
>      2.0 BOOT PROCESS
>      -   2.1 Single-stage BootApp
>      -   2.2 Multi-stage BootApp
>      -   2.3 Multi-stage BootApp requirements and usage
>      3.0 BOOT DEVICE AND IMAGE CREATION
>      -   3.1 Creating a bootrom or BootApp image
>      -   3.2 Creating bootable disks.
>      -   3.3 Creating bootable USB flash drive from Linux
>      -   3.4 Creating bootable USB flash drive from Windows
>      -   3.5 Creating bootable hard disks from Linux and Windows
>      -   3.6 Creating bootable devices from VxWorks
>      -   3.7 Creating Multi-Stage bootable images
>      -   3.8 Creating a VIP/VxWorks kernel image
>      -   3.9 Booting VxWorks via PXE
>      -   3.10 Using GRUB to boot vxWorks
>      4.0 FEATURES
>      -   4.1 List of Hardware Features
>      -   4.2 Feature Interactions
>      5.0 HARDWARE DETAILS
>      -   5.1 Jumpers & Switches
>      -   5.2 BIOS Settings
>      -   5.3 Memory Maps
>      -   5.4 Serial Configuration
>      -   5.5 Network Configuration
>      -   5.6 Devices
>      -   5.7 USB Host Support
>      -   5.8 Boot Devices
>      -   5.9 Boot Methods
>      6.0 SPECIAL CONSIDERATIONS
>      -   6.1 Make Targets
>      -   6.2 BSP Bootloaders and Bootroms
>      -   6.3 BSP Validated Tools
>      -   6.4 Special Routines
>      -   6.5 BIOS E820 Memory Auto-size
>      -   6.6 Warm Boot Devices
>      -   6.7 Changing AP startup time in SMP based configuration
>      7.0 KNOWN PROBLEMS
>      8.0 BOARD LAYOUT
>      9.0 SEE ALSO
>      10.0 BIBLIOGRAPHY

#### 1.0 INTRODUCTION

> This reference entry provides board-specific information necessary to run VxWorks for the Kontron KTQ45 BSP.

> The KTQ45 board is based on the Intel® Q45 + ICH10DO Embedded chipset, supports Intel® CoreTM2 Duo & Intel® CoreTM2 Quad incl. E8400 & Q9650 desktop CPU.

> Due to the complexity of hardware and configuration, the use of editing config.h is not recommended. The use of vxprj or Workbench with board bundles is preferred.

> Unless it's one of the supported targets, boards based on technology similar to one of the targets supported by this BSP are not guaranteed to work. Boards with custom or modified BIOS's are not guaranteed to work. WindRiver does not provide BIOS updates.

> Before using a board with VxWorks, verify that the board runs in the factory configuration by using vendor-supplied ROMs and jumper settings.

> Refer to`HARDWARE DETAILS' section for CRB specific setup requirements, hardware problems and work-arounds.

> For best results, the board vendor's documentation should be used in conjunction with this document.

#### 2.0 BOOT PROCESS

> This section discuss the different boot mechanisms available for use and supported by this BSP.

#### 2.1 Single-stage BootApp

> Single-stage BootApp is the same BootApp that is available in previous versions of VxWorks (prior to 6.9.2).

> In single-stage BootApps, the system BIOS code loads and executes the bootstrap loader when the board is powered on. The bootstrap loader is written in x86 16-bit assembly language. The BIOS obtains the bootstrap loader from the boot sector, which may be in one of several locations: an USB 2.0 key, a hard disk, or some other alternative. When the BIOS finds the bootstrap loader, it transfers execution to it. The bootstrap loader finds the bootrom.sys file, loads it into memory, and transfers execution to romInit.

> Size of single-stage bootrom.sys file must be less than or equal to 589824 (ROM_SIZE) bytes, otherwise the boot process will fail. It is a restriction for IA boot disks. If the image size is larger than 589824 bytes, the build process will also fail. Please refer to "Multi-stage BootApp" section below for methods of overcoming this limitation.

#### 2.2 Multi-stage BootApp

> Multi-stage BootApp is being introduced to overcome the 589824 (0x90000) byte limitation of single-stage BootApp.

> Multi-stage BootApps consist of two stages. Stage one will replace the original bootrom.sys and will be much smaller in size. The original bootrom.sys will become stage two and will be renamed as bootapp.sys.

> The MBR (Master Boot Record) will behave the same as with the original mechanism, but the device information will be used to locate the bootrom.sys (copied from vxStage1Boot.bin) image, via the int 0x13 BIOS interface, which is then read into low memory at location 0x8000 (FIRST_TEXT_ADRS), again using the int 0x13 BIOS interface. This small first stage boot loader will then load the second stage bootapp.sys (copied from vxWorks_romCompress.bin) file into memory location ROM_TEXT_ADRS and jump into 32 bit mode, and then start romInit. The value of ROM_TEXT_ADRS macro differs between single-stage and multi-stage BootApps.

> The second stage works as the original. It decompresses the bootrom vxImage to RAM_DST_ADRS (RAM_LOW_ADRS of BootApp for project builds) while in 32 bit mode and executes vxImage which gives the bootrom prompt.

> Multi-stage BootApp can operate in several different modes.

> Fast reboot mode is enabled by including BUNDLE_MSB_FAST_REBOOT (includes INCLUDE_MULTI_STAGE_BOOT and INCLUDE_FAST_REBOOT components). In this mode, second stage saves a copy of itself to a memory area at the end of the VxWorks system memory (sysMemTop( )). Checksum is saved with a copy of the image. This second stage copy is restored on warm reboots after checksum is checked. For fast reboots, warm reboots will jump back to the original entry point in stage 1 at 0x8010 (FIRST_TEXT_ADRS+ROM_WARM_HIGH). This entry point will restore the previously saved second stage memory and jump to it. Some RAM is used for the second stage image copy.

> If fast reboot is not enabled by only including the INCLUDE_MULTI_STAGE_BOOT component, only cold reboots are done. This is due to many BIOS'es not being able to re-access the boot device on a warm reboot if the device has also been initialized by VxWorks. For example, if a high speed USB flash drive is used as the boot device, BIOS is not able to re-access the drive on a warm reboot if BootApp or VxWorks is built with INCLUDE_EHCI. Another example is if a SATA drive is used as the boot device, BIOS is not able to re-access the drive on a warm reboot if BootApp or VxWorks image is built with INCLUDE_DRV_STORAGE_AHCI. No RAM is used for second stage image copy.

> If the user wishes to do non-fast-reboot warm reboots anyway to save RAM space, BUNDLE_MSB_WARM_REBOOT (includes INCLUDE_MULTI_STAGE_BOOT and INCLUDE_MULTI_STAGE_WARM_REBOOT components) can be included; however, care should be taken not to initialize the boot device in BootApp and VxWorks. In these cases, warm reboots will jump back to the original entry point in stage 1 at 0x8010 (FIRST_TEXT_ADRS+ROM_WARM_HIGH). This entry point will jump back to 16 bit mode and start everything from scratch, loading the second stage bootapp.sys file again from the boot media and so on. No RAM is used for second stage image copy.

>     NOTE: INCLUDE_FAST_REBOOT and INCLUDE_MULTI_STAGE_WARM_REBOOT
>           components cannot be included at the same time.  This also means that
>           BUNDLE_MSB_FAST_REBOOT and BUNDLE_MSB_WARM_REBOOT cannot be added at
>           the same time.

> The default value of multi-stage BootApp ROM_SIZE is set to 2,097,152 (0x200000) bytes; however, macro and parameter values can be modified to change this value.

#### 2.3 Multi-stage BootApp requirements and usage

> Currently only the use of the GNU compiler is supported with Multi-stage boot. The first stage source file vxStage1Boot.s is hand coded for use with the GNU compiler directives.

> The first stage is vxStage1Boot.bin (as bootrom.sys) the second stage is vxWorks_romCompress.bin (as bootapp.sys) and the third stage is VxWorks kernel itself. All these three stages must agree on the common addresses used by them all, BOOT_IMAGE_ADRS and BOOT_IMAGE_SIZE. All the required values are inherited and available via the following definitions already present in BSP and OS.

>         #define BOOT_IMAGE_ADRS (LOCAL_MEM_LOCAL_ADRS + BOOT_IMAGE_ADRS_OFFSET)
>         #define BOOT_IMAGE_ADRS_OFFSET (BOOT_MULTI_STAGE_DATA_OFFSET)
>         #define BOOT_MULTI_STAGE_DATA_OFFSET 0x5000

>         #define BOOT_IMAGE_SIZE (LOCAL_MEM_LOCAL_ADRS + BOOT_IMAGE_SIZE_OFFSET)
>         #define BOOT_IMAGE_SIZE_OFFSET (BOOT_IMAGE_ADRS_OFFSET + BOOT_IMAGE_ADRS_OFFSET_SIZE)
>         #define BOOT_IMAGE_ADRS_OFFSET_SIZE 4

> When building your multi-stage BootApp and your VxWorks kernel image project, you need to include the (agreed upon) multi-stage boot bundle in both the BootApp and the VxWorks kernel. Both the BootApp and the kernel need to include the same bundle.

>         vxprj bundle add BUNDLE_MSB_FAST_REBOOT
>         or
>         vxprj bundle add BUNDLE_MSB_WARM_REBOOT

> When building your multi-stage BootApp project (vxprj or Workbench) you need to set the ROM_SIZE and ROM_TEXT_ADRS via a build macro. This is not required for the VxWorks kernel projects. This is required since the original non-multi-stage boot values are inherited via the Makefile in the BSP, and we need to adjust them for a project build without editing the Makefile.

>         vxprj buildmacro set ROM_SIZE 00200000
>         vxprj buildmacro set ROM_TEXT_ADRS 00408000

#### 3.0 BOOT DEVICE AND IMAGE CREATION

> This section describes how to prepare boot devices and BootApp images to load VxWorks.

#### 3.1 Creating a bootrom or BootApp image

> Create a BootApp image using the vxprj facility:

>             vxprj create kontron_ktq45 gnu kontron_ktq45_gnu_bootapp -profile PROFILE_BOOTAPP_BASIC
>             cd kontron_ktq45_gnu_bootapp

> Complete build

>             vxprj build set default_romCompress
>             vxprj build vxWorks_romCompress.bin

> Alternately, a VxWorks Image Project that is configured as a BOOTAPP can be generated
> by creating a VIP with the BOOTAPP Profile.

> A BOOTAPP VIP can be created using a Command Line build, vxprj, or WorkBench. If building
> with WorkBench, select default_romCompress as the Active Build Spec, select the Board Bundle,
> and build the vxWorks.bin target.

> If building with Workbench then open a VxWorks Development Shell

>             vxprj create -force -profile PROFILE_BOOTAPP_BASIC kontron_ktq45 gnu kontron_ktq45_gnu
>             cd kontron_ktq45_gnu

> Complete build

>             vxprj build set default_romCompress
>             vxprj build vxWorks_romCompress.bin

#### 3.2 Creating bootable disks.

> You may use a USB flash disk or hard disk to boot VxWorks. You must boot from a primary bootable partition on the primary disk as seen by the PC BIOS. VxWorks is also bootable over the network.

> 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.

#### 3.3 Creating bootable USB flash drive from Linux

> 1. Set up USB flash drive on host

> a. Find the USB drive device name. The USB flash drive is usually
> named /dev/sdb. Partitions on the drive are then named
> /dev/sdb1, /dev/sdb2, and so on. It is important to verify the
> naming as it may be some other variant beginning with
> /dev/sd. After inserting the USB drive, perform the following
> commands:

>           % su root
>           % /sbin/fdisk -l

> The output includes something like the following:

>           ...
>           Disk /dev/sdb: 16 MB, 16138240 bytes
>           1 heads, 31 sectors/track, 1016 cylinders
>           Units = cylinders of 31 * 512 = 15872 bytes

>              Device Boot Start End Blocks Id System

>              Device Boot      Start         End      Blocks   Id  System
>           /dev/sdb1   *           1        1016       15732+   6  FAT16

> The exact output depends on the flash drive type and existing
> partitions.

> b. Examine the fdisk output to verify that the sector size is 512
> bytes.

> CAUTION: If the sector size is not 512 bytes, the USB drive will
> probably not work for booting with vxld. (vxld is a small 16-bit
> utility that is loaded by the BIOS from the USB flash
> drive. vxld in turn loads bootrom.sys from the USB flash drive
> and passes control to the boot application.)

> In the preceding example output, the following element indicates
> that the sector size is 512:

>           cylinders of 31 * 512 = 15872 bytes

> Another method for verifying the size of the sectors is simply
> to run the /bin/dmesg utility after inserting the USB drive. The
> output should include a line like this:

>           SCSI device sdb: 2083840 512-byte hdwr sectors (1067 MB)

> CAUTION: If the drive name is not /dev/sdb, be sure to
> substitute the correct name in the steps described below.

> 2. Create a Boot Partition

> Linux provides various tools for partitioning disks. This
> section discusses parted and fdisk. Note that these utilities do
> not work with some USB flash drives. Wind River recommends using
> a USB flash drive from a major producer that has a capacity of
> no more than 1 GB. The sector size must be 512 bytes.

> Using parted

> a. Change to root user and start parted, as follows:

>           % su root
>           % /sbin/parted /dev/sdb

> b. Check the existing partition structure on the drive. At the
> (parted) prompt, enter print, as follows:

>           (parted) print
>             Model: SanDisk Cruzer Micro (scsi)
>             Disk /dev/sdb: 512MB
>             Sector size (logical/physical): 512B/512B
>             Partition Table: msdos
>             Number  Start   End    Size   Type     File system  Flags
>              1      31.7kB  512MB  512MB  primary  fat16        boot, lba

> c. If the output from the print command indicates that the
> partition table is not msdos, remove the table and create a
> new one, and create a new partition, using the following
> commands:

> 1) mktable to change the disk label.
> 2) y to continue.
> 3) msdos for the new disk label.
> 4) mkpart to create a new partition.
> 5) primary for the partition type.
> 6) fat16 for the file system type.
> 7) Enter 0 for start.
> 8) Enter size for the end. Use the size of the drive.

> d. If the output from the print command indicates that the file
> system of partition 1 is not fat16, delete the existing
> partition, and create a new one using the following commands:

> 1) rm 1 to delete the partition.
> 2) mkpart to create a new partition.
> 3) primary for the partition type.
> 4) fat16 for the file system type.
> 5) Enter 0 for start.
> 6) Enter size for the end. Use the size of the drive.

> e. If the output from the print command does not include the
> boot flag, use the following command:

>           toggle 1 boot

> f. If necessary, execute print again to verify the msdos
> partition table with bootable FAT16 file system. The lba flag
> may be missing.

> g. Exit parted with the quit command.

> Using fdisk

> a. Change to root user and start fdisk, as follows:

>           % su root
>           % /sbin/fdisk /dev/sdb

> b. Then use the following commands:

> a) p to show the existing partitions.
> b) d to delete it.
> c) p again to show any remaining partitions (if partitions
> exist, repeat the previous step).
> d) n to make a new partition.
> e) p for primary partition.
> f) 1 to make this the first partition.
> g) ENTER to use the default first cylinder.
> h) Enter size to set the partition size. Use the size of the
> drive, or ENTER to accept default, unless the drive is
> larger than 2 GB.
> i) a to make this partition active.
> j) 1 to select partition 1.
> k) t to change the partition file system.
> l) 6 to select the FAT16 file system.
> m) w to write the new partition table.

> Note: that the partition size should be less than or equal
> to the smaller of either the flash drive size or 2 GB. fdisk
> accepts various syntaxes for specifying the partition size
> (for example, +128M). You can also simply use the ENTER key
> to accept the default, unless the drive is larger than 2 GB.

> 3. Add Boot Loader to Drive

> a. Copy $WIND_BASE/host/$WIND_HOST_TYPE/bin/vxld.bin from your
> VxWorks installation to another location on your host
> machine. vxld is a small 16-bit utility that is loaded by the
> BIOS from the USB flash drive. vxld in turn loads bootrom.sys
> from the USB Flash Drive and passes control to the boot
> application.

> b. If using single-stage BootApp, rename the 64-bit VxWorks boot
> loader file you previously created from vxWorks_romCompress.bin
> to bootrom.sys and copy it to the same location. If using
> multi-stage BootApp, rename the 64-bit VxWorks boot loader file
> you previously created from vxStage1Boot.bin to bootrom.sys and
> copy it to the same location.

> c. Configure the mtools drive name by editing (as root)
> /etc/mtools.conf, adding the following new entry for the USB
> drive:

>           drive u: file="/dev/sdb1"

> Note: u: is an arbitrary (but logical) drive name for
> USB. See the mtools man page for more information.

> d. From the directory in which the images are located, format
> the partition and copy the bootrom.sys file, sync the drive,
> and then eject it, as follows:

>           % su root
>           % mformat u: -B vxld.bin
>           % mcopy bootrom.sys u:
>           % sync
>           % eject /dev/sdb1

> e. Unplug the USB Flash drive from your Linux host.

> f. Plug the USB Flash drive into your target and change the BIOS
> setting to boot from USB flash drive.

#### 3.4 Creating bootable USB flash drive from Windows

> You will require the mkbt.exe utility and possibly the diskpart.exe utility that is distributed with Windows. The diskpart utility will be used to correct disks that do not have a partition set to active. The mkbt utility is used to extract important boot parameters required by the BIOS, from a valid bootsect.bin file, and write it to the boot parameters in the MBR (master boot record) of the USB drive.

> 1. Set up USB flash drive on host

> a. Download free software mkbt20 from
> ftp://dl.xs4all.nl/pub/mirror/nu2files/mkbt20.zip, or
> http://ftp.rz.tu-bs.de/pub/mirror/www.nu2.nu/nu2files/mkbt20.zip
> and extract it to BSP directory

> b. Insert a USB flash drive to host and find the USB drive device name.

> 2. Create a Boot Partition and Add Boot Loader to Drive

> a. In a DOS command shell run the following commands to ensure USB drive is
> Configured correctly for mkbt

> Execute diskpart as administrator, and then list the disks.

> NOTE: Commands below are indicated after the `DISKPART>" prompt.

>           DISKPART> list disk

>             Disk ###  Status         Size     Free     Dyn  Gpt
>             --------  -------------  -------  -------  ---  ---
>             Disk 0    Online          465 GB  1024 KB
>             Disk 1    Online         1907 MB      0 B

> Observe USB drive number in the displayed list (USB is Disk 1) and select disk 1

>           DISKPART> select disk 1

>           Disk 1 is now the selected disk.

> List disks again to make sure you have the correct drive selected, indicated
> by the "*" character.

>           DISKPART> list disk

>             Disk ###  Status         Size     Free     Dyn  Gpt
>             --------  -------------  -------  -------  ---  ---
>             Disk 0    Online          465 GB  1024 KB
>           * Disk 1    Online         1907 MB      0 B

> Clean the disk, create primary partition and make it active as indicated below.

>           DISKPART> clean

>           DiskPart succeeded in cleaning the disk.

>           DISKPART> create partition primary

>           DiskPart succeeded in creating the specified partition.

>           DISKPART> select partition 1

>           Partition 1 is now the selected partition.

>           DISKPART> active

>           DiskPart marked the current partition as active.

> Now format the disk as fat. It will take about 2 minutes, depending on the disk size.

>           DISKPART> format fs=fat

>             100 percent completed

>           Diskpart successfully formatted the volume.

> Assign a drive letter and exit.

>           DISKPART> assign

>           DiskPart successfully assigned the drive letter or mount point.

>           DISKPART> exit

> Note the drive letter that is assigned to the USB drive. We will use this
> drive letter with the mkbt utility.

> b. In the BSP directory, run the following command (this example
> assumes that the drive letter is g:):

>           mkbt -x bootsect.bin g:

> Following information will be shown :

>           * Expert mode (-x)
>           * Warning different filesystem ID
>           Size=0bytes OEM="MSDOS5.0" VolLabel="NO NAME" FileSys="FAT16"

> c. If using single-stage BootApp, run the following command to copy
> the generated vxWorks_romCompress.bin to the USB key as
> bootrom.sys. If using multi-stage BootApp, copy
> vxStage1Boot.bin to the USB key as bootrom.sys. The image on
> the USB key MUST be contiguous or the first stage of the boot
> will fail. A contiguous image can be generated by saving all
> images from the USB key to a temporary location, deleting all
> images from USB key, and then copying each image back to the USB
> key.

> If single-stage BOOTAPP image is being used

>             cp "project directory"/default_romCompress/vxWorks_romCompress.bin g:bootrom.sys

>             or

>             cp "project directory"/default_romCompress/vxWorks_romCompress.bin /media/"device"/bootrom.sys

> d. If using multi-stage BootApp, also copy vxWorks_romCompress.bin
> as bootapp.sys to the USB key.

> For multi-stage BootApp:

>           copy vxWorks_romCompress.bin g:bootapp.sys

> e. Unplug the USB Flash drive from your Windows host.

> f. Plug the USB Flash drive into your target and change the BIOS
> setting to boot from USB flash drive.

> 3. Booting with the created USB drive

> Insert the USB key into the Core2 board and reset. Change the BIOS setting to
> boot from the USB. After the VxWorks bootrom boots up, you will see following:

>                                 VxWorks System Boot

>                     Copyright 1984-2014  Wind River Systems, Inc.

>                     CPU: Intel(R) Core2 Processor SYMMETRIC IO Kontron KTQ45 Board
>                     Version: VxWorks 6.9
>                     BSP version: R03.00
>                     Creation date: Jan 30 2014 19:27:36

>             Press any key to stop auto-boot...

>             [VxWorks Boot]:

> If you want to boot VxWorks image from USB key, include the component
> INCLUDE_USB in your BootApp project and rebuild your bootrom. (default is enable)

>         vxprj component add INCLUDE_USB

> Some USB key's might not be found after the bootrom boots up. Try
> removing and reinserting the USB key.
> Enter following command in VxWorks Boot Shell,

>             [VxWorks Boot]: devs

> You will see following:

>             drv name
>                0 /null
>                1 /tyCo/0
>                1 /tyCo/1
>                6 host:
>                3 /bd0

>             [VxWorks Boot]: ?

> You will see some information as following:

>            Device Formats:
>              boot device: fs                  file name: /bdx/vxWorks

>            Boot Flags:
>              0x02 -   load local system symbols
>              0x04 -   don't autoboot
>              0x08 -   quick autoboot (no countdown)
>              0x80 -   use tftp to get boot image

>            Available Boot Devices:
>              Filesystem Devices:  /bd0  bd0
>              Enhanced Network Devices: gei0
>            [VxWorks Boot]:

> The "/bd0" shows VxWorks bootrom found the USB key, Then enter c command in
> VxWorks Boot Shell to change boot device to "fs", file name to "/bd0/vxWorks",
> other field to "gei0" to activate ethernet connection, save it. Finally, enter
> @ command to start VxWorks image, and you'll see VxWorks shell.

>         NOTE: As of the writing of this document, network initialization
>               does not work using the bootline's other field when target is
>               booted off of an ahci or ich storage device.  As a workaround, the
>               initialization process can be completed manually after boot by
>               doing something like:

>         ipcom_drv_eth_init "gei", 0, 0
>         ifconfig "gei0 90.0.0.50 netmask 255.255.255.224 up"

#### 3.5 Creating bootable hard disks from Linux and Windows

> Connect a SATA hard disk to host and format a partition of less than 2GB in FAT format (not FAT32). Then, follow the same procedure as when making a bootable USB flash drive. Reconnect the SATA drive to the target board, and Change the BIOS setting to boot from the SATA drive.

#### 3.6 Creating bootable devices from VxWorks

> In order to prepare a bootable device (USB disk or hard disk), you have to initially (ONCE only) boot VxWorks over the network using a bootable USB flash drive or via PXE (Please refer to "Booting VxWorks via PXE" section) and configure the hard disk using the VxWorks target shell.

> VxWorks image can be created as follows:

>                vxprj create kontron_ktq45 gnu kontron_ktq45_gnu
>                cd kontron_ktq45_gnu

> Include the following components

>                vxprj component add INCLUDE_XBD
>                vxprj component add INCLUDE_XBD_BLK_DEV
>                vxprj component add INCLUDE_XBD_PART_LIB
>                vxprj component add INCLUDE_XBD_RAMDRV
>                vxprj component add INCLUDE_DOSFS
>                vxprj component add INCLUDE_FS_MONITOR
>                vxprj component add INCLUDE_SHELL
>                vxprj component add INCLUDE_DRV_STORAGE_AHCI
>                vxprj component add INCLUDE_DRV_STORAGE_PIIX
>                vxprj component add INCLUDE_USB_INIT
>                vxprj component add INCLUDE_EHCI_INIT
>                vxprj component add INCLUDE_USB_MS_BULKONLY_INIT
>                vxprj component add INCLUDE_MKBOOT

> Build the project

>                vxprj build

> Attach a boot device (a SATA hard disk, an IDE hard disk or an USB
> flash disk) to the board. Load the generated VxWorks image into the
> target and from the target shell, enter the command:

>             -> devs
>             drv name
>               0 /null
>               1 /tyCo/0
>               1 /tyCo/1
>               4 /ata0:1
>               5 /bd0
>               host:
>               6 /vio

> You will see an USB flash disk is shown as "/bd0" and a hard disk is
> shown as "/ata0:1". Actually you may connect a hard disk to any port,
> and the device name would shown as "/atax:1", "x" means the port number.
> This document will cite port 0 as an example.

> From the target shell prompt, enter the command:

>              -> xbdCreatePartition  "/bd0", 2, 99
>              or
>              -> xbdCreatePartition  "/ata0:1", 4, 33, 33, 33

> Note: Any bootable hard disk partition should not exceed 2 GB. The
> parameters "4, 33, 33, 33" specifies that there should be 4
> partitions, part0, part1, part2, part3. The partitions part1, 2,
> and 3 are created with "33 percent" of the disk capacity and the
> rest would be allocated to part0. The command does not specify the
> amount of the first partition size.

> With a 80GB drive. The above command creates 4 partitions, the
> last of partitions with sizes of 33%, 33%, 33% respectively. The
> bootable partition gets 1% (i.e. 100 minus 33 minus 33 minus 33 = 1%),
> which is less than 2GB on a 80 GB hard disk.

> From the target shell prompt, enter the command:

>             ->devs
>             drv name
>               0 /null
>               2 /tyCo/0
>               2 /tyCo/1
>               4 /ata0:1
>               5 /ata0:2
>               5 /ata0:3
>               5 /ata0:4
>               6 /bd0
>               7 /bd0:2
>               host:
>               10 /vio

> Execute "dosFsVolFormat" command:

>              -> dosFsVolFormat "/bd0"
>              or
>              -> dosFsVolFormat "/ata0:1"

> Now, execute a command to install a FreeBSD style bootloader onto the
> first sector of a disk.

>              -> vxmbr "/bd0"
>              or
>              -> vxmbr "/ata0:1"

> Install a boot loader onto a partition boot sector.

>              -> vxsys "/bd0",0,0
>              or
>              -> vxsys "/ata0:1",0,0

> Copy bootrom.bin to the boot disk as bootrom.sys file.

>             copy "host:bootrom.bin","/bd0/bootrom.sys"
>             or
>             copy "host:bootrom.bin","/ata0:1/bootrom.sys"

> Reboot the target board, change the BIOS settings to boot from the boot
> device. After the VxWorks bootrom boots up, the following will be displayed:

>                                 VxWorks System Boot

>                     Copyright 1984-2014  Wind River Systems, Inc.

>                     CPU: Intel(R) Core2 Processor SYMMETRIC IO Kontron KTQ45 Board
>                     Version: VxWorks 6.9
>                     BSP version: R03.00
>                     Creation date: Jan 30 2014 19:27:36

>             Press any key to stop auto-boot...

>             [VxWorks Boot]:

#### 3.7 Creating Multi-Stage bootable images

> Because of architecture limitations, the Intel Architecture boot process runs in the first 640KB of memory, which limits the size of the compressed boot image (BootApp) to approximately 576KB. This size limitation restricts the number and/or combinations of components included in a BootApp, leading to significantly reduced functionality. Using a multi-stage boot loader will allow the use of very large (>1GB) compressed BootApp images.

>         NOTE: For multi-stage boot, VxWorks and bootrom must apply the same
>               multi-stage boot bundle selections (BUNDLE_MSB_FAST_REBOOT or
>               BUNDLE_MSB_WARM_REBOOT) as the BootApp.

> 1) Creating a bootrom image using the vxprj facility.
> Open a VxWorks Development Shell, in the BSP directory
> "$(WIND_BASE)/target/config/kontron_ktq45", run the command:

>             vxprj create kontron_ktq45 gnu kontron_ktq45_gnu_bootapp -profile PROFILE_BOOTAPP_BASIC
>             cd kontron_ktq45_gnu_bootapp

> Set default build

>             vxprj build set default_romCompress

> Add a Multi-stage boot bundle

>             vxprj bundle add BUNDLE_MSB_FAST_REBOOT
>             or
>             vxprj bundle add BUNDLE_MSB_WARM_REBOOT

> Set bootrom size and entry point

>             vxprj buildmacro set ROM_SIZE 00200000
>             vxprj buildmacro set ROM_TEXT_ADRS 00408000

> Complete build

>             vxprj build vxWorks_romCompress.bin
>             vxprj build vxStage1Boot.bin

> vxStage1Boot.bin is copied as bootrom.sys to the root directory of the bootable media first.
> Now vxWorks_romCompress.bin is copied as bootapp.sys to the root directory of the bootable
> media as the second file.

> In addition to the vxStage1Boot.bin stage 1 boot file, a PXE bootfile can be built.
> Simply add the following to the above project.

>            vxprj build vxStage1Boot.pxe

> vxStage1Boot.pxe is copied as bootrom.pxe in PXE tftp directory.
> vxWorks_romCompress.bin is copied as bootapp.sys in PXE tftp directory.

> 2) Creating a bootrom images using Workbench.

> a. If using Workbench, use the following steps to build vxWorks_romCompress.bin

>             -> File
>               -> New
>                 -> Other
>                   -> VxWorks Image Project
>                      Specify your project name in "Project name:" field
>                     -> Next
>                        Specify "BSP:" kontron_ktq45
>                        Specify "Tool chain:" as gnu
>                       -> Next
>                         -> Next
>                            Specify "Profile:" as PROFILE_BOOTAPP_BASIC
>                           -> Next
>                             -> Finish

>             -> Right click on project just created
>               -> Build Options
>                 -> Set Active Build Spec...
>                   -> default_romCompress

>             -> Right click on project just created
>               -> Edit Kernel Configuration
>                 -> Click on Bundles tab
>                   -> Add one of the following bundles:
>                      "Multi Stage Boot Fast Reboot bundle" (BUNDLE_MSB_FAST_REBOOT)
>                      -- or --
>                      "Multi Stage Boot Warm Reboot bundle" (BUNDLE_MSB_WARM_REBOOT)

>             -> Right click on project just created
>               -> Properties
>                 -> Build Properties
>                   -> Click on Variables tab
>                     -> Modify ROM_SIZE to 00200000
>                     -> Modify ROM_TEXT_ADRS to 00408000
>                       -> OK

>             -> Right click on "vxWorks.bin (default_romCompress)"
>               -> Build Target

> b. Use the following steps to build vxStage1Boot.bin

>             -> Right click on project from above
>               -> New
>                 -> Build Target
>                    Specify "Build target name:" as vxStage1Boot.bin
>                   -> Finish

>             -> Right click on "vxStage1Boot.bin (default_romCompress)"
>               -> Build Target

> vxStage1Boot.bin is copied as bootrom.sys to the root directory of the bootable media first.
> Now vxWorks_romCompress.bin is copied as bootapp.sys to the root directory of the bootable
> media as the second file.

> c. Use the following steps to build vxStage1Boot.pxe

>             -> Right click on project from above
>               -> New
>                 -> Build Target
>                    Specify "Build target name:" as vxStage1Boot.pxe
>                   -> Finish

>             -> Right click on "vxStage1Boot.pxe (default_romCompress)"
>               -> Build Target

> vxStage1Boot.pxe is copied as bootrom.pxe in PXE tftp directory.
> vxWorks_romCompress.bin is copied as bootapp.sys in PXE tftp directory.

> 3) NOTES

> BUNDLE_MSB_WARM_REBOOT requires that neither the bootrom nor the VxWorks kernel
> shall touch the UHCI or EHCI devices. This implies that all USB related components
> must be removed from both the bootrom project and VxWorks kernel project.

>                 vxprj component remove INCLUDE_USB
>                 vxprj component remove INCLUDE_UHCI
>                 vxprj component remove INCLUDE_UHCI_INIT
>                 vxprj component remove INCLUDE_EHCI
>                 vxprj component remove INCLUDE_EHCI_INIT
>                 vxprj component remove INCLUDE_SYS_WARM_USB

> When BUNDLE_MSB_WARM_REBOOT is used, and ACPI is included in either the bootrom or
> VxWorks kernel, make sure the BIOS does not enable automatic handover to the OS.
> ACPI touches all devices whether or not drivers for the devices are loaded. When
> hand-off to OS for EHCI is enabled, the BIOS would lose control over the EHCI the moment
> ACPI discovers the EHCI devices. VxWorks itself does a hand-off from the BIOS to the OS
> if USB device drivers are included, so the BIOS setting is not required.
> Most BIOS's do not have this setting, so this can be ignored.
> To disable automatic handover if your BIOS have the setting present, enter the BIOS and
> change the following setting:

>                 "Advanced"
>                     --> "USB Configuration"
>                         --> "BIOS EHCI Hand-Off" set to [Disabled]

#### 3.8 Creating a VIP/VxWorks kernel image

> There are two ways to create a VIP/VxWorks kernel that can be loaded via a bootrom/BootApp. The first is to do it via a VxWorks Development Shell using the vxprj facility. The second way is to use Workbench.

> 1) Creating a VxWorks kernel image using the vxprj facility.

> Open a VxWorks Development Shell in the project directory "$WIND_BASE/target/proj".

> Now run the following commands to create your kernel project directory:

> To create a VxWorks kernel for the KTQ45:

>         vxprj create -force kontron_ktq45 gnu kontron_ktq45_gnu
>         vxprj bundle add gnu kontron_ktq45_gnu/gnu kontron_ktq45_gnu.wpj BUNDLE_BEARLAKE

> Add extra desired bundles and/or components that you want to include into your VIP/VxWorks project.

> Now build your project. It can be done by entering your project directory and then simply typing "vxprj build". This will automatically use the WPJ file from the current project directory.

> Alternatively you can execute the build command from the same directory the project creation commands were given: "$WIND_BASE/target/proj"

> To build VxWorks kernel image:

>         vxprj build gnu kontron_ktq45_gnu/gnu kontron_ktq45_gnu.wpj

> 2) Creating a VxWorks kernel image using Workbench.

> Use the following steps to build VxWorks kernel image

>         -> File
>           -> New
>             -> Other
>               -> VxWorks Image Project
>                  Specify your project name in "Project name:" field
>                 -> Next
>                    Specify "BSP:" kontron_ktq45
>                    Specify "Tool chain:" as gnu
>                   -> Next
>                      Tick SMP support if desired and supported by your CRB
>                      Tick other available options if desired
>                     -> Next
>                        Leave profile on default (no profile)
>                       -> Next
>                         -> Finish

>         -> Right click on "vxWorks (default)"
>           -> Build Target

> VxWorks should be copied to a location accessible by the bootrom/BootApp.

> 3) NOTES

> When using a multi-stage BootApp to load vxWorks, VxWorks and bootrom must apply the same multi-stage boot bundle selections (BUNDLE_MSB_FAST_REBOOT or BUNDLE_MSB_WARM_REBOOT) as the BootApp.

> Adding the required bundle via VxWorks Development shell

> Change directory to your project directory "$WIND_BASE/target/proj/projectDir"

>         vxprj bundle add BUNDLE_MSB_FAST_REBOOT
>         -- or --
>         vxprj bundle add BUNDLE_MSB_WARM_REBOOT

> Now rebuild your project

>         vxprj build

> Adding the required bundle via Workbench

>         -> Right click on your project
>           -> Edit Kernel Configuration
>             -> Click on Bundles tab
>               -> Add one of the following bundles:
>                  "Multi Stage Boot Fast Reboot bundle" (BUNDLE_MSB_FAST_REBOOT)
>                  -- or --
>                  "Multi Stage Boot Warm Reboot bundle" (BUNDLE_MSB_WARM_REBOOT)

> Now rebuild your project

>         -> Right click on "vxWorks (default)"
>           -> Build Target

#### 3.9 Booting VxWorks via PXE

> It is possible to boot VxWorks via the network using PXE (the Preboot eXecution Environment). PXE support may be provided either by the BIOS on motherboards with integrated ethernet ports, or by standalone ethernet adapters with PXE ROMs. Many of the Intel PRO/100 and PRO/1000 cards (supported by the fei and gei drivers) with management features include PXE ROM support. The advantage to using PXE is that no boot disk is necessary.

> Another alternative is to use the publicly available gPXE bootloader (http://etherboot.org/wiki/) for PXE boot. If BIOS provided or ethernet adapter provided PXE ROM does not work well with VxWorks BootApp, gPXE can be tried. Both single-stage and multi-stage PXE BootApps were tested with the latest gPXE as of 04/08/2011 (version 1.0.1+).

>     NOTE: Multi-stage PXE BootApp has been found to not boot properly
>           with the BIOS PXE on KTQ45; however, it boots successfully with
>           gPXE.

> The vxWorks_romCompress.pxe (single-stage BootApp) or vxStage1Boot.pxe (multi-stage BootApp) loader is virtually identical to the normal vxWorks_romCompress.bin or vxStage1Boot.bin, except that it has an extra block of padding prepended to it. When booting from disk, the vxld.bin loader is normally loaded by the BIOS at address 0x7C00. It then in turn loads the BootApp at address 0x8000 and starts it running. By contrast, when booting with PXE, the BootApp is loaded directly at address 0x7C00 by the PXE ROM. A leading block of 1024 NOP instructions is therefore used to force the actual romInit( ) entry point to fall at address 0x8000, just as it would as if it had been loaded from disk.

> For multi-stage PXE boot, first stage boot loader can use PXE's underyling UNDI (Universal Network Device Interface) API to load the second stage bootapp.sys. int 0x1A PXE BIOS interface is used to determine whether BootApp has been loaded via PXE. If it is a PXE load, "PXENV+" structure is retrieved. Next, "!PXE" is retrieved (offset from beginning of "PXENV+" structure). Subsequent PXENV_GET_CACHED_INFO PXE API call (using additional information from "!PXE") is used to retrieve the TFTP host and TFTP directory information. Finally, PXENV_TFTP_READ_FILE PXE API call is be used to load the second stage bootapp.sys file. First stage boot will only support accessing PXE API functions using "!PXE" structure as specified above.

> A single-stage vxWorks_romCompress.pxe loader can be created by the following command (pxeBoot.bin is in the BSP directory):

>         cat pxeBoot.bin vxWorks_romCompress.bin > vxWorks_romCompress.pxe

> Alternatively, the following command can be used from the project directory:

>         vxprj build vxWorks_romCompress.pxe

> A multi-stage vxStage1Boot.pxe loader can be created by the following command (pxeBoot.bin is in the BSP directory):

>         cat pxeBoot.bin vxStage1Boot.bin > vxStage1Boot.pxe

> Alternatively, the following command can be used from the project directory:

>         vxprj build vxStage1Boot.pxe

> PXE booting requires the use of a DHCP and TFTP server. When the PXE ROM starts up, it will use DHCP to discover an IP address and the path for the BootApp file. Generally, the PXE ROM assumes that the DHCP and TFTP servers will be running on the same machine. Exactly how you configure the DHCP and TFTP servers will depend on what software is used. DHCP and TFTP support is available for most UNIX/Linux/BSD systems, as well as for Microsoft Windows (R). The following sample setup instructions explain how to configure the open source ISC DHCP server running on a FreeBSD system.

> Assume that your client machine is on the 10.0.0.0/32 network, and that your DHCP/TFTP server's IP address is 10.0.0.1. When the PXE client is started up, the PXE ROM should display the station address of the ethernet port. We will assume the address is 00:00:E8:01:02:03, and that we want to assign the target an IP address of 10.0.0.3. Given this, we need to create a dhcpd.conf file as follows:

>         # dhcpd.conf
>         #
>         # Sample PXE boot configuration file for ISC dhcpd
>         #

>         ddns-update-style none;

>         subnet 10.0.0.0 netmask 255.255.255.0 {
>           range 10.0.0.3 10.0.0.3;
>           deny unknown-clients;
>           host vxWorks_pentium_target {
>             hardware ethernet 00:00:e8:01:02:03;
>           }
>           option routers 10.0.0.1;
>           option broadcast-address 10.0.0.255;
>           filename "/bootrom.pxe";
>           default-lease-time 600;
>           max-lease-time 7200;
>         }

> Start the DHCP server with the following command, as superuser:

>         # dhcpd -cf /path/to/dhcpd.conf

> Next, edit the /etc/inetd.conf file to enable the TFTP service, and insure inetd is started. The enable inetd, edit the /etc/rc.conf file and add a line that says inetd_enable="YES" then run the following commands:

>         # sh /etc/rc.d/inetd stop
>         # sh /etc/rc.d/inetd start

> Lastly, create a /tftpboot directory. For single-stage BootApp, copy vxWorks_romCompress.pxe as bootrom.pxe in /tftpboot directory. For multi-stage BootApp, copy vxStage1Boot.pxe as bootrom.pxe in /tftpboot directory and also copy vxWorks_romCompress.bin as bootapp.sys in /tftpboot directory.

> Once this setup has been done, reboot the PXE client system. It should display output similar to the following:

>     CLIENT MAC ADDR: 00 00 E8 01 02 03  GUID: xxxxxxxx xxxx xxxx xxxx xxxxxxxxxxxx
>     CLIENT IP: 10.0.0.3  MASK: 255.255.255.0  DHCP IP: 10.0.0.1
>     GATEWAY IP: 10.0.0.1
>     TFTP...

> Very shortly after this output appears, the VxWorks BootApp should start up and the BootApp startup banner should be displayed. At this point, you can enter the desired VxWorks boot parameters and use the BootApp to load a VxWorks image.

> Important notes:

> - PXE is a 16-bit real mode environment. Consequently, boot
> applications downloaded via PXE are limited in that they must be
> able to start up in 16-bit real mode, and they must be less than
> 640K in size. The VxWorks vxWorks_romCompress.bin (single-stage
> BootApp) and vxStage1Boot.bin (multi-stage BootApp) images meet
> these requirements, however standalone VxWorks images might not.

> - The PXE environment also provides a universal API for accessing the
> underlying ethernet device, however VxWorks has no support for this
> feature. This means that while you can download the VxWorks BootApp
> via any PXE-enabled ethernet device, a native driver for the
> ethernet device must be available in VxWorks in order for the
> BootApp to subsequently download a VxWorks image (or for the
> downloaded VxWorks image to be able to use the ethernet port).

#### 3.10 Using GRUB to boot vxWorks

> NOTE: This BSP does not support using GRUB to load BootApp.

> We can boot VxWorks using GRUB. To build a GRUB bootable VxWorks image, simply add the GRUB_MULTIBOOT component to your VxWorks image project:

>     vxprj component add GRUB_MULTIBOOT

> Above command automatically adds INCLUDE_MPTABLE_BOOT_OP component to the project. Please refer to "MP APIC Configuration Using Workbench Command Line Tools" section.

> NOTE: When loaded using GRUB, additional memory configuration may be necessary in order to utilize all the RAM available. Please refer to "BIOS E820 Memory Auto-size" section.

> The GRUB implementation of VxWorks adheres to the Multiboot Specification. The Multiboot Specification information passed to the operating system were acquired from the BIOS.

> The GRUB VxWorks image uses the default boot line specified using the DEFAULT_BOOT_LINE parameter if not specified in GRUB's grub.cfg file. The default boot line can be passed from GRUB to VxWorks by specifying the optional sysbootline parameter in grub.cfg file. The following is a sample grub.cfg file (for GRUB2 version 1.98):

>     # The following lines configures both keyboard and serial port for input.
>     # Both VGA console and serial ports are used for output.
>     # Serial port is configured for 9600 baud.
>     serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
>     terminal_output serial console
>     terminal_input serial console

>     set default=0
>     set timeout=30
>     set root=(hd0,1)

>     menuentry "vxWorks" {
>         multiboot /images/vxWorks sysbootline:gei(0,0)host:vxWorks h=90.0.0.3 e=90.0.0.50 u=target
>     }

> The GRUB VxWorks image does not support "warm" boot. reboot/CTRL-X methods all force "cold" boot.

> For more information on GRUB and the Multiboot Specification please refer to:

>     http://www.gnu.org/software/grub/
>     http://www.gnu.org/software/grub/manual/multiboot/multiboot.html

#### 4.0 FEATURES

> This section describes all features of the board, supported or not. It documents all configurations of the board and the interaction between features and configuration items.

#### 4.1 List of Hardware Features

> Hardware Interface | Controller | Driver/Component | Status
> --- | --- | --- | ---
> UART:0 | PCIe | vxbNs16550Sio.c | SUPPORTED
> PCH Ethernet | on-chip | gei825xxVxbEnd.c | SUPPORTED
> 1GB-ETHERNET:0 | PCIe | rtl8169VxbEnd.c | SUPPORTED
> SATA/AHCI | on-chip | vxbIntelAhciStorage.c | SUPPORTED
> SATA/IDE | on-chip | vxbPiixStorage.c | SUPPORTED
> GRAPHICS | on-chip | vxbM6845Vga.c | SUPPORTED
> PS2 | on-chip | vxbI8042Kbd.c | SUPPORTED
> TIMER | on-chip | vxbI8253Timer.c | SUPPORTED
> RTC | on-chip | vxbMc146818Rtc.c | SUPPORTED
> USB2-HOST | on-chip | USB EHCI driver | SUPPORTED
> FAN/Temp/Voltage sensors | W83627 | libkontron.a | SUPPORTED
> Watchdog | W83627 | libkontron.a | SUPPORTED
> SMBus | on-chip | libkontron.a | SUPPORTED
> GPIO | W83627 | libkontron.a | SUPPORTED
> KEAPI GUI | n/a | keapi_fs.o | SUPPORTED
> Intruder Status | on-chip | KEAPI | SUPPORTED
> USB2-DEVICE | on-chip | n/a | UNSUPPORTED
> USB1-HOST | on-chip | n/a | UNSUPPORTED
> SD/MMC-CARD | on-chip | n/a | UNSUPPORTED
> VIDEO-DECODE | on-chip | n/a | UNSUPPORTED
> AUDIO | on-chip | n/a | UNSUPPORTED
> LPC | on-chip | n/a | UNSUPPORTED

#### 4.2 Feature Interactions

> Refer to the board vendor's documentation.

#### 5.0 HARDWARE DETAILS

> This section documents the details of the device drivers and board hardware elements. Problems interacting with a CRB or getting it to boot are discussed in this section.

#### 5.1 Jumpers & Switches

> Please refer to the board vendor's documentation.

#### 5.2 BIOS Settings

> The BSP was validated against KTQ45 with the following BIOS version:

>        BIOS Vendor                       AMIBIOS
>        Version                                   08.00.15
>        Build Date                        03/01/11
>        ID                                                            KTQ450011
>        Serial #                                                      A2

> This BSP was validated with the following processor.

>        Intel(R) Core(TM)2 Quad CPU Q94000
>        Speed                             2666 MHz
>        Number of Processors              1 CPU(s) / 4 Core(s)

> This BSP was validated with 1 gigabyte of system memory.

> This BSP supports both AHCI and IDE SATA hard drives. BIOS settings should be changed according to which kind of hard drives are used.

#### 5.3 Memory Maps

> Refer to VxWorks Memory Layout section in VxWorks Architecture Supplement and the VxWorks BSP Developers Guide for information regarding memory mapping.

#### 5.4 Serial Configuration

> Default configuration is:
> Baud Rate: 115200
> Data: 8 bit
> Parity: None
> Stop: 1 bit
> Flow Control: None

#### 5.5 Network Configuration

> This BSP provides support for VxBus drivers, including network drivers. The list of VxBus network drivers available for PCIe devices includes the following:

>         INCLUDE_FEI8255X_VXB_END
>         INCLUDE_GEI825XX_VXB_END
>         INCLUDE_RTL8169_VXB_END
>         INCLUDE_END

> For command line builds using the vxprj facility, add the desired driver.

> Example adding the GEI driver:

>         vxprj component add INCLUDE_GEI825XX_VXB_END

> The Intel(R) Pro/1000PT 82572EI Gigabit Ethernet adapter is one of the tested PCIe device supported in this release.

> The following END and corresponding END2 drivers are supported in this BSP. However, only END driver is enabled by default.

> Driver | END | END2
> --- | --- | ---
> GEI | INCLUDE_GEI825XX_VXB_END | INCLUDE_GEI825XX_VXB_END2

> To enable the END2 driver, you should modify your configuration as follows:

> For project build under Workbench, in the Kernel Configuration Window of your created VxWorks Image Project, add INCLUDE_END2 component and corresponding END2 component, this will un-define END automatically. Then rebuild your project.

#### 5.6 Devices

> PC Console

>   This function will use PC monitor as VxWorks console. To use these controllers the INCLUDE_PC_CONSOLE component must be included in your vxprj or Workbench project. Only PS2 keyboard is supported.

>           vxprj component add INCLUDE_PC_CONSOLE

> ns16550

>   Used for the serial ports.

> vxbPiixStorage

>   Vxbus Driver for the IDE/ATA hard disk controller. To use this driver, include the INCLUDE_DRV_STORAGE_PIIX component in your vxprj or Workbench project.

>           vxprj component add INCLUDE_DRV_STORAGE_PIIX

> vxbAhciStorage

>   Vxbus Driver for the SATA hard disk controller. To use this driver, include the INCLUDE_DRV_STORAGE_AHCI component in your vxprj or Workbench project.

>           vxprj component add INCLUDE_DRV_STORAGE_AHCI

> vxbI8253Timer

>   This library contains a board-independent interface for manipulating the timer functions on Intel(R) 8253 and compatible timer chip devices. Timer 0 is used as system clock, According to different applications, timer 1,2 has different usage.

> vxbIntelAhciStorage (patched version) and vxbIntelAhciStorageShow

>   Vxbus Driver for the SATA hard disk controller. To use this driver, the INCLUDE_DRV_STORAGE_INTEL_AHCI must be included in your vxprj or Workbench project.

> vxbMc146818Rtc

>   This is the driver for the real time clock (based on the Motorola MC146818).

> vxbIntelTimestamp

>   This is the driver for the timestamp on Intel(R) chipsets. To use the timestamp feature, include the INCLUDE_TIMESTAMP component in your vxprj or Workbench project.

>           vxprj component add INCLUDE_TIMESTAMP

> vxbLoApicTimer

>   This library contains routines to manipulate the timer functions on the Intel(R) P6 (PentiumPro, II, and III) and P7 (Pentium4) family processor's Local APIC/xAPIC Timer with a board-independent interface.

> APIC/xAPIC frequency

>   At initialization, the vxbLoApicTimer timer driver calculates the clock frequency of the Local APIC/xAPIC Timer only when the APIC_TIMER_CLOCK_HZ parameter is set to 0 (default). Otherwise, the specified value will be applied as the clock frequency. If this value is set manually, it must match the actual frequency of the timer hardware to ensure accurate timekeeping. Platform specific operating frequencies can only be obtained from the appropriate Intel proprietary documentation.

>   This value can be set using workbench or with the vxprj commmand line (VIP):

>       vxprj parameter set APIC_TIMER_CLOCK_HZ 133330000

> i8259Intr

>   Driver for the Intel(R) 8259A Programmable Interrupt Controller (PIC). IRQs 0 - 7 are handled by PIC1 and IRQs 8 - 15 by PIC2. PIC2 interrupts are cascaded into PIC1 at IRQ2 .The Fully Nested Mode is used in the default configuration of this BSP.

> gei825xxVxbEnd

>   This library supports the PCH integrated ethernet driver.

> INCLUDE_CFG_GEI8254X_END_1
> INCLUDE_CFG_GEI8254X_END_2

>   These components are providing support for configuration of the onboard Gigabit Ethernet Interface at the front panel connector and/or REAR-IO. It sets the network mask and internet address of the interface to the values defined for CFG_GEI_X_MASK and CFG_GEI_X_ADDR. You can modify both parameters within the Workbench project facility. It is allowed to set CFG_GEI_X_ADDR to "dhcp", in this case the NIC will use DHCP client to retrieve IP information (Note: INCLUDE_IPDHCPC component has to be enabled to use this facility).

>   This component requires INCLUDE_GEI825XX_VXB_END GEI driver.

> KONTRON_KEAPI2_BSP_SUPPORT

>   This component provides support for KEAPI. The W83672 and SMBus pch drivers are required. KEAPI uses the Winbond watchdog which is also used by BIOS.

> DRV_SMBUS_INTEL_PCH

>   This component includes Intel PCH Smbus driver. This module implements a driver for the Intel PCH SMBus controller.

> DRV_W83627

>   This component includes W83627 voltage, fan and temperature sensor driver, watchdog driver. This is 3rdparty driver provided by Kontron. See the driver documenation for further details.

>   NOTE: Note that the following components are not supported by this BSP

>       INCLUDE_ATA

>   replaced by

>       INCLUDE_DRV_STORAGE_PIIX

#### 5.7 USB Host Support

> A standard USB EHCI controller is supported in this BSP. Please refer to Wind River's USB documents.

#### 5.8 Boot Devices

> The supported boot devices are:

> gei0 | - Primary Ethernet (10baseT, 100baseTX, or 1000baseT)
> ata0:1 | - AHCI/IDE drive
> fs | - USB disk

#### 5.9 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 to 0x80, TFTP protocol is used.

#### 6.0 SPECIAL CONSIDERATIONS

> This section discuss special features and/or restrictions of boards supported by this BSP.

#### 6.1 Make Targets

> The make targets are listed as the names of object-format files. Other images not listed here may not be tested. All "make" targets in this section is specific to the KTQ45 CRB base configuration only and may not work with other configurations or boards supported by this BSP.

>         `bootrom'
>         `bootrom.bin'
>         `vxWorks' (with `vxWorks.sym')
>         `vxWorks.st'

#### 6.2 BSP Bootloaders and Bootroms

> Bootloader/Bootrom | Status
> --- | ---
> BIOS (pre-flashed) | SUPPORTED
> bootrom | SUPPORTED
> bootrom_uncmp | UNSUPPORTED
> vxWorks | SUPPORTED
> vxWorks_rom | UNSUPPORTED
> vxWorks_romCompress | SUPPORTED
> vxWorks_romResident | UNSUPPORTED
> vxStage1Boot | SUPPORTED

> vxWorks_romCompress

>   SUPPORTED only for PROFILE_BOOTAPP_BASIC and default_romCompress build. When the bootrom image size is too large (larger than 589824 bytes), it is required to make use of the Multi-Stage boot mechanism described in the BOOT PROCESS section.

#### 6.3 BSP Validated Tools

> Tool | Connection/Type | Status
> --- | --- | ---
> Workbench Debugger | ETHERNET/WDB | SUPPORTED
> Workbench System Viewer | ETHERNET/WDB | SUPPORTED
> Workbench MemScope | ETHERNET/WDB | SUPPORTED
> Workbench ProfileScope | ETHERNET/WDB | SUPPORTED
> Workbench StethoScope | ETHERNET/WDB | SUPPORTED
> Workbench CoverageScope | ETHERNET/WDB | SUPPORTED
> Workbench Core File Analysis | ETHERNET/WDB | UNVALIDATED
> Workbench Sensor Points | ETHERNET/WDB | UNVALIDATED
> Workbench OCD Debugger | JTAG | SUPPORTED
> Workbench OCD Flash | JTAG | UNSUPPORTED

#### 6.4 Special Routines

> The following routines are specific to this BSP and are available to the user. They are written in assembly code in sysALib.s. For further details, please refer to following entries:

> sysInByte( ) | input one byte from I/O space
> sysInWord( ) | input one word from I/O space
> sysInLong( ) | input one long-word from I/O space
> sysOutByte( ) | output one byte to I/O space
> sysOutWord( ) | output one word to I/O space
> sysOutLong( ) | output one long-word to I/O space
> sysInWordString( ) | input word string from I/O space
> sysInLongString( ) | input long string from I/O space
> sysOutWordString( ) | output word string to I/O space
> sysOutLongString( ) | output long string to I/O space

#### 6.5 BIOS E820 Memory Auto-size

> Intel(R) memory auto-size support using E820 BIOS memory map information. Using the 0x15 interrupt with function code 0xe820, the physical RAM memory map can be retrieved from the BIOS. The data returned is a set of descriptors containing the memory range start address, length, and type. The data is acquired while in 16 bit REAL mode during cold boot in the bootrom, and stored in a fixed location in reserved memory. This data is in turn consumed by the VxWorks image during startup to dynamically adjust the top of memory. Additional memory segments beyond the one located at LOCAL_MEM_LOCAL_ADRS are automatically mapped to the MMU.

> By default, BIOS E820 memory auto sizing is enabled. To disable, add the INCLUDE_NO_MEM_AUTOSIZE component to your project.

>         vxprj component add INCLUDE_NO_MEM_AUTOSIZE

> When BIOS E820 memory auto sizing is disabled, the LOCAL_MEM_SIZE parameter must be set to reflect the top of usable memory. This value is typically the system ram size minus the on-board memory base (0x00100000). For a system with .75 GB of installed system ram (0x30000000) the LOCAL_MEM_SIZE parameter would be 0x2ff00000 (0x30000000-0x00100000). On 32-bit platforms, the system ram size typically cannot exceed 3.4GB.

>         vxprj parameter set LOCAL_MEM_SIZE 0x2ff00000

#### 6.6 Warm Boot Devices

> To select the warm start device in a vxprj based image, add the corresponding component to the project and the SYS_WARM_TYPE parameter will automatically be set using the requested type.

> NOTE: Note that the following components are not supported by this BSP

>     INCLUDE_SYS_WARM_FD
>     INCLUDE_SYS_WARM_TFFS

> Supported components for warm boot device selection:

>     INCLUDE_SYS_WARM_BIOS
>     INCLUDE_SYS_WARM_USB
>     INCLUDE_SYS_WARM_ICH
>     INCLUDE_SYS_WARM_AHCI

> Example: To add warm start from BIOS

>         vxprj component add INCLUDE_SYS_WARM_BIOS

#### 6.7 Changing AP startup time in SMP based configuration

> This BSP supports configuring the time allowed to determine if an application processor succeeded in starting up. Two variables are used to control the number of times to test, and how long to wait between tests.

> Variables SYS_AP_LOOP_COUNT and SYS_AP_TIMEOUT can be changed in your vxprj project

>         vxprj parameter set SYS_AP_LOOP_COUNT 200000
>         vxprj parameter set SYS_AP_TIMEOUT 10

> It is also visible under your Workbench project BSP build parameters.

>             -> Right click on your project
>               -> Edit Kernel Configuration
>                 -> Click on Components tab
>                   -> Expand "Hardware"
>                     -> Expand "kontron_ktq45 BSP configuration options"
>                       -> Expand "BSP build parameters"
>                          -> Change value for SYS_AP_LOOP_COUNT as desired.
>                          -> Change value for SYS_AP_TIMEOUT as desired.

>         Now rebuild you project.

> SYS_AP_TIMEOUT time is specified in microseconds and should be short in duration. SYS_AP_LOOP_COUNT times SYS_AP_TIMEOUT gives the total time to wait for an AP before giving up and moving on to the next application processor.

#### 7.0 KNOWN PROBLEMS

> This section discuss problems that have been observed on some platforms and workarounds if available.

#### 8.0 BOARD LAYOUT

> Please consult your board vendor documentation for the board layout.

#### 9.0 SEE ALSO

> VxWorks User's Guide: Getting Started

> VxWorks Programmer's Guide: Configuration

> VxWorks Programmer's Guide: Architecture Supplement

#### 10.0 BIBLIOGRAPHY

> Intel(R) Architecture Software Developer's Manual, Volume 1: Basic Architecture

> Intel(R) Architecture Software Developer's Manual, Volume 2: Instruction Set Reference

> Intel(R) Architecture Software Developer's Manual, Volume 3: System Programming Guide

> AP-485, Intel(R) Processor Identification and the CPUID Instruction

> PCI System Architecture, Fourth Edition, Addison-Wesley, 1999, ISBN 0-201-30974-2

> KTQ45/Flex Users Guide (KTD-00782-I)