QNX Technical Articles
QNX® Momentics® 6.3.0 Renesas Biscayne BSP 1.0.1 Release Notes
Date of this edition: December 22, 2004
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)
|
Contents
- What's in this BSP?
- 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
- Startup
- Serial driver (SCI and HSPI)
- PCMCIA server
- I2C driver
- Camelot utility
- Camelot DMA library
- AC97 audio driver
- I2S audio driver
- USB support
- NAND driver
- Graphics driver
- Network driver (included with OS).
Source code
- IPL
- Startup
- Serial driver (SCI and HSPI)
- I2C driver
- Camelot utility
- AC97 audio driver
- I2S audio driver
- Graphics driver
- Network driver
- Flash driver.
The flash filesystem driver library is included in the separately available Flash Filesystem & Embedding Technology Development Kit (TDK). |
Documentation
- Renesas Biscayne 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
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 |
"bin" drivers (serial, flash, block, PCMCIA, USB) | $QNX_TARGET\cpu\bin |
"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, PCMCIA, USB) | $QNX_TARGET/cpu/bin |
"dll" drivers (audio, graphics, network) | $QNX_TARGET/cpu/lib/dll |
Fixed issues
- devn-smc9000.so
- We fixed an alignment problem in devn-smc9000.so that could have caused io-net to crash with a SIGBUS error. (Ref# 19170)
- procnto
- The data cache on SHLE is now properly invalidated on requests for PROT_NOCACHE memory. This means that USB will work correctly with this BSP. (Ref# 19459)
- Documentation
- The instructions for creating a flash filesystem partitions have been corrected. (Ref# 19035)
Known issues for this BSP
- As documented by Renesas, there are bandwidth restrictions on the LCD controller. It supports 16 x 1 to 1024 x 1024 dots (8 bpp: a maximum of 640 x 480 dots, 16 bpp: a maximum of 320 x 240 dots). If you try to run at 640 x 480 x 16 on the Renesas Biscayne board, you'll get display corruption and flicker.
- If windows aren't properly displayed under Photon, make sure that phfont is running.
- 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.
- Simply uncommenting the io-graphics line in the buildfile
isn't enough to run Photon on the target; this line shows how to run the
graphics driver only.
For more information on embedding Photon on your board, see the Photon in Embedded
Systems appendix of the Photon Programmer's Guide.
To test or evaluate Photon on your target before embedding it you could make the Photon environment accessible to the target by simply mounting your host environment into the target. You'll need to use an NFS or CIFS client on the target depending on the type of server running on your host platform. This example shows how to create a basic Photon configuration using an NFS client.
- Uncomment the following sections from the build file:
network, usb and graphics
- Add the following at the end of the network section:
fs-nfs3 10.0.0.1:$QNX_TARGET/cpu/ / 10.0.0.1:$QNX_TARGET/etc /etc 10.0.0.1:$QNX_TARGET/usr/photon /usr/photon & waitfor /usr/bin waitfor /usr/photon waitfor /etc Where 10.0.0.1 is the server IP address
The first three lines of the fs-nfs command comprise one command.
- You can now run the Photon drivers.
To run the graphics driver:
/usr/photon/bin/Photon & waitfor /dev/photon /usr/photon/bin/io-graphics -d...
(See the "Devices supported" chapter in the BSP documentation for details on the graphics driver options).To use a usb mouse and keyboard:
/sbin/io-hid -dusb /usr/photon/bin/devi-hid kbd mouse &
- Uncomment the following sections from the build file:
- 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.
Please check the version of these release notes posted 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.