Home
Developer Resources
Technical Articles

QNX Technical Articles

QNX® Momentics® 6.3.0 Intel IXDP2800 BSP 1.0.1 Release Notes

QNX® Momentics® 6.3.0

Date of this edition: April 11, 2005

Target OS: QNX® Neutrino® 6.3.0 SP1

Host OS: Microsoft Windows XP SP1 or SP2; Microsoft Windows 2000 SP4; Sun Solaris 7/8; QNX® Neutrino® 6.3.0 SP1; Linux (Red Hat 8/9)

Boards supported: Intel IXDP2800 revision B1


Note:
  • You need to have installed QNX Momentics 6.3.0 SP1 before installing this BSP.
  • For information on installing this BSP, see the installation note.
  • For the most up-to-date version of these release notes, log into your myQNX account, and then go to the Download Center area of www.qnx.com.
  • This BSP doesn't include the Intel SDK for the IXDP2800 board. To get the SDK, please contact Intel.

Contents


Note: Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number. You might also find the reference numbers useful for tracking issues as they become fixed.

What's in this BSP?

This BSP contains:

  • Binary components
  • Source code
  • Documentation.

Note: The source code requires a BSP Source License.

Binary components

  • Startup
  • PCI server
  • Serial driver
  • Network driver (included with OS).

Source code

  • Startup
  • PCI server
  • Serial driver
  • Network driver.

Documentation

  • Intel IXDP2800 BSP readme (HTML)

Note:

Each BSP guide contains board-specific information and instructions on building an OS image for that particular board.

The procedure for building BSPs has changed since QNX Momentics 6.2.1. For instance, you must now run the . ./setenv.sh script before compiling your BSP source. If you fail to run this shell script prior to building the BSP, you can overwrite existing binaries or libs that are installed in $QNX_TARGET. For details, see the chapter "Working with a BSP" in the Building Embedded Systems manual (in the Documentation Roadmap page under the QNX Neutrino RTOS section).


Location of source and documentation

When you install BSPs, you'll find the source code and documentation in the following locations:

Windows hosts

Component Location
Source code $QNX_TARGET\usr\src\archives\qnx\
Documentation $QNX_TARGET\usr\help\product\bsp_index.html
Release notes $QNX_TARGET\etc\readme\bsp

QNX Neutrino, Linux, and Solaris hosts

Component Location
Source code $QNX_TARGET/usr/src/archives/qnx/
Documentation $QNX_TARGET/usr/help/product/bsp_index.html
Release notes $QNX_TARGET/etc/readme/bsp

Note:
  • To extract the source from the archive, use any application that supports the ZIP format (e.g. WinZIP). For more information, see the chapter "Working with a BSP" in the Building Embedded Systems manual.
  • The "roadmap" page (e.g. from the Windows XP start menu: Release notes-->All Programs-->QNX Momentics 6.3.0-->Documentation) contains links to the various HTML booksets that accompany the OS: System Architecture, Building Embedded Systems, Programmer's Guide, Library Reference, Utilities Reference, etc.

Binaries, buildfiles, IPLs, and other files

Depending on the particular BSP and type of driver, you'll find the files in these locations:

File Location
Buildfile $QNX_TARGET\cpu\boot\build
IPL and/or startup $QNX_TARGET\cpu\boot\sys
"sbin" drivers (serial, flash, block, PCI, PCMCIA, USB) $QNX_TARGET\cpu\sbin
"dll" drivers (audio, graphics, network) $QNX_TARGET\cpu\lib\dll

Linux hosts

File Location
Buildfile $QNX_TARGET/cpu/boot/build
IPL and/or startup $QNX_TARGET/cpu/boot/sys
"bin" drivers (serial, flash, block, PCI, PCMCIA, USB) $QNX_TARGET/cpu/bin
"dll" drivers (audio, graphics, network) $QNX_TARGET/cpu/lib/dll

Known issues for this BSP


Note: Please check the version of these release notes on the website for the most up-to-date information.

  • The ROM Monitor assigns special meaning to files that end with .bin. It seems to ignore the address specified on the command line, so the image isn't bootable. To work around this problem, the boot image file generated by this BSP ends in -bin, instead of the usual .bin.
  • The Egress and Ingress processors must both be up and running QNX Neutrino before you start the PCI server on one processor. Otherwise, the ROM monitor will lock up on the other one.
  • When connecting the network driver to a switch, make sure to let the driver autonegotiate the speed and duplex. If forced, the driver might not work with the switch; it works with a hub. (Ref# 21982)
  • The following warning is generated when you compile the PCI server:
     
    hardware/pci/ixp2400/ixp2400.c: In function `ixp2400_read_cnfg':
    hardware/pci/ixp2400/ixp2400.c:365: warning: variable `addrp' might be clobbered by `longjmp' or `vfork'
      

    The warning is benign, since the signal handler that could cause the problem isn't installed. (Ref# 22215)

  • If you install the source code for a BSP on a Windows platform (Windows 2000 or XP), and you don't install it on the C drive, then the BSP will fail to build using the command-line instructions given in the Working with a BSP chapter of Building Embedded Systems. The tools can't find the ixdp2800.build file. (Ref# 21924)

    If you install the BSP on the C drive, building the BSP from the command line succeeds. Building a BSP in the IDE works no matter where you install the BSP.

    Workaround: Do one of the following:

    • Before building the BSP, do the following:
      1. Start a bash shell.
      2. Go to the directory that holds the BSP source ($QNX_TARGET/usr/src/archives/qnx/BSP_name)
      3. Enter the following command:
        cp install\armbe\boot\build\ixdp2800.build images\ixdp2800.build
            

        This command copies the ixdp2800.build file into the correct directory, and lets you build the BSP, as described in the documentation.

    • Enter the following commands to build the BSP image:
      cd images
      make
            
  • When you import this BSP into the IDE, the ixp2400.be variant is renamed by the IDE to o.be. This causes the IDE to only build devc-ser8250 instead of devc-ser8250-ixdp2400. The buildfile will not build because it looks for devc-ser8250-ixdp2400. This issue doesn't occur when you build the BSP from the command line.

    Workaround: Once you've imported the BSP into the IDE, click on the C/C++ Projects tab to display the list of drivers. Expand the bsp-intel-ixdpxxxx_devc-ser8250 serial driver by clicking on the + sign. Then, expand "ser8250", then "arm". Rename the o.be variant to ixp2400.be by right-clicking on it and selecting "Rename". Rebuild the entire project to compile devc-ser8250-ixdp2400 and to rebuild the OS image.

  • In Microsoft Windows, certain programs (e.g. Norton Ghost) add directories inside double quotation marks (e.g. ...;"c:\Program Files\Norton Ghost\";...) to your PATH environment variable. This causes the Cygwin spawn() function to fail, which in turn causes cp to fail when called by ln-w. (Ref# 20046)

    Workaround: Modify your PATH environment variable and remove any quotation marks.

  • To build the BSP from the command line, you need to extract the source code from the zip file. In Microsoft Windows, make sure you place the source code in a directory that doesn't contain any spaces in its name.

  • In those instances where the the ROM monitor's MAC address is different from the one you pass in when running io-net, the host can cache the ROM monitor's address. This can result in a loss of connectivity.

    Workaround: If you need to specify a MAC address to io-net, we recommend that you use the same MAC address that the ROM monitor uses. This will ensure that if the host caches the ROM monitor's MAC address, you'll still be able to communicate with the target. Otherwise you might need to delete the target's arp entry on your host.

  • The TCP/IP stack obtains a timer from the process manager. This timer starts at 0. If the TCP/IP stack and a TCP/IP application that tries to connect to a remote host start executing too soon, the TCP/IP stack may apply a time of 0 seconds to ARP cache entry structures. If this occurs, you may end up with a permanent ARP entry (i.e. one that never times out). You can also end up with permanent, incomplete ARP entries that never time out, and that the TCP/IP stack doesn't attempt to resolve. If this happens, your host won't be able to communicate with one or (possibly) more remote hosts (i.e. the ones the TCP/IP application in the OS image is trying to reach).

    You can check for permanent ARP entries by running the arp -an command and examining the output. The only permanent entries listed should be for the IP addresses assigned to your host's interfaces; there shouldn't be any permanent, incomplete entries. If you find a permanent entry that isn't for the IP address of an interface on your host, and you didn't explicitly create a permanent entry, then you could be encountering this problem. (Ref# 21395)

    Workaround: In the buildfile for your OS image, delay the start of the TCP/IP stack or the first TCP/IP application by at least one second, by using the sleep command (e.g. sleep 1) or some other delay mechanism.

  • When you install several BSPs that share common files, you'll be prompted to overwrite the existing files. We recommend that you backup the existing files before you overwrite them. Uninstalling any BSP that shares that file will currently remove the common file. You'll need to restore the backup after you uninstall any BSP that shared the file(s). (Ref# 22922)

Note: Please check the version of these release notes on the website for the most up-to-date information.

Technical support

If you have any questions, comments, or problems with a QNX product, please contact Technical Support. For more information, see the How to Get Help chapter of the Welcome to QNX Momentics guide or visit our website, www.qnx.com.