QNX Technical Articles

Date of this edition: January 14, 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)

You need to have installed the QNX Momentics 6.3.0 SP1 before installing this BSP. For information on installing this BSP, see the installation note. If you install SP1, you should also install the latest version of the QNX Momentics Character Driver Development Kit (DDK), if you installed an earlier version of it. Significant changes have been made to this DDK; please see the Character DDK Release Notes. SMP support for this BSP is available in the separately available Symmetric Multiprocessing Technology Development Kit (TDK). 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.

Contents

• What's in this BSP?
  • Binary components
  • Source code
  • Documentation
• Location of source and documentation
• Fixed issues
• Known issues for this BSP
• Technical support

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.

The source code requires a BSP Source License.

Binary components

• IPL (example only)
• Startup
• Serial driver
• Network driver
• PCI (BCM91250A only)
• PC Card (BCM91250A only)
• USB support (BCM91250A only).

Source code

• IPL (example only)
• Startup
• Flash driver
• Serial driver
• Network driver
• PCI Server.

The flash filesystem library is included in the separately available Flash Filesystem & Embedding TDK.

Documentation

• Broadcom BCM91250 / BCM91125 BSP guide (HTML)

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

QNX Neutrino, Linux, and Solaris hosts

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:

Windows hosts

QNX Neutrino, Linux, and Solaris hosts

Known issues

• The 64-bit PCI slots don't function properly. (Ref# 10942)
• The network driver lacks multicast support. (Ref# 21749)
• There are auto-negotiation issues with the network driver. (Ref# 22063, 22067, 22068)
• A memory leak occurs when the network driver is unmounted. (Ref# 22070)
• The new priority=xx option for io-net may cause starvation of other io-net threads and should not be used. (Ref# 21999)
• 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.

• In those instances where 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 IDE can't build images for a BSP containing buildfiles for both little endian and big endian. (Ref# 20942)
• When selecting odd and even parity for the serial driver, you may experience corrupt data. (Ref# 21993)

  Workaround: Select parity "none" for the serial driver.

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

• There is an issue in the buildfile with how io-net starts the two driver interfaces. Here is the correct way to start them:

  display_msg Starting io-net with large stack 
  io-net -c1 -ptcpip cache=1
  
  display_msg Starting first on-board ethernet driver
  mount -Tio-net -o"ioport=0x10064000,irq=0x80050013,mac=001155332244" devn-bcm1250.so
  waitfor /dev/io-net/en0 10
  ifconfig en0 1.2.3.4
  
  display_msg Starting second on-board ethernet driver
  mount -Tio-net -o"ioport=0x10065000,irq=0x80050014,mac=001122334456" devn-bcm1250.so
  waitfor /dev/io-net/en1 10
  ifconfig en1 1.2.3.5

• In order to maximize performance throughput when there's a steady stream of received packets, the PHY doesn't get probed on a consistent basis. This could result in the network driver setting the wrong speed/duplex. (Ref# 21798)

  Workaround: For proper autonegotiation, use the new network driver option probe_phy=1 to allow for correct tracking of cable changes.

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.