QNX Technical Articles
Getting Started with theTI Jacinto BSP
© 2008, QNX Software Systems GmbH & Co. KG. All rights reserved.
Contents
- Running QNX Neutrino on the TI Jacinto EVM
- System requirements
- Step 1: Connect your hardware
- Step 2: Build the BSP
- Step 3: Transfer the OS image to the target
- Step 4: Start working with Neutrino OS
- System Layout
- Summary of driver commands
- About graphics
- Creating a flash partition
- Where do I go from here?
- BSP filename conventions
Running QNX Neutrino on the TI Jacinto EVM
Before you begin
For information about the hardware or firmware, refer to the documentation for your board. You may also find the following website useful:
We assume that you're already familiar with the following docs:
Title | Chapter |
---|---|
Building Embedded Systems | Making an OS image; for customizing the BSP from the command line |
Building Embedded Systems | Working with a BSP; for building the BSP |
IDE User's Guide | Building OS and Flash Images; for customizing the BSP within the IDE |
What's in this BSP?
See the latest release notes for details on what is included in this BSP.
Devices supported
Neutrino supports the following devices on the TI Jacinto EVM:
- Ethernet controller
- Graphics controller
- Serial: 16550 UART
- Flash: 64 MB AMD Flash
- NAND Flash
- Block: ATA Interface
- SD: SD Memory Card Interface
- USB: Jacinto USB Interface
- Audio:McASP Interface of the TMS320DRA44x
- CAN Bus
- I2C: DM6446 I2C Manager
- SPI: DRA446 SPI Controller
![]() |
|
System requirements
Target system
- TI Jacinto EVM: CPU board and a main board
- 64 MB NOR flash
- appropriate power supply and cable
Host development system
- System requirements: see the release notes
- Terminal emulation program (e.g. HyperTerminal, qtalk, Momentics IDE Terminal, etc.)
- RS-232 serial port
- Null-modem serial cable
- Ethernet link
![]() |
For other system requirements (e.g. disk, RAM), see the installation notes for QNX Momentics. |
Step 1: Connect your hardware
- Connect the null-modem serial cable to the serial port of the
Jacinto and the serial port of your host machine.
If you have a Neutrino host with a serial mouse, you may have to move it to the second serial port on your host, because some terminal programs require the first serial port. - Connect an RJ-45 ethernet cable between the ethernet port on the Jacinto EVM and your local network.
- Connect the power supply cable on your board.
Step 2: Build the BSP
You can build a BSP OS image from the source code contained in the BSP package.
For instructions about building a BSP OS image, please refer to the chapter Working with a BSP in the Building Embedded Systems manual.
Step 3: Transfer the OS image to the target
Boot OS images by ROM monitor
![]() |
Make sure the host machine is capable of handling TFTP requests (see inetd documentation for details). |
- On your host machine, start your favorite terminal program with these settings:
- Baud: 115200
- Bits: 8
- Stop bits: 1
- Parity: none
- Start your target. You should see output similar to the following:
U-Boot 1.1.3 (Jan 22 2007 - 16:13:39) U-Boot code: 62080000 -> 620977D0 BSS: -> 6209C4C8 RAM Configuration: Bank #0: 60000000 128 MB ******************** DRI version 0.05 ******************* qjwang@ti.com ARM Clock :- 324MHz SDRAM Clock :- 110MHz SPANSION NOR Flash: 64 MB In: serial Out: serial Err: serial Hit any key to stop autoboot: 3
- Press any key to stop autobooting, and then you'll see the Jacinto prompt:
Jacinto #
- At the Jacinto # prompt, issue the following command to show the current environment:
Jacinto # printenv
- You can change the current settings using the setenv command to configure the following
parameters:
Jacinto # setenv netmask 255.255.240.0 Jacinto # setenv ipaddr 10.42.101.242 Jacinto # setenv gatewayip 10.42.96.1 Jacinto # setenv serverip 10.42.98.211 Jacinto # setenv 'bootcmd tftpboot 40010000;go 40010000'
- Once you've configured these parameters, use the saveenv
command to store your changes:
Jacinto # saveenv
- Restart your target. You should see output similar to the following:
Using MAC Address 00:0E:99:02:61:53 TFTP from server 10.42.98.211; our IP address is 10.42.101.242 Filename 'ifs-jacinto.raw'. Load address: 0x40010000 Loading: T T T T T T T ################################################################# ########################################################## done Bytes transferred = 627276 (9924c hex) ## Starting application at 0x40010000 ... Dcache: 512x32 WB Icache: 512x32 arm926 rev 5 324MHz System page at phys:40166000 user:fc404000 kern:fc404000 Starting next program at vfe0203a4 Welcome to QNX Neutrino 6.x on a TI Jacinto EVM #
Boot OS images by IPL
![]() |
Before burning the IPL, you might want to save the first 1 MB of flash in order to save the ROM monitor. |
- Run mkflashimage in the BSP's images directory
to create a combined IPL/OS image to use when burning the flash.
# ./mkflashimage
You need to change the default image filename to ifs-jacinto.bin, and you can ignore the warning message “Warning: Output file cannot represent architecture UNKNOWN!” - Download the ipl-ifs-jacinto.bin image to your target board, /dev/shmem/ipl-ifs-jacinto.bin.
- Make sure the target can read the image you want to copy, and then
execute the following commands in the Neutrino shell to burn the IPL-IFS
images to flash:
# devf-generic -s0x20000000,64M # flashctl -p/dev/fs0 -l6M -ve # cp -V /dev/shmem/ipl-ifs-jacinto.bin /dev/fs0
- Reboot the target; the IPL should come up.
Either press s to transfer the OS image
serially using sendnto, or if
you generated ipl-ifs-jacinto.bin and copied it to
/dev/fs0, press f to scan the
flash for an os image.
When booting serially, images larger than 6 MB won't load unless you first modify the IPL source.
Step 4: Start working with Neutrino OS
You can test the OS simply by executing any shell builtin command or any command residing within the OS image (e.g. ls).
Once the initial image is running, you can update the OS image using the network and flash drivers. For sample command lines, please see the “Summary of driver commands” section.
System Layout
The table below depicts the memory layout for the image and for the flash.
Item | Address |
---|---|
OS image loaded at: | 0x40010000 |
Flash base address | 0x20000000 |
Summary of driver commands
The driver command lines below are specific to the TI Jacinto EVM board. See the online docs for each driver for additional command-line options and other details.
![]() |
Some of the following drivers are commented out in the default buildfile. To use the drivers in the target hardware, you'll need to uncomment them in your buildfile, rebuild the image, and load the image into the board. |
Startup:
- Command:
- startup-jacinto -L 0x67800000,0x800000 -vvvvv
Serial:
- Command:
- devc-ser8250 -e -F -S -b 115200 -c24000000/16 0x01c20000^2,43
Required binaries:
- devc-ser8250
Flash(NOR):
- Command:
- devf-generic -s0x20000000,64M
Required binaries:
- devf-generic
- flashctl
SPI:
- Command:
- spi-master -d dra446 base=0x01c24c00,irq=37,edmairq=0xc128,edmachannel=40
Required binaries:
- spi-master
Required libraries:
- spi-dm644x.so
I2C:
- Command:
- i2c-dm6446 -p0x01C21000 -i39 --u0
- i2c-dm6446 -p0x01C21000 -i39 --u1
Required binaries:
- i2c-dm6446
USB:
- Command:
- io-usb -d jacinto ioport=0x01c42000,irq=2
Required binaries:
- io-usb
- usb
Required libraries:
- devu-jacinto.so
- libusbdi.so
Ethernet:
- Command:
- io-net -dsmc9000-jacinto ioport=0x2a000000,irq=106,mac=xxxxxxxxxxxx -ptcpip
Required binaries:
- io-net
- ifconfig
Required libraries:
- devn-smc9000-jacinto.so
- libsocket.so
- npm-tcpip.so
Block and SD:
- Command:
- devb-eide-dm644x blk cache=12M
- devb-sd-jacinto blk cache=12M
Required binaries:
- devb-eide-dm644x
- devb-sd-jacinto
Required libraries:
- devb-eide-dm644x
- libcam.so
- cam-disk.so
- cam-cdrom.so
- io-blk.so
- fs-qnx4.so
- fs-dos.so
- fs-cd.so
Audio:
- Command:
- io-audio -d dra44x-jacinto
This driver must be started after the I2C driver is active.
Required binaries:
- io-audio
- mix_ctl
Required libraries:
- deva-ctrl-dra44x-jacinto.so
- libasound.so
Graphics:
- Command:
- io-display -dvid=0,did=0
Required binaries:
- io-display
Required libraries:
- devg-jacinto.so
- libGLES_CL.so.1
- libffb.so
- libgf.so.1
- The eVRU_Jacinto.out (version 2.03) DSP image must be running in order for the graphics driver to use hardware-accelerated rendering.
- You must build the DSP image with the same configuration as DSPLink on the ARM side. Make sure you're using the correct command-line options to startup. For testing of this BSP, we used an 8M DSP image with eVRU version 2.03 provided by TES.
- This BSP includes a sample jacinto.conf file. You may have to change the dspexe= option in the jacinto.conf file, depending on where the DSP image is located.
Required config files:
- display.conf
- jacinto.conf
![]() |
For more information about these commands, see the Neutrino Utilities Reference. |
About graphics
The graphics driver supports these display interfaces:
- VPSS (digital or analog)
- Internal Raster Controller
It's possible to do dual-display output using the VPSS analog output and the Internal Raster Controller. You can set this up in the jacinto.conf configuration file.
VPSS display interface
The driver supports the following analog outputs:
- NTSC 720x480 interlaced output (composite, svideo, component)
- PAL 720x576 interlaced output (composite, svideo, component)
You can use jacinto.conf to configure digital output. We tested the driver with the LG Philips LB080WV3 LCD.
The VPSS controller supports the following layers or “OSD windows”:
- Video Window 0, supporting YUV422 or RGB888 formats
- Video Window 1, supporting YUV422 or RGB888 formats
- OSD Window 0, supporting RGB565 format
- OSD Window 1, supporting RGB565 format
You can control the following features for all layers:
- window start position and size
- horizontal & vertical zoom (2X, 4X)
The OSD windows can support the follow features:
- alpha blending (16 levels)
- transparency (when a pixel matches the transparent color, the pixel will be transparent and the underlying video pixels will be displayed)
You can enable or configure OSD Rectangular Cursor support using jacinto.conf.
![]() |
The OSD window restrictions (from the TI documentation) include:
|
Raster controller
The Raster Controller has been validated with the Sharp LQ050Q5DR01 TFT LCD. The Raster controller supports a single layer and runs only at the RGB565 pixel format.
Optional graphics driver rendering acceleration
The graphics driver can run with SW rendering or can have accelerated 2D/3D rendering using a DSP image containing the TES eVRU graphics library.
Hardware-accelerated 2D rendering using the eVRU graphics library is supported for RGB565, RGB888, and ARGB8888 color formats. The 2D accelerated features are:
- filled rectangle
- filled rectangle with alpha map
- filled rectangle with global alpha
- blit (opaque)
- blit with alpha map
- blit with global alpha
- blit with alpha map and global value
- blit with per-pixel alpha (source surface must be ARGB8888 format)
- blit with per-pixel alpha and global value (source surface must ARGB8888 format)
- clip rectangle
- lines
- thick lines
- dashed line (backfilled only)
- anti-aliased lines
- filled polygon
- filled polygon (with anti-aliasing)
- scaled blit (opaque)
- scaled blit (with global alpha)
![]() |
The alpha map must be the same size as the fill/blit size. |
Hardware-accelerated 3D rendering using the eVRU graphics library is limited, and is disabled by default to allow OpenGLES conformance. To enable the accelerated 3D rendering, set the sw3d option in jacinto.conf to 0 (sw3d=0). When enabled, the following features are accelerated for RGB565 and RGB888:
- flat shaded triangle
- flat shaded triangle strip
- flat shaded triangle fan
- flat shaded line
- flat shaded line strip
- flat shaded line loop
- flat shaded point
- color buffer clearing
Optional graphics memory management
The Jacinto has two memory buses (EMIFA, EMIFB). We've found that for certain graphics operations, performance is improved if the source and destination surfaces are on separate EMIFs.
You can reserve memory from the system by using the -rBASE,SIZE option, where BASE is the physical base address of memory, and SIZE is the number of bytes to reserve.
To take advantage of this, you can specific two memory regions to devg-jacinto.so, using the following new options in jacinto.conf:
- abase
- The physical base address of the reserved memory pool. This must match the address specified to startup with the -r option.
- asize
- The size of the memory pool. This must match the size specified to startup with the -r option.
- bbase
- The physical base address of reserved memory pool. This must match the address specified to startup with the -r option.
- bsize
- The size of the memory pool. This must match the size specified to startup with the -r option.
The EMIFA base address is 0x40000000 and is 128 MB in size, and the EMIFB base address is 0x60000000 and is 128 MB in size.
In developing/testing this functionality, we used the following startup line:
startup-jacinto -r 0x60000000,0x200000 -r0x47E00000,0x200000 -L 0x67800000,0x800000 -vvvvv
The above line reserves 2 MB in EMIFA and 2 MB in EMIFB. The resulting entries in jacinto.conf are:
bbase=0x60000000,bsize=0x200000,abase=0x47e00000,asize=0x200000
The devg-jacinto.so driver creates two memory pools to allocate surfaces from while surfaces can be allocated.
By default, the driver attempts to allocate memory from POOL B (specified by bbase and bsize). If this allocation fails, the surface is allocated by the graphics framework from general system memory. It doesn't attempt to allocate the surface from the other pool.
You can select POOL A (specified by abase and asize) by passing in the GF_SURFACE_CREATE_CPU_FAST_ACCESS flag to gf_surface_create() or gf_surface_create_layer() as shown in the following examples:
if (gf_surface_create( &images[0], device, 100, 100, GF_FORMAT_BGR888, NULL, GF_SURFACE_CREATE_2D_ACCESSIBLE | GF_SURFACE_CREATE_CPU_FAST_ACCESS) != GF_ERR_OK) { return -1; } if (gf_surface_create_layer( &t_surface, &info->layer, 1, 0, info->width, info->height, info->layer_format, NULL, GF_SURFACE_CREATE_CPU_FAST_ACCESS) != GF_ERR_OK) { return 0; }
If this allocation fails, the surface is allocated by the graphics framework from general system memory. It doesn't attempt to allocate the surface from the other pool.
If you don't specify memory regions to that driver, all surfaces are created by the graphics framework in general memory (whether or not memory was reserved at startup).
AVME/devg coexistence
It's possible to have the TI AVME and QNX graphics coexist in the same system. To do this, the following must occur:
- The QNX graphics application must be started before AVME.
- In jacinto.conf, you must set the avme option to indicate which OSD windows of the VPBE will be managed by the devg driver, and which it will leave for AVME to manage.
For details on the avme options, see jacinto.conf.
Creating a flash partition
- Enter the following command to start the flash filesystem driver:
devf-generic -s0x20000000,64M
- Erase the flash, except for the first 6 MB:
Because the ROM monitor or IPL/OS image are in the first 6 megabyte of flash , you may not want to erase them. Use the -l (length) and -o (offset) options to avoid these areas. flashctl -p/dev/fs0 -o6M -l58M -ve
- Format the partition:
flashctl -p/dev/fs0p0 -o6M -l58M -vf
- Slay and then restart the driver to mount the new partition:
slay devf-generic devf-generic -s0x20000000,64M
You should now have a /fs0p0 and /fs0p1 directory automounted.
Where do I go from here?
For information on: | Go to: |
---|---|
Generating IPL, startup, and other modules from BSP source code | Building Embedded Systems, Working with a BSP |
Using mkifs to generate an OS image from a buildfile | Building Embedded Systems, Making an OS image |
Writing, compiling, and debugging your applications using command-line tools | Programmer's Guide |
Building your applications using the Integrated Development Environment (IDE) | IDE User's Guide, Building OS and Flash Images |
Writing a device driver | DDK Guides |
The complete QNX doc set | Documentation Roadmap (e.g. under Windows XP via the start menu: | )
Release notes | www.qnx.com (look for the appropriate release notes after logging into your myQNX account) |
Technical support forums | See the release notes for details. Look for the appropriate newsgroup. |
BSP filename conventions
In QNX BSPs, we use the following conventions for naming files:
Part of filename | Description | Example |
---|---|---|
.bin | Suffix for binary format file. | ifs-artesyn.bin |
.build | Suffix for buildfile. | sandpoint.build |
efs- | Prefix for QNX Embedded Filesystem file; generated by mkefs. | efs-sengine.srec |
.elf | Suffix for ELF (Executable and Linking Format) file. | ipl-ifs-mbx800.elf |
ifs- | Prefix for QNX Image Filesystem file; generated by mkifs. | ifs-800fads.elf |
ipl- | Prefix for IPL (Initial Program Loader) file. | ipl-eagle.srec |
.openbios | Suffix for OpenBIOS format file. | ifs-walnut.openbios |
.prepboot | Suffix for Motorola PRePboot format file. | ifs-prpmc800.prepboot |
.srec | Suffix for S-record format file. | ifs-malta.srec |