QNX® Momentics® 6.3.0 Freescale MPC85x0 ADS BSP 1.0.2 Release Notes

Date of this edition: July 04, 2008

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: Freescale MPC8560ADS (CPU rev 2); Freescale MPC8540ADS (CPU rev 2)

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

What's in this BSP?

This BSP contains:

• Binary components
• Source code
• Documentation.

Binary components

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

Source code

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

Documentation

• Freescale MPC85x0 ADS Board Support Package readme (HTML)

Location of source and documentation

When you install BSPs, you'll find the source code in $QNX_TARGET\usr\src\archives\qnx\ on Windows, and in $QNX_TARGET/usr/src/archives/qnx/ on QNX Neutrino and Linux.

You can read the documentation (including release notes) in the Integrated Development Environment's help system on all host OSs; on self-hosted QNX Neutrino systems, you can also read it in the Photon helpviewer, or you can use a web browser to display:

${QNX_TARGET}/usr/help/product/momentics/bookset.html

This “roadmap” page contains links to the various HTML booksets that accompany the OS (e.g. System Architecture, QNX Neutrino 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

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

QNX Neutrino, Linux, and Solaris 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/sbin
“dll” drivers (audio, graphics, network)	$QNX_TARGET/cpu/lib/dll

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 board no longer hangs due to high network activity. (Ref# 22409)
• The network driver (devn-mpc85xx.so) can now receive multicast packets, so you can use IPv6. (Ref# 22343)

Known issues for this BSP

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

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

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

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.