QNX Technical Articles

Date of this edition: January 21, 2005

Target OS: QNX^® Neutrino^® 6.3.0

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

Boards supported: Freescale MPC8560ADS (CPU rev 2); Freescale MPC8540ADS (CPU rev 2)

You need to use ROM Monitor version UBoot v 1.1.2 with these boards.

You need to have installed QNX Momentics 6.3.0 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.

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

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

Source code

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

The flash filesystem driver binary and the flash filesystem library are included in the separately available Flash Filesystem & Embedding Technology Development Kit (TDK).

Documentation

• Freescale MPC85x0 ADS Board Support Package readme (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

Fixed issues

• Message interrupts work properly with the correct number of vectors and priorities. (Ref# 20790)
• The network driver runs normally during packet-forwarding RFC2544 benchmarks. (Ref# 19566)
• The network driver no longer has auto-negotiation problems with a 100BaseT switch. (Ref# 19567)
• The network driver (devn-mpc85xx.so) can now receive multicast packets, so you can use IPv6. (Ref# 22343)
• The BSP documentation gives instructions for changing the clock frequencies. (Ref# 22603)
• The example in the docs for starting the 8250 serial driver no longer has the wrong clock value. (Ref# 22580)

Known issues for this BSP

• The board might hang due to high network activity because of a defect on the MPC8560 CPU. For more information, see CPU29 in MPC8560 PowerQUICC III Device Errata, available from Freescale's website. (Ref# 22409)

  Workaround: Download an updated experimental version of procnto from where you downloaded this BSP from our website.

• Unmount doesn't return when trying to unmount /dev/io-net/en0 (Ref# 22139)

  Workaround: Slay and restart io-net to unmount the driver.

• Unplugging the network cable results in an "Unknown" media speed on reinsertion. The driver is still fully functional in this state. (Ref# 21992)
• 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 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.

• Some PCI cards may not operate at a PCI frequency of 66MHz.

  Workaround: Configure the PCI frequency to be 33MHz instead. See the BSP documentation for details.

• The OS image generated for a TFTP download should be a raw format. When you create the image, it will appear with an .srec extension on it. In the documentation the TFTP image name is correct and appears with a .raw extension. This is just a naming convention issue; it doesn't affect the format of the image which is actually a raw format as opposed to an SREC format. If you wish to change the file to the proper extension, you may do so in the Makefile located in the images directory.

• Some Rev-Pilot boards have problems running Ethernet at half-duplex mode. The second Ethernet port may not work either. (Ref# 23333)

  The Rev-A boards do not exhibit these problems.

  Workaround: Run the Ethernet driver in full-duplex mode on the first Ethernet port.

• When a "break" is detected by the hardware, the Line Status interrupt is asserted. This interrupt is cleared by reading the line status register (which also gives you the cause of the interrupt).

  From the documentation for the line status register (Section 12.13.9 of the 8540 User Manual):

  "Note that the ULSR[BI] is set immediately after ULSR is read if bus remains zero and no mark state followed by a valid new character has been detected."

  In other words, as long as there's no input to the board after a break, the LS interrupt constantly gets cleared and reasserted resulting in the out-of-interrupt events being generated.

  Workarounds: There are a few workarounds:

  1. Ensure that no breaks are delivered to the target (if one is sent, sending a character to the target will clear the interrupt). See option 2. Note that a break can be also generated to the target (under the conditions of having mis-matched baud rates between the target and host).
  2. Always ensure that at least one character is sent to the target immediately following the delivery of a break.
  3. Disable the line status interrupt:

     In the source file init.c, change line 84:

           write_8250(port[REG_IE], 0x0f);
           

     to

           write_8250(port[REG_IE], 0x0b);
           

  This results in an unfortunate side effect: breaks, framing errors, parity errors, overrun errors, data ready interrupts Rx FIFO errors, Tx empty, Tx holding register empty will not generate Line Status interrupts.

  However, the LSR is also read with every character received, so processing of line status changes will not be completely disabled, just delayed until a character is received.

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.