QNX Technical Articles

QNX^® Momentics^® 6.3.0

Motorola MGT5200 BSP

Release Notes

Date of this edition: June 07, 2004

Target OS: QNX^® Neutrino^® 6.3.0

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

Boards supported: Lite5200 EVB Rev2 and Total5200 SDP Rev1 and Rev2

Contents

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

What's in this BSP?

This BSP contains:

• Binary components
• Source code
• Documentation.

Binary components

• IPL
• Startup
• PCI server
• Serial driver
• Network driver
• Bestcomm DMA library
• Bestcomm utility
• USB support
• EIDE driver
• Audio driver (Total5200 only)
• Graphics driver (Total5200 only)
• SPI driver (Total5200 only)
• I2C driver (Total5200 only)
• Touchscreen (Total5200 only).

Source code

• IPL
• Startup
• PCI server
• Serial driver
• Network driver
• Audio driver (Total5200 only)
• Graphics driver (Total5200 only)
• SPI driver (Total5200 only)
• I2C driver (Total5200 only)
• Touchscreen (Total5200 only).

Documentation

• Motorola MGT5200 BSP readme (HTML)

Location of source and documentation

When you install BSPs, you'll find the source code and documentation in the following locations:

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 for this BSP

• If a FIFO error occurs while the audio driver is running (logged by slogger), the driver may need to be restarted to restore correct operation. See the section "Audio concerns" below for details.
• During audio playback and or capture, configuration changes such as volume changes may not take effect. See the section "Audio concerns" below for details.
• The MGT5200 default buildfile has the PCI server commented-out, but tries to run it in the .script section. Uncomment the PCI server in the buildfile (below the [data=c]).
• The MGT5200 default buildfile has the correct io-usb arguments (i.e. io-usb -dohci-mgt5200 ioport=0xf0001000,irq=70). The documentation has incorrect io-usb arguments. (Ref# 19846)
• Only the top USB port works on the Total5200 board.
• The flash driver for the Total5200 revision 1 supports only 32MB of flash. The flash driver for the Total5200 revision 2 supports 64 MB of flash. In order to start the flash driver for the revision 2, use the following command-line arguments:

  devf-mgt5200 -s0xfc000000,64M
    

• Graphics-intensive applications can starve out the audio DMA channel. (Ref# 20872)

  To fix this, change the priority of the bus arbitrator in the startup code; edit hardware/startup/boards/mgt5200/mgt5200_clock_freqs.c and go to line 103. Change:

  xlb_arb->priority &= 0xffff0f0f;
    

  to:

  xlb_arb->priority = 11111010;
    

  You'll have to rebuild the startup code and the OS image after you've made this change.

• Although this isn't currently documented, the eight 8250-compatible UARTs are supported. However, on the Total 5200 board (rev 1 only), the ports must be accessed via 32-bit reads and writes. Therefore, you'll need to generate a version of devc-ser8250 that uses 32-bit accesses. To do this, you'll need to use the Character DDK.

  ---

  NOTE:

  Rev 2 of the Total 5200 board doesn't have this problem.

  ---

  1. Go to the source directory for devc-ser8250:

     cd $PATH/ddk-6.3.0/char/src/hardware/devc/ser8250/ppc/

  2. Add the mgt.be variant to the source tree:

     addvariant mgt.be

  3. In the mgt.be directory, create and save the following variant.h file:

     #ifndef write_8250
     #define write_8250(__port,__val)    out32(__port,__val)
     #endif
     
     #ifndef read_8250
     #define read_8250(__port)   in32(__port)
     #endif

  4. Now make this driver, and include it in your build image.

  To start the driver, use the appropriate command-line arguments:

  For this port:	Use this command:
  0	devc-ser8250-mgt -e -b115200 -c7372800 0x30000000^2,0
  1	devc-ser8250-mgt -e -b115200 -c7372800 0x30000020^2,0
  2	devc-ser8250-mgt -e -b115200 -c7372800 0x30000040^2,0
  3	devc-ser8250-mgt -e -b115200 -c7372800 0x30000060^2,0
  4	devc-ser8250-mgt -e -b115200 -c7372800 0x30000080^2,6
  5	devc-ser8250-mgt -e -b115200 -c7372800 0x300000a0^2,6
  6	devc-ser8250-mgt -e -b115200 -c7372800 0x300000c0^2,6
  7	devc-ser8250-mgt -e -b115200 -c7372800 0x300000e0^2,6

  ---

  NOTE:

  UARTs 0 through 3 share IRQ 0; ports 4 through 7 share IRQ 6.

  ---

io-audio -d mpc5200 &

Audio concerns

The MPC5200 has six Programmable Serial Controllers (PSCs) that can be used to stream audio data into and out of the MPC5200. Two of the PSCs have an operating mode designed to connect to AC'97 codecs. However, the AC'97 mode on the MPC5200 lacks a full implementation of an AC'97 physical interface. It does not include circuitry for managing the register interfaces on AC'97 codecs. Thus, software routines must be used to program the AC'97 registers. As a result, there are a few timing concerns that must be taken into account when working with an AC'97 codec.

Before explaining these concerns, it's necessary to describe the basic workings of the AC'97 audio system. The system consists of two primary components:

• the codec -- responsible for all analog signal control and for the analog-to-digital conversion (ADC) as well as the digital-to-analog conversion (DAC).
• the digital controller -- responsible for transferring the digital PCM streams to the codec and for changing codec internal registers that control the codec operation.

The two components communicate via a bi-directional five-wire serial TDM interface. The data flowing across this link is formatted as input and output frames that are transferred at the rate of 48000 frames per second. A simplified format of these frames is shown in the following tables:

PSC output (serial data out)

CODEC output (serial data in)

In this simplified view, the codec provides the data and frame synchronization clock for the communication; the controller must detect the start of frame signal so that it can begin sending its output frame and begin decoding the input frame at the correct time. The "Cmd" slots hold codec commands for reading and writing codec controls, the "Status" slots hold the results for the last command received, and the PCM slots hold the PCM data for the audio streams. The Tag slots are used to signal the validity of the other slots and for support of the Sample rate conversion in the codec. To achieve sample rates different from the frame rate (48 KHz), the codec uses the tag bits to control the data transfer.

The MPC5200 implements the AC'97 controller using a Programmable Serial Controller (PSC), but the limited functionality of the PSC can cause several issues for the device driver.

1. The first issue is that random "Cmd" data can be sent to the codec. This condition occurs if the DMA engine does not fill the PSC Transmit FIFO quickly enough. This situation causes the PSC to loose frame synchronization with the codec, so when the FIFO is later filled that data will be sent in any slot of the frame. This means that the PCM data can be sent in the "Cmd" slots. Since the PCM data can be any value, the effects on the codec are not defined.
2. The second issue is also caused by the PSC limited functionality: the PSC does not understand the AC'97 frame but simply transmits and receives data. This means it's not possible to use the sample rate converters in the codec. This feature of AC'97 is called Variable Rate Audio (VRA) and requires that the controller support "on demand" slot request bits -- in short the codec sets a slot request bit whenever it needs data. As an example, for a playback rate of 44100 Hz, the codec would set the slot requests bits in 441 of 480 frames transferred. Since the PSC does not interpret the request bits, this feature is not usable. The situation then requires the audio architecture or the application to perform rate conversion in software. This conversion requires CPU power to perform; the better the quality of the conversion, the more CPU power is required.
3. The last issue is getting codec commands such as volume changes to occur in a timely manner. To accomplish this, the audio driver must inject these commands into the PSC data stream such that the commands are transferred to the codec in the earliest possible frame. To do this, the driver needs to know where in a DMA buffer the DMA engine is accurately. There are issues with the current Bestcomm DMA implementation that may prevent this technique from working consistently.

All audio applications using the MPC5200 driver should be designed carefully to work around these issues.

Technical support

If you have any questions, comments, or problems with a QNX product, we recommend that you use our support forums available from our news server, news://inn.qnx.com.

Since QNX developers and support staff frequent our newsgroups, you should find them to be your best avenue of support for solving problems.