QNX Technical Articles
QNX® Momentics® 6.3.0 Xilinx Virtex4 ML403 BSP 1.0.0 Release Notes
Date of this edition: September 08, 2006
Target OS: QNX® Neutrino® 6.3.0 SP1 or later
Host OS: Microsoft Windows XP SP1 or SP2; Microsoft Windows 2000 SP4
Boards supported: Xilinx Virtex-4 ML403
|
Contents
- What's in this BSP?
- Location of source and documentation
- 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
- Serial driver
- Ethernet driver
- Input driver
- Graphics driver
Source code
- Startup
- Serial driver
- Ethernet driver
- Input driver
- Graphics driver
Documentation
- Xilinx Virtex-4 ML403 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. 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 |
|
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 |
"sbin" drivers (serial, flash, block, PCI, PCMCIA, USB) | $QNX_TARGET/cpu/sbin |
"dll" drivers (audio, graphics, network) | $QNX_TARGET/cpu/lib/dll |
Known issues for this BSP
Please check the version of these release notes on the website for the most up-to-date information. |
- The QNX Momentics Integrated Development Environment (IDE) does not currently support this BSP.
Workaround: This BSP needs to be compiled from the command line.
- The Ethernet driver only support 10 / 100Mbit for now.
- PS2 internet Microsoft keyboards (i.e. keyboard with extra web enabled keys) will not
work with this BSP.
Workaround: Use any other type of keyboard or standard Microsoft keyboards.
- With the Xilinx design provided with this BSP the PS/2 Keyboard and PS/2 Mouse are swapped.
Workaround: Connect the PS/2 Mouse into the PS/2 Keyboard connector on the board and connect the PS/2 Keyboard into the PS/2 Mouse connector on the board.
- With the default options in the build file the devi-ml300 driver will run READY if either the mouse or
keyboard is not attached to the board. This will result in the driver not working for the attached device.
Workaround: Have both the mouse and keyboard attached their respective PS2 port. Alternatively you can modify the driver options to only initalize the attached devices. i.e. For the mouse only devi-ml300 ps2 mousedev or for keyboard only devi-ml300 kbd kbddev.
- Due to the small buffer size (i.e. 2KB) of the Ethernet implemention, you might experience performance issues when
running FTP or NFS on the ML403 board.
Workaround:
If you run the QNX FTP client, use the sndbuf and rcvbuf commands to set the transmit and receive buffers to 512.
If you run the QNX NFS client and server, use the -t option for both. - If you're using an evaluation copy of the Xilinx tools, the board will hang after running QNX for 9 hours and 9 minutes.
Workaround: Contact Xilinx for an commercial license of the Xilinx EDK/ISE tools.
- 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.
- Some warnings may be displayed when compiling this BSP with one or both supported compilers. These warnings are benign and do not affect the functionality of the resulting binaries.
- 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.
- If you specify the -d and -p options for io-graphics, you must put the -d option before the -p, or else io-graphics fails. (Ref# 22670)
- 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)
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.