ARM9 WinCE BSP User Guide

'''  Content is no longer maintained and is being kept for reference only! '''



Introduction
This is the User Guide for the Windows Embedded CE 6.0 BSP for the Texas Instruments OMAP-L13x, AM17x and AM18 processors. This document describes the functionality and features provided by the BSP and it details the various driver and kernel APIs made available.

For information on how to build and use the BSP see the Quick Start Guide for the appropriate Development Kit.

'''Note: In this document, the term "OMAP-L138 Development Kit" or "OMAP-L138 Kit" always refers to either an OMAP-L138 Evaluation Module (EVM) or eXperimenter Kit. The term "AM1808 Development Kit" or "AM1808 Kit" always refers to an AM1808 eXperimenter Kit. When there is no danger of confusion, the term "Development Kit" or just "Kit" refers to one of the above development kits.'''

Scope
This User Guide describes the functionality and features of the OMAP-L137/AM17x and OMAP-L138/AM18x WINCE 6.0 BSPs.

BSP Code Structure
The CE 6.0 BSP consists of the following code trees:


 * C:\WINCE600\PLATFORM\OMAPL138_AM18X – OMAP-L138/AM18x Kit specific code. This folder is referred to as a  < BSPFolder >  in this document.
 * C:\WINCE600\PLATFORM\OMAPL137_AM17X – OMAP-L137/AM17x Kit specific code. This folder is referred to as a  < BSPFolder >  in this document.
 * C:\WINCE600\PLATFORM\COMMON\SRC\SOC\OMAPL13X_TI_V1 – OAL and driver libraries for peripherals in the OMAP-L13x/AM17x/AM18x SOC. This folder is referred to as the  < SOCFolder >  in this document.
 * C:\WINCE600\OSDesigns – Various sample OS designs for OMAPL138/AM18X and OMAPL137/AM17X

The shared SOC code is used by both the OMAPL138/AM18X BSP and the OMAPL137/AM17X BSP. Any SOC specific functionality in this area is configured either via registry settings or via external variables that are defined in the respective BSP.

Version stamps for the SOC and BSP code can be found in the following headers:


 * C:\WINCE600\PLATFORM\OMAPL138_AM18X\SRC\INC\bsp_version.h
 * C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\INC\bsp_version.h
 * C:\WINCE600\PLATFORM\COMMON\SRC\SOC\OMAPL13X_TI_V1\INC\bsp_soc_version.h

More information on the CE 6.0 BSP directory structure can be found in the CE 6.0 documentation:

http://msdn.microsoft.com/en-us/library/ee479271.aspx

First Stage Boot-loaders
The BSP includes first stage boot-loaders that perform hardware initialisation and load the secondary boot-loader (EBOOT). The first stage boot-loaders included in the BSP are as follows:


 * OMAP-L138 UBL with 300MHz ARM and DSP configuration
 * AM1808 UBL with 456MHz ARM configuration
 * OMAP-L137 UBL with 300MHz ARM and DSP configuration
 * AM1707 UBL with 300MHz ARM configuration (for early Kit revisions that do not support higher clock rates)
 * AM1707 UBL with 456MHz ARM configuration

The first stage boot-loaders can be found in the following directory:

…\ < BSPFolder > \SRC\BOOT\TOOLS

EBOOT Features
The BSP includes the EBOOT boot-loader. Boot-loader reference information is available here:

http://msdn.microsoft.com/en-us/library/ee478582.aspx

The EBOOT implementation supports the following functionality:


 * Serial Flash support for:
 * OMAPL137_AM17X: Numonyx M25P64 8MB SPI Serial Flash
 * OMAPL138_AM18X: Winbond W25X32 4MB SPI Serial Flash
 * NAND flash support for the Micron Technologies MT29F4G08AAC Flash
 * NOR flash support for:
 * OMAPL138_AM18X: Intel PC28F640P30T85 8MB StrataFlash
 * Persistent storage of boot parameters (such as IP address, boot mode) in Serial Flash, NOR and NAND
 * Serial debug driver on UART0 (115200 baud, 8 data bits, 1 stop bit, no parity)
 * EMAC Ethernet debug driver
 * Default device ID derived from Ethernet MAC, menu option to override.
 * Boot CE image from RAM
 * Flashing of CE images to NAND, NOR (OMAPL138_AM18X only)
 * Boot CE image from NAND, NOR (OMAPL138_AM18X only), SD/MMC card
 * Splash screen support (not for NAND boot on OMAPL137_AM17X)
 * Peripheral test options for many of the Kit peripherals

Not supported:


 * NOR flash support for:
 * OMAPL137_AM17X: Spansion S29AL032D 4MB Flash

EBOOT Sources
The main EBOOT sources can be found in the following directory:

…\ < BSPFolder > \SRC\BOOT\EBOOT

Flashing EBOOT to the Development Kit
An EBOOT binary can be flashed to Serial Flash, NOR or NAND. See the Quick Start Guide (AM18x/OMAP-L138 WinCE BSP Quick Start Guide or AM17x/OMAP-L137 WinCE BSP Quick Start Guide) for information on flashing EBOOT to Serial Flash.

Flashing EBOOT to OMAP-L137 Development Kit (NAND Flash)
Note: For flashing the AM1707 Kit see the next section.

A new EBOOT image can be flashed to the OMAP-L137 Kit NAND flash using the Code Composer Studio (CCS), which is included with the Kit. The optional UI board, with populated NAND socket, needs to be attached to the Kit base board.

Install CCS, Kit Drivers and Target Content as described in the Quick Start Guide supplied with the Kit. CCS configuration files and GEL files can also be downloaded here:

http://support.spectrumdigital.com/boards/evmomapl137/revg/

EBOOT can then be flashed as follows:

1. Perform a Release build of an OS design, as described in the AM17x/OMAP-L137 WinCE BSP Quick Start Guide.

2. Power off the Kit and set the SW2 BOOT DIP switches to Emulation Debug mode: ON, ON, ON, ON, OFF, OFF

3. Set the UI board SW1 DIP switches to NAND mode: ON, OFF, ON, ON

4. Connect the Kit JTAG socket (EMBED USB J201) to the PC using the USB cable supplied with the Kit (mini-A plug to standard-A plug).

5. Power on the Kit. Windows may prompt for XDS510 USB drivers at this point. Direct Windows to the CCS CD-ROM and it should find the drivers.

6. Start CCS using the EVMOMAP-L137 CCStudio v3.3 icon installed with CCS. CCS should detect the XDS510 USB JTAG emulator and open the Parallel Debug Manager window:

7. Right click on TMS320C674XP_0 and select Connect Device. This will connect CCS to the DSP core and initialise the Kit hardware. The CPU Status column should report Halted once connected and initialised.

8. Right click on TMS320C674XP_0 and select Open. This will open the CCS IDE window for the DSP.

9. Remove the evomapl137_dsp.gel GEL file.



10. Select File > Load GEL… and select the following GEL file:

C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\dskda830_dsp.gel

11. Select GEL > DSKDA830 Functions  > Setup_EMIFA_PinMux. Close the DSP IDE window.

12. Right click on ARM9_0 and select Connect Device. This will connect CCS to the ARM core. The CPU Status column should report Halted once connected.

13. Right click on ARM9_0 and select Open. This will open the CCS IDE window.

14. In the CCS IDE select menu option File > Load Program… and select the NAND Flash writer program: C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\nand-writer.out

15. CCS will download the program to the Kit. The CCS window should now look like this:

16. Run the flash writer by selecting menu option Debug > Run.

17. CCS will show output from the flash writer program in the Output window and you will be prompted for an image type. Enter the following into the input dialog and click OK: dspais

18. You will be prompted for a file name. Enter the following file name into the input dialog and click OK: C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\dsp-nand-ais.bin

19. The flash writer will write the DSP boot-loader to flash, reporting progress as it writes. Wait for flashing to complete. The flash writer will verify the file is written successfully and it should report that the Files matched.

20. Reload and run the flash writer again by selecting menu options File > Reload Program and Debug  > Run.

21. Enter the following into the input dialog and click OK: armubl

22. Enter the following file name into the input dialog and click OK: C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\ubl-nand.bin

23. The flash writer will write the ARM boot-loader to flash, reporting progress as it writes. Wait for flashing to complete and check that the flash writer reports Files matched.

24. Reload and run the flash writer again by selecting menu options File > Reload Program and Debug  > Run.

25. Enter the following into the input dialog and click OK: uboot

26. Enter the following file name into the input dialog and click OK: C:\WINCE600\PLATFORM\OMAPL137_AM17X\target\ARMV4I\retail\EBOOTNANDFLASH.nb0

27. The flash writer will write the EBOOT boot-loader to flash, reporting progress as it writes. Wait for flashing to complete and check that the flash writer reports Files matched.

28. Close CCS and the Parallel Debug Manager windows.

29. Power off the Kit and set the SW2 BOOT DIP switches to NAND 8-bit Boot mode: OFF, ON, ON, ON, ON, OFF

30. Connect the development PC serial port to the Kit UART (serial cable is supplied with the Kit).

31. Start your serial terminal application (115200 baud, 8N1).

32. Power on the Kit and check that the new EBOOT image boots

33. EBOOT settings can now be configured, as described in the Quick Start Guide.

Flashing EBOOT to AM1707 Development Kit (NAND Flash)
A new EBOOT image can be flashed to the AM1707 Kit NAND flash using the Code Composer Studio (CCS), which is included with the Kit. The optional UI board, with populated NAND socket, needs to be attached to the Kit base board.

Install CCS, Kit Drivers and Target Content as described in the Quick Start Guide supplied with the Kit. CCS configuration files and GEL files can also be downloaded here:

http://support.spectrumdigital.com/boards/evmam1707/revg/

EBOOT can then be flashed as follows:

1. Perform a Release build of an OS design, as described in the AM17x/OMAP-L137 WinCE BSP Quick Start Guide.

2. Power off the Kit and set the SW2 BOOT DIP switches to Emulation Debug mode: ON, ON, ON, ON, OFF, OFF

3. Set the UI board SW1 DIP switches to NAND mode: ON, OFF, ON, ON

4. Connect the Kit JTAG socket (EMBED USB J201) to the PC using the USB cable supplied with the Kit (mini-A plug to standard-A plug).

5. Power on the Kit. Windows may prompt for XDS510 USB drivers at this point. Direct Windows to the CCS CD-ROM and it should find the drivers.

6. Start CCS using the EVMAM1707 CCStudio v3.3 icon installed with CCS (or double click the evmam1707_xds510usb.ccs file). Note that you may need to create a folder called: C:\CCStudio_vX.X\boards\evmam1707_v1\gel and copy the evmam1707.gel file into that folder.

7. CCS should detect the XDS510 USB JTAG emulator and open the CCS IDE window.

8. In the CCS IDE select menu option Debug > Connect and CCS should successfully connect to the AM1707.

9. Select GEL > EVMAM1707 Functions  > Setup_EMIFA_PinMux.

10. Select menu option File > Load Program… and select the NAND Flash writer program: C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\nand-writer.out

11. CCS will download the program to the Kit. The CCS window should now look like this:

12. Run the flash writer by selecting menu option Debug > Run.

13. CCS will show output from the flash writer program in the Output window and you will be prompted for an image type. Enter the following into the input dialog and click OK: armais

14. You will be prompted for a file name. Choose one of the following ARM bootloader images that matches the clock speed that the SOC and Kit support and enter its file name into the input dialog and click OK:

For 300mhz BSP 01.00.02 and later releases: C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\arm-nand-ais.bin For 300mhz BSP 01.00.01 and earlier releases: C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\arm-nand-ais-300mhz.bin For 456 mhz: C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\arm-nand-ais-456mhz.bin

15. The flash writer will write the ARM boot-loader to flash, reporting progress as it writes. Wait for flashing to complete. The flash writer will verify the file is written successfully and it should report that the NAND boot preparation was successful!

16. Reload and run the flash writer again by selecting menu options File > Reload Program and Debug  > Run.

17. Enter the following into the input dialog and click OK: uboot

18. Enter the following file name into the input dialog and click OK: C:\WINCE600\PLATFORM\OMAPL137_AM17X\target\ARMV4I\retail\EBOOTNANDFLASH.nb0

19. The flash writer will write the EBOOT boot-loader to flash, reporting progress as it writes. Wait for flashing to complete and check that the flash writer reports NAND boot preparation was successful!

20. Close CCS and the Parallel Debug Manager windows.

21. Power off the Kit and set the SW2 BOOT DIP switches to NAND 8-bit Boot mode: OFF, ON, ON, ON, ON, OFF

22. Connect the development PC serial port to the Kit UART (serial cable is supplied with the Kit).

23. Start your serial terminal application (115200 baud, 8N1).

24. Power on the Kit and check that the new EBOOT image boots

25. EBOOT settings can now be configured, as described in the Quick Start Guide.

Flashing EBOOT to OMAP-L137 Development Kit (NAND Flash) Using Serial Flash Utility
For BSP 01.00.02 and later releases, a new EBOOT image can be flashed to the OMAP-L137 Kit NAND flash using the sfh_OMAP-L137.exe tool.

The UI board, with populated NAND socket, needs to be attached to the Kit base board.

A PC with a serial port that supports 230400 baud is required. Many USB to serial adapter cables support 230400 baud so one of these can be used.

Note 1. It is reported by customer that in case of Rev 2 OMAP-L137 processor 115200 baud rate is required.

Note 2. We have experienced issues with some USB to serial adapters. One chipset known to work with the L137 is the Prolific PL-2303.

Note 3. Due to compatibility issue, please use the sfh_OMAP-L137.exe tool and the ubl images from the same release in the following procedure.

Procedure for flashing NAND:

1. Perform a Release build of an OS design, as described in the AM17x/OMAP-L137 WinCE BSP Quick Start Guide.

2. Connect the development PC serial port to the Kit UART (serial cable is supplied with the Kit). Close your serial terminal application.

3. Set the Kit baseboard DIP switches SW2-[7 2 1 0 3 -] to [ON OFF ON OFF OFF OFF].

4. Set the UI board DIP switches SW1-[1 2 3 4] to [ON OFF ON ON]

5. Open a Windows Command Prompt (cmd.exe)

6. Change directory to the EBOOT tools area: cd C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin

7. Copy the new EBOOT image to the tools area: copy C:\WINCE600\PLATFORM\OMAPL137_AM17X\target\ARMV4I\retail\EBOOTNANDFLASH.nb0 .

8. Run the flash tool to erase the NAND Flash (change COM port if required): sfh_OMAP-L137.exe -erase -targetType OMAPL137_v1 -flashType NAND -baud 230400 -p COM1

(In case of Rev 2 OMAP-L137 processor, use 115200 baud rate)

9. Power on or reset the Kit. You should see progress being reported, wait until it completes. Note: If the erase sequence does not complete after 30 seconds press a key to terminate the sfh_OMAP-L138.exe program and continue with the flashing procedure.

10. Run the flash tool to write an appropriate UBL and EBOOT to flash (change COM port if required).

sfh_OMAP-L137.exe -flash_dsp -flashType NAND -targetType OMAPL137_v1 -baud 230400 -p COM4 -appStartAddr 0xc3f60000 -appLoadAddr 0xc3f60000 dsp-nand-ais.bin ubl-nand.bin EBOOTNANDFLASH.nb0 

(In case of Rev 2 OMAP-L137 processor, use 115200 baud rate)

11. Power on or reset the Kit. You should see progress being reported, wait until it completes.

12. Power off the Kit and set baseboard DIP switches SW2-[7 2 1 0 3 -] to [OFF ON ON ON ON OFF].

13. Start your serial terminal application (115200 baud, 8N1).

14. Power on the Kit and check that the new EBOOT image boots

15. EBOOT settings can now be configured, as described in the Quick Start Guide.

Flashing EBOOT to AM1707 Development Kit (NAND Flash) Using Serial Flash Utility
For BSP 01.00.02 and later releases, a new EBOOT image can be flashed to the AM1707 Kit NAND flash using the sfh_OMAP-L137.exe tool.

The UI board, with populated NAND socket, needs to be attached to the Kit base board.

Note. Due to compatibility issue, please use the sfh_OMAP-L137.exe tool and the ubl images from the same release in the following procedure.

Procedure for flashing NAND:

1. Perform a Release build of an OS design, as described in the AM17x/OMAP-L137 WinCE BSP Quick Start Guide.

2. Connect the development PC serial port to the Kit UART (serial cable is supplied with the Kit). Close your serial terminal application.

3. Set the Kit baseboard DIP switches SW2-[7 2 1 0 3 -] to [ON OFF ON OFF OFF OFF].

4. Set the UI board DIP switches SW1-[1 2 3 4] to [ON OFF ON ON]

5. Open a Windows Command Prompt (cmd.exe)

6. Change directory to the EBOOT tools area: cd C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin

7. Copy the new EBOOT image to the tools area: copy C:\WINCE600\PLATFORM\OMAPL137_AM17X\target\ARMV4I\retail\EBOOTNANDFLASH.nb0 .

8. Run the flash tool to erase the NAND Flash (change COM port if required): sfh_OMAP-L137.exe -erase -flashType NAND -targetType AM1707 -p COM4

9. Power on or reset the Kit. You should see progress being reported, wait until it completes. Note: If the erase sequence does not complete after 30 seconds press a key to terminate the sfh_OMAP-L138.exe program and continue with the flashing procedure.

10. Run the flash tool to write an appropriate UBL and EBOOT to flash (change COM port if required).

sfh_OMAP-L137.exe -flash -flashType NAND -targetType AM1707 -p COM4 -appStartAddr 0xc3f60000 -appLoadAddr 0xc3f60000 arm-nand-ais-456mhz.ais EBOOTNANDFLASH.nb0 

11. Power on or reset the Kit. You should see progress being reported, wait until it completes.

12. Power off the Kit and set baseboard DIP switches SW2-[7 2 1 0 3 -] to [OFF ON ON ON ON OFF].

13. Start your serial terminal application (115200 baud, 8N1).

14. Power on the Kit and check that the new EBOOT image boots

15. EBOOT settings can now be configured, as described in the Quick Start Guide.

Flashing EBOOT to OMAP-L138/AM18x Development Kit (NAND Flash)
A new EBOOT image can be flashed to the OMAP-L138/AM18x Kit NAND flash using the sfh_OMAP-L138.exe tool. The UI board, with populated NAND socket, needs to be attached to the Kit base board. Procedure for flashing NAND:

1. Perform a Release build of an OS design, as described in the AM18x/OMAP-L138 WinCE BSP Quick Start Guide.

2. Connect the development PC serial port to the Kit UART (serial cable is supplied with the Kit). Close your serial terminal application.

3. Set the Kit DIP switches S7-7 and S7-8 to ON and all others to OFF.

4. Open a Windows Command Prompt (cmd.exe)

5. Change directory to the EBOOT tools area: cd C:\WINCE600\PLATFORM\OMAPL138_AM18X\SRC\BOOT\TOOLS\bin

6. Copy the new EBOOT image to the tools area: copy C:\WINCE600\PLATFORM\OMAPL138_AM18X\target\ARMV4I\retail\EBOOTNANDFLASH.nb0 .

7. Run the flash tool to erase the NAND Flash (change COM port if required): sfh_OMAP-L138.exe -erase -targetType [OMAPL138 | AM1808] -flashType NAND -p COM1

8. Power on or reset the Kit. You should see progress being reported, wait until it completes. Note: If the erase sequence does not complete after 30 seconds press a key to terminate the sfh_OMAP-L138.exe program and continue with the flashing procedure.

9. Run the flash tool to write an appropriate UBL and EBOOT to flash (change COM port if required).

sfh_OMAP-L138.exe -flash -targetType [OMAPL138 | AM1808]  -flashType NAND -v -p COM1 -appStartAddr 0xc7f60000 -appLoadAddr 0xc7f60000    [nand-ubl]  EBOOTNANDFLASH.nb0 

where nand-ubl is:

a. For BSP 01.00.02 and later releases arm-nand-ais.bin for OMAP-L138 arm-nand-ais-456mhz.bin for AM1808

b. For BSP 01.00.01 and earlier releases ubl_OMAPL138_NAND.bin for OMAP-L138 ubl_AM1808_NAND.bin for AM1808

10. Power on or reset the Kit. You should see progress being reported, wait until it completes.

11. Power off the Kit and set DIP switches S7-6, S7-7 and S7-8 to OFF and S7-5 to ON.

12. Start your serial terminal application (115200 baud, 8N1).

13. Power on the Kit and check that the new EBOOT image boots

14. EBOOT settings can now be configured, as described in the Quick Start Guide.

Flashing EBOOT to OMAP-L138/AM18x Development Kit (NOR Flash)
A new EBOOT image can be flashed to the OMAP-L138/AM18x Kit NOR flash using the sfh_OMAP-L138.exe tool. The UI board needs to be attached to the Kit base board. Procedure for flashing NOR:

1. Perform a Release build of an OS design, as described in the AM18x/OMAP-L138 WinCE BSP Quick Start Guide.

2. Connect the development PC serial port to the Kit UART (serial cable is supplied with the Kit). Close your serial terminal application.

3. Remove any SD/MMC card from the SD card slot.

4. Set the Kit DIP switches S7-7 and S7-8 to ON and all others to OFF.

5. Open a Windows Command Prompt (cmd.exe)

6. Change directory to the EBOOT tools area: cd C:\WINCE600\PLATFORM\OMAPL138_AM18X\SRC\BOOT\TOOLS\bin

7. Copy the new EBOOT image to the tools area: copy C:\WINCE600\PLATFORM\OMAPL138_AM18X\target\ARMV4I\retail\EBOOTNORFLASH.nb0 .

8. Run the flash tool to erase the NOR Flash (change COM port if required): sfh_OMAP-L138.exe -erase -targetType [OMAPL138 | AM1808] -flashType NOR -p COM1

9. Power on or reset the Kit. You should see progress being reported, wait until it completes.

10. Run the flash tool to write an appropriate UBL and EBOOT to flash (change COM port if required).

sfh_OMAP-L138.exe -flash -targetType [OMAPL138 | AM1808] -flashType NOR -v -p COM1 -appStartAddr 0xc7f60000 -appLoadAddr 0xc7f60000 [nor-ubl] EBOOTNORFLASH.nb0 

where nor-ubl is:

a. For BSP 01.00.02 and later releases arm-nor-ais.bin for OMAP-L138 arm-nor-ais-456mhz.bin for AM1808

b. For BSP 01.00.01 and earlier releases ubl_OMAPL138_NOR.bin for OMAP-L138 ubl_AM1808_NOR.bin for AM1808

11. Power on or reset the Kit. You should see progress being reported, wait until it completes.

12. Power off the Kit and set DIP switches S7-5, S7-6 and S7-7 to ON and S7-8 to OFF. Check that there is no card in the SD card slot.

13. Start your serial terminal application (115200 baud, 8N1).

14. Power on the Kit and check that the new EBOOT image boots

15. EBOOT settings can now be configured, as described in the Quick Start Guide.

SD/MMC Card Boot Support
EBOOT supports loading a CE image from an SD/MMC card. The card needs to be formatted with a FAT file system. EBOOT will look for the following files on the SD/MMC card:


 * nk.bin / nk.nb0 – CE image file. Either a bin or nb0 file can be placed on the card. EBOOT will look for the bin file first. The bin file is usually smaller and takes less time to read but there are limits on the size of bin file supported. If EBOOT reports that there is insufficient space to read the bin file try the nb0 file instead.

The files can be written to the card using a standard PC card reader or using CE 6.0 running on the Kit.

To configure EBOOT to load the CE image from an SD card, use the Boot Settings  > Select Boot Device menu.

Boot Modes
Table 1 and 2 gives a summary of the boot modes supported on the OMAP-L13x/AM17x/AM18x Development Kit.

The ubl files can be found in

• C:\WINCE600\PLATFORM\OMAPL137_AM17X\SRC\BOOT\TOOLS\bin\

• C:\WINCE600\PLATFORM\OMAPL138_AM18X\SRC\BOOT\TOOLS\bin\

depending on the platform.

Note: SD boot is only supported on OMAP-L138 platform by BSP 01.00.01 and later releases.

OAL Features
The BSP implements a production-quality OAL. OAL reference information is available here:

http://msdn.microsoft.com/en-us/library/ee479158.aspx

The OAL implementation includes support for the following SOC features and functionality:


 * Boot parameters (passed from boot-loader)
 * ARM cache (instruction and data, write buffer)
 * Interrupt controller (including GPIO interrupts)
 * Timer (1ms fixed system tick) – uses Timer0, low 32 bits
 * Software emulation of real time clock
 * MMU
 * System IO control
 * Kernel profiler – uses Timer0, high 32 bits
 * Serial debug support – on UART2
 * KITL connection over Ethernet (interrupt or polled transport)
 * VMINI support
 * Library abstractions (PSC, PLL, GPIO abstractions)
 * Real Time Clock (RTC)
 * Watchdog Timer (Timer1)
 * Power management: CPU idle support (ARM wait for interrupt in OEMIdle)

Not supported:


 * Idle timer (GetIdleTime)

Build Options
In OMAP-L137 silicon revision 1.1 and earlier there is an issue with the ARM data cache write-back mode. The write-back mode is disabled in the BSP via the SOC type selection in the catalog. When using a later silicon revision the Rev 2 catalog entry should be selected.

The Watchdog timer is disabled by default. The Watchdog can be enabled by setting the BSP_WDT_ENABLE variable in the BSP configuration file:

…\ < BSPFolder > \OMAPL138_AM18X.bat

…\ < BSPFolder > \OMAPL137_AM17X.bat

Memory Configuration
The memory map configuration can be found in:

…\ < BSPFolder > \FILES\config.bib

There are areas of RAM reserved for some of the drivers. Should the memory map require changing the following files will need updating:

…\ < BSPFolder > \FILES\config.bib

…\ < BSPFolder > \SRC\BOOT\EBOOT\SPIFLASH\ebootspiflash.bib

…\ < BSPFolder > \SRC\BOOT\EBOOT\NANDFLASH\ebootnandflash.bib

…\ < BSPFolder > \SRC\BOOT\EBOOT\NORFLASH\ebootnorflash.bib

…\ < BSPFolder > \SRC\INC\image_cfg.h

…\ < BSPFolder > \SRC\INC\image_cfg.inc

Pin Multiplexing Configuration
The pin multiplexing configuration can be found in these headers:

…\ < BSPFolder > \SRC\INC\bsp_cfg.h

…\ < BSPFolder > \SRC\INC\bsp_cfg.inc

All pin multiplexing for the CE OS is configured via these headers. The device drivers do not perform pin multiplex configuration.

Library Features
The BSP includes a library to manage access to the SOC Power Sleep Controller. The library is implemented at the kernel level and is accessed via a KernelIOControl. The library has an API to get and set the power state for an SOC module.

Limitations
No documented limitations.

Build Options
There are no build options for this library.

Library API
The PSC driver level API is defined in the follow header:

…\ < SOCFolder > \INC\psc.h

The library header defines a set of inline wrapper functions that call the PSC KernelIOControls.

A PSC kernel level API is available for use from other kernel modules. The kernel API is defined in the follow header:

…\ < SOCFolder > \OAL\INC\kernelpsc.h

Library Features
The BSP includes a library to manage access to the SOC GPIO lines. The library is implemented at the kernel level and is accessed via a KernelIOControl. The library has an API to set the IO direction for a line and to get and set its state.

Limitations
No documented limitations.

Build Options
There are no build options for this library.

Library API
The GPIO library API is defined in the follow headers:

…\ < SOCFolder > \INC\gpiodefs.h

…\ < SOCFolder > \INC\gpio.h

The library header defines a set of inline wrapper functions that call the GPIO KernelIOControls.

A GPIO kernel level API is available for use from other kernel modules. The kernel API is defined in the follow header:

…\ < SOCFolder > \OAL\INC\kernelgpio.h

Library Features
The BSP includes a library to manage access to the SOC PLL controllers. The library is implemented at the kernel level and is accessed via a KernelIOControl. The library has an API to get all the PLL clock frequencies or just a single clock frequency.

Limitations
No documented limitations.

Build Options
There are no build options for this library.

Library API
The PLLC driver level API is defined in the follow header:

…\ < SOCFolder > \INC\pllc.h

The library header defines a set of inline wrapper functions that call the PLL KernelIOControls.

A PLLC kernel level API is available for use from other kernel modules. The kernel API is defined in the follow header:

…\ < SOCFolder > \OAL\INC\kernelpllc.h

Driver Features
The EDMA driver is built around the TI EDMA3 Low Level Driver 01.10 (July 2009) package. The EDMA3 LLD code has been wrapped in a Windows CE streams interface driver that handles the CE specifics such as initialisation and interrupt handling.

The EDMA3 LLD APIs are exposed for use by drivers and the CE EDMA driver adds a few additional APIs for event handling.

Registry Entries
The EDMA driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
When EDMA is in use by both the ARM and DSP (or any other region), the EDMA region mapping registers need configuring to prevent regions from interfering with each other ’ s DMA operations. On the ARM side this is configured via this source file:

…\ < BSPFolder > \SRC\DRIVERS\EDMA\edma3cfg.c

The region mapping register configurations are towards the end of the file. If your DSP components are using DMA channels then the region mapping registers will need to map them out of the ARM side.

Driver API
The driver API is defined in the follow headers:

…\ < SOCFolder > \EDMA\edma.h

…\ < SOCFolder > \EDMA\edma3_drv.h

Drivers should include the edma.h header.

The API is large and quite complex and is not reproduced here. See the comments in the header files and the EDMA datasheet for the SOC.

Example Usage
The EDMA test utility demonstrates how to use the driver interface to perform a simple memory to memory transfer:

…\ < BSPFolder > \SRC\TEST\APPS\EDMATEST\edmatest.c

…\ < BSPFolder > \SRC\TEST\DRIVERS\EDMATEST\edma_test.c

Driver Features
The I2C driver supports the following feature set:


 * Master mode operation
 * Support for the two I2C buses
 * 7-bit and 10-bit addresses
 * 8-bit data transfers
 * Polled or interrupt driven transfers
 * Transaction based API where a set of transfers is performed as a single operation
 * Synchronous API, protected for parallel access
 * API available to drivers and user mode applications
 * Clock rate specified per transaction
 * Kernel and driver level interfaces
 * Power management support for D0 and D4 states

The driver does NOT support the following features:


 * Slave mode operation
 * 2-bit to 7-bit data transfers
 * Ignore NACK mode
 * Free data format mode
 * Repeat start mode
 * DMA assisted transfers
 * GPIO functionality

Registry Entries
There are two sets of registry entries, one for each I2C bus. The I2C driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
There is a build option for the I2C driver in the appropriate BSP configuration file:

…\ < BSPFolder > \OMAPL138_AM18X.bat

…\ < BSPFolder > \OMAPL137_AM17X.bat

The BSP_POWER_DOWN_WHEN_IDLE variable can be used to enable power down of the I2C peripherals when they are not in use. Note that this is not enabled by default as it prevents the DSP from using I2C as the DSP cannot power up the peripherals.

Driver API
The I2C driver API is defined in the follow headers:

…\ < SOCFolder > \INC\i2ctrans.h

…\ < SOCFolder > \INC\i2c.h

The header defines a transfer structure that is used to specify one or more I2C transfers. A set of inline wrapper functions are defined in the header to open and close a bus, and to perform a transfer.

Example Usage
The I2C test utility demonstrates how to use the interface:

…\ < BSPFolder > \SRC\TEST\APPS\I2CTEST\i2ctest.cpp

Driver Features
The SPI driver supports the following feature set:


 * Master mode operation
 * Support for the two SPI buses
 * 3 pin operation
 * 4 pin operation with chip select
 * Multiple / encoded chip selection
 * Chip select delays at start and end of transfer
 * Chip select hold at end of transfer
 * 2 to 16 bit word length
 * MSB or LSB shift direction
 * Mode (CPHA, CPOL) specified per transfer
 * Polled or interrupt driven transfers
 * Timeout specified per transfer
 * Synchronous API, protected for parallel access
 * API available to drivers and user mode applications
 * Clock rate specified per transfer
 * Power management support for D0 and D4 states

The driver does NOT support the following features:


 * Slave mode operation
 * External clock source
 * Multi-buffer mode
 * 4 pin mode with SPI enable
 * DMA assisted transfers
 * GPIO functionality

Registry Entries
There are two sets of registry entries, one for each SPI bus. The SPI driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
There is a build option for the SPI driver in the appropriate BSP configuration file:

…\ < BSPFolder > \OMAPL138_AM18X.bat

…\ < BSPFolder > \OMAPL137_AM17X.bat

The BSP_POWER_DOWN_WHEN_IDLE variable can be used to enable power down of the SPI peripherals when they are not in use. Note that this is not enabled by default as it prevents the DSP from using SPI as the DSP cannot power up the peripherals.

Driver API
The SPI driver API is defined in the follow header:

…\ < SOCFolder > \INC\spi.h

The header defines a configuration structure and a transfer structure. A bus must be configured before transfers can be performed. A set of inline wrapper functions are defined in the header to open, close and configure a bus, and to perform a transfer.

Example Usage
The SPI test utility demonstrates how to use the driver interface:

…\ < BSPFolder > \SRC\TEST\APPS\SPITEST\spitest.cpp

Library Features
The BSP includes a library to support the use of the McASP peripherals. The library is linked with drivers that use McASP.

Limitations
No documented limitations.

Build Options
There are no build options for this library.

Library API
The McASP library API is defined in the follow header:

…\ < SOCFolder > \MCASP\mcasp.h

The API is quite extensive and is not duplicated here. Refer to the McASP datasheet for the OMAP-L13x for further information.

Example Usage
The AIC3106 Audio driver used the McASP library. See the Audio driver section for more details.

Driver Features
The BSP contains an audio driver for the TLV320AIC3106 Audio Codec. The driver is ARM-only with no DSP acceleration/support. The driver implements the WAVEDEV2 model. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee485632.aspx

The driver supports the following feature set:


 * Stereo playback to the LINE OUT 3.5mm jack
 * Stereo record from the LINE IN 3.5mm jack
 * L137: Stereo playback to the HP OUT 3.5mm jack
 * L137: Stereo record from the MIC IN 3.5mm jack
 * Input and output volume control
 * Sample rates supported: 8KHz, 16KHz, 11.025KHz, 22.05KHz, 44.1KHz, 48KHz, 96KHz
 * Mono and stereo streams supported
 * 8 and 16-bit sample size supported
 * McASP used to communicate with AIC3106 (I2S format with DMA support)
 * McASP configured as clock master
 * Power management support for D0 and D4 states

Registry Entries
The audio driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
There are no build options for this driver.

Driver API
The audio driver functionality is exposed via the standard CE waveform audio APIs.

There are some additional custom IOCTL ’ s implemented that support switching the input source and output destination in the AIC3106 and configuring the input gain. The IOCTL ’ s are defined in the following header:

…\ < BSPFolder > \SRC\INC\wavioctl.h

Example Usage
When the audio driver and Waveform Audio support are included in an OS design the following audio utilities are also built:


 * wavplay – Plays a WAV file
 * wavrec – Records a WAV file
 * wavevol – Adjusts the audio output volume. Command line parameter is the volume between 0 and 100.
 * wavtest – Switches between LINE IN / MIC IN and LINE OUT / HP OUT. Also provides input gain control.

The source code for wavevol and wavtest can be found in:

…\ < BSPFolder > \SRC\TEST\APPS

Three small audio test files are also included in the BSP:


 * \windows\test.wav – Windows CE start-up sound
 * \windows\tones.wav – 10 tones at 80% amplitude
 * \windows\tones2.wav – 12 tones, an octave from middle C up, 50% amplitude

Driver Features
The BSP includes a USB host controller driver for the USB 1.1 OHCI port. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee486679.aspx

The driver supports the following feature set:


 * Endpoint types: control, interrupt, bulk, isochronous
 * USB low and full speed devices support

The driver has been tested with the following class drivers and devices:


 * USB HID class driver, mice and keyboards
 * USB Storage class driver, flash drives and hard drives

Registry Entries
The USB host driver registry entries are defined in:

…\ < BSPFolder > \SRC\DRIVERS\USB\OHCI\ohci.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
No build options.

Driver API
The USB host driver functionality is utilised by the Microsoft supplied class driver layers.

Driver Features
The BSP includes a USB host controller driver for the USB 2.0 OTG port. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee486679.aspx

The driver supports the following feature set:


 * Endpoint types: control, interrupt, bulk, isochronous
 * Control endpoint plus 4 IN and 4 OUT endpoints
 * USB full and high speed devices support
 * DMA assisted transfers for interrupt, bulk, isochronous endpoints. Utilizing Generic RNDIS mode for bulk and interrupt transfers.
 * Virtual endpoint support for bulk endpoints where all bulk transfers are performed through a single HW endpoint
 * USB.org compliance test mode support. Supports test modes defined in the Embedded Hi-Speed Host Electrical Test Procedure, Revision 1.01.
 * Power management support for D0 and D4 states

The driver has been tested with the following class drivers and devices:


 * USB HID class driver, mice and keyboards
 * USB Storage class driver, flash drives and hard drives

Registry Entries
The USB host driver registry entries are defined in this file:

…\ < BSPFolder > \SRC\DRIVERS\USB\USBH\usbh.reg

The registry entries are as follows.

The USB 2.0 host controller has 4KB of FIFO RAM. This RAM needs to be shared between the 10 endpoints (5 TX and 5 RX endpoints). The control endpoint uses 64 bytes of RAM. The remaining 4032 bytes of RAM needs to be allocated between the other 8 endpoints. This allocation is configured via the registry and may need to be changed depending on expected USB usage.

 [ HKEY_LOCAL_MACHINE\Drivers\BuiltIn\USBH\CONFIG\EP < 1-4 > \ < IN/OUT >] 

Limitations
1. There is a limitation in the use of the virtual bulk endpoint support. The virtual bulk endpoint support enables all devices requiring bulk endpoints to share the same host controller endpoint. This works fine for most classes of device such as mass storage and HID devices. It will not work for classes of device that issue bulk transfers that remain open for any length of time, such as Bluetooth and RNDIS devices. When a class driver issues a bulk transfer that remains open for some time it blocks access to the endpoint that is shared with the other devices. This causes transfer timeouts for the other devices and their class drivers will disable or un-mount the devices. If Bluetooth or RNDIS devices are expected to be used then virtual endpoint support should be disabled.

Build Options
No documented build options

Driver API
The USB host driver functionality is utilised by the Microsoft supplied class driver layers.

USB2COM Library
The BSP includes a copy of the reference USB 2.0 Host Controller Driver library in this directory:

…\ < SOCFolder > \USB\USB2COM

The original sources for this library are available in the public area:

C:\WINCE600\PUBLIC\COMMON\OAK\DRIVERS\USB\HCD\USB20\USB2COM

The library has been updated to support the USB.org Embedded Hi-Speed Host Electrical Test Procedure. All the changes are marked by the following conditional compilation flag:

ENABLE_TESTMODE_SUPPORT

If support for the USB.org test modes is not required the USB Host driver can be linked with the public USB2COM library rather than the modified library.

Driver Features
The BSP includes a USB function controller driver for the USB 2.0 OTG port. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee483825.aspx

The driver supports the following feature set:


 * Endpoint types: control, interrupt, bulk, isochronous
 * Control endpoint plus 4 IN and 4 OUT endpoints
 * USB full and high speed device support
 * DMA assisted transfers for interrupt, bulk, isochronous endpoints. Utilizes Generic RNDIS mode for bulk and interrupt transfers.
 * Registration of USB descriptor sets containing Interfaces with Alternate Settings.
 * Power management support for D0 (Controller, PHY on, session enabled) and D4 (Controller, PHY off, session disabled)

The driver has been tested with the following class drivers:


 * Serial class client driver (for ActiveSync support)
 * RNDIS client driver
 * Mass Storage client driver

Registry Entries
The USB function driver registry entries are defined in this file:

…\ < BSPFolder > \SRC\DRIVERS\USB\USBFN\usbfn.reg

The registry entries are as follows.

The platform.reg file also contains registry entries to configure the USB function driver for serial device support (on COM5), RNDIS support and Mass Storage support. The serial class support enables ActiveSync to be used. See the quick start guide (ref. 1) for details of including ActiveSync in an OS design.

Limitations
1. Use of Generic RNDIS mode is not supported when the Mass Storage Class driver is in use as the MSC protocol is not compatible with GenRNDIS operation in the controller. The DisableRxGenRNDIS flag should be set when MSC class is in use.

Build Options
No documented build options.

Driver API
The USB function driver implements the standard PDD API entry points and together with a suitable MDD it supports the various Microsoft supplied class drivers.

Driver Features
The BSP includes a USB OTG driver for the USB 2.0 OTG port. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee485293.aspx

The driver supports the following feature set:


 * Dynamic switching between Host and Function mode
 * Power management support for D0 and D4 states

Registry Entries
The USB OTG driver registry entries are defined in this file:

…\ < BSPFolder > \SRC\DRIVERS\USB\USBOTG\usbotg.reg

The registry entries are as follows.

Build Options
No build options.

Driver API
The USB OTG driver supports a number of IOCTL ’ s. See the CE 6.0 documentation for details.

Driver Features
The USB subsystem in the SOC includes a CPPI 4.1 DMA module that is used by the USB 2.0 OTG controller module. The USB CDMA driver manages this CPPI DMA module.

The driver initializes the CPPI module and provides descriptor queue management. The USB host and function drivers register their descriptor queue requirements at driver initialisation time.

Registry Entries
The USB CDMA driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
No build options.

Driver API
The USB CDMA driver functionality is used by the USB Host and Function drivers.

Driver Features
The BSP includes a display driver for the LCD controller running in raster mode. Display driver reference information is available here:

http://msdn.microsoft.com/en-us/library/ee486732.aspx

The driver supports the following feature set:


 * GDI and DirectDraw support (ARM based rendering to the framebuffer).
 * Flat frame buffer for GDI without acceleration, RGB 565 mode.
 * Software cursor.
 * Output to digital LCD supporting:
 * L138: Sharp TFT-LCD LQ043T1DG01, available as the 4.3" WQVGA Display Kit from Logic Inc
 * L137/AM1707: Sharp TFT-LCD LQ043T1DG01, available on the AM1707/L137 UI Module with Touch Screen
 * L137/AM1707: Sharp TFT-LCD LQ035Q3DG01, available on the DA830 UI Module
 * Double buffering supported on DirectDraw primary surface.
 * Power management support for D0 and D4 states

Registry Entries
The display driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
Hardware Limitation: The backlight PWM line on the OMAP-L137 Kit is not wired up. The PWM line is required by the LQ043T1DG01 Touch LCD, but not the LQ035Q3DG01 LCD. Hence on OMAP-L137 Kit, only driver for LQ035Q3DG01 LCD is supported.

Build Options
If alternative LCD panels are used the LCD timing configuration can be found in the following header file:

…\ < BSPFolder > \SRC\INC\lcd_cfg.h

The display driver will allocate DirectDraw surface buffers from the SDRAM area reserved for the display, defined in:

…\ < BSPFolder > \FILES\config.bib

If insufficient memory is available for a surface buffer then the driver will fail the surface creation. The size of the display reserved area should be tuned for the applications in use (see the Memory Configuration section). The default size is 6MB, which is enough for a double buffered primary surface and a double buffered overlay surface (both full screen).

Driver API
The display driver functionality is utilised by the Microsoft GWES framework.

Example Usage
There are also some sample DirectDraw applications supplied with Windows CE:

\WINCE600\PUBLIC\DIRECTX\SDK\SAMPLES\DDRAW

See the Quick Start Guide for information on running the applications.

Driver Features
The BSP includes a display driver for the LCD controller running in asynchronous (LIDD) mode.

The driver supports the following feature set:


 * Support for the Hantronix 24x2 HDM24216L-2-L30S character mode LCD
 * Separate Hantronix and LIDD support code, enabling alternative LCD module support to be added.
 * LCD controller powered down when not in use.
 * Power management support for D0 and D4 states

Registry Entries
The display driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
No build options.

Driver API
The driver API is defined in the follow header:

…\ < BSPFolder > \INC\charlcd.h

The header defines a set of inline functions to initialise, open and close the driver, and a set of functions to update the character display.

Example Usage
The Char LCD test utility demonstrates how to use the interface:

…\ < BSPFolder > \SRC\TEST\APPS\CLDTEST\cldtest.cpp

Driver Features
The BSP includes an NDIS miniport driver for the EMAC Ethernet peripheral in the SOC.

Ethernet driver reference information is available here:

http://msdn.microsoft.com/en-us/library/ee484851.aspx

The driver supports power management states D0 and D3.

Registry Entries
The miniport driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries comprise of the standard NDIS entries plus some example TCP/IP settings. The TCP/IP settings can be configured to use DHCP to acquire an IP address or alternatively a static IP address can be configured.

Limitations
No documented limitations.

Build Options
There are no build options for this driver.

Driver API
The miniport driver functionality is utilised by the Microsoft NDIS wrapper.

Driver Features
The BSP includes a NAND flash memory device driver. The driver implements the FMD part of the standard FAL + FMD block driver model.

Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee483398.aspx

The driver supports the following feature set:


 * Support for the following NAND flash devices:
 * Micron Technologies MT29F4G08AAC Flash
 * ECC support for large page NAND devices. This uses the SOC hardware ECC module.
 * Interrupt support for detection of the ready/busy signal from the flash device via a GPIO interrupt.
 * Optimised word read/write routines to deliver maximum throughput performance. These assembler routines use multiple register load and store instructions.
 * DMA support for page read operations

Registry Entries
The NAND flash driver registry entries are defined in:


 * …\ < BSPFolder > \SRC\DRIVERS\NAND\nand.reg

The registry entries are as follows:

 [ HKEY_LOCAL_MACHINE\Drivers\BuiltIn\NandFlashDisk ] 

 [ HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\NandFlashDisk ] 

For further information on the storage manager profile registry settings refer to:

http://msdn.microsoft.com/en-us/library/aa915589.aspx

Limitations
No documented limitations.

Build options
There are a number of NAND driver build options defined in the BSP configuration batch file.

DMA Enable

Setting the BSP_ENABLE_NAND_DRIVER_DMA variable will enable the DMA page read functionality for the CE driver.

Setting the BSP_ENABLE_NAND_BOOT_DMA variable will enable the DMA page read functionality for EBOOT.

Ready Interrupt Enable

Setting the BSP_ENABLE_NAND_INTERRUPT_STATUS variable will enable interrupt based ready status checks. The interrupt ready status functionality is only used when waiting for NAND operations that take a significant amount of time. This functionality is only compiled into the CE driver and not the bootloaders.

ECC Enable

Setting the BSP_ENABLE_NAND_ECC variable will enable the ECC functionality in both the CE driver and the bootloaders. The ECC functionality uses the SOC hardware ECC module to detect and correct errors.

Driver API
The driver exposes the standard FMD driver interface allowing it to be accessed as a typical block device. Reference information for the driver API can be found here:

http://msdn.microsoft.com/en-us/library/ee484239.aspx

In addition to this, the driver supports the following IOCTLs:


 * IOCTL_FMD_RAW_WRITE_BLOCKS


 * IOCTL_FMD_GET_RAW_BLOCK_SIZE

These are provided to allow raw data to be written to the NAND flash device without going through the file system.

Driver Features
The BSP includes a serial driver that supports the UART peripherals.

Serial driver reference information is available here:

http://msdn.microsoft.com/en-us/library/ee483100.aspx

The driver supports the following feature set:


 * Support for the three UARTs (COM1 to COM3)
 * Data bits: 5 to 8
 * Stop bits: 1, 1.5 or 2
 * Baud rates: 2400, 4800, 7200, 9600, 14400, 19200, 38400, 56000, 57600, 115200, 128000
 * Parity: none, even, odd, mark, space
 * Flow control: CTS / RTS
 * Use of hardware Autoflow Control when CTS / RTS enabled
 * Power management support for D0 and D4 states (UARTs powered off when not in use)

The driver does not support use of DMA.

Registry Entries
There are three sets of registry entries, one for each UART. The serial driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
The default pin mux settings in the BSP enable only UART2 to be used. The pin mux settings for the BSP can be updated in this header:

…\ < BSPFolder > \SRC\INC\bsp_cfg.h

When the serial driver for UART2 is included in an OS design the OAL debug output is disabled via a build flag defined in this file:

…\ < BSPFolder > \sources.cmn

Driver API
The serial drivers implement the streams driver interfaces required to support the standard serial communications port APIs.

Example Usage
The serial test application demonstrates how to use the serial interfaces:

…\ < BSPFolder > \SRC\TEST\APPS\UARTTEST

The serial test application implements a simple loop-back test. The application can be built for a desktop PC (solution file provided) and for the CE device.

Driver Features
The BSP includes two drivers for supporting Software UARTs using the PRU. The PRU driver manages the Software UART firmware and the SUART driver implements a standard WinCE serial driver using the PDD framework.

WinCE serial driver reference information is available here:

http://msdn.microsoft.com/en-us/library/ee483100.aspx

PRU Soft UART firmware documentation is available here:

http://www.mistralsolutions.com/pes-support/support-downloads/l13x-daughter-card-documentation-software.html

The driver supports the following feature set:


 * Support for the three UARTs (COM4 to COM7)
 * Data bits: 6, 7, 8
 * Stop bits: 1
 * Baud rates: 1200, 12800, 2400, 4800, 7200, 9600, 14400, 19200, 38400, 57600, 115200
 * Parity: none
 * Flow control: none

Registry Entries
There is one group of registry entries for the PRU driver and another four sets of registry entries, one for each Soft UART. These are all defined in:

…\ < BSPFolder > \FILES\platform.reg

The PRU driver registry entries are as follows.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PRU]

The PRU driver also has registry entries to select which serializers are used for each Soft UART.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PRU\SUARTx]

The SUART driver registry entries are as follows for each COM port instance.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SerialX]

Limitations
The PRU firmware used in this release has the following limitations:


 * First Character for RX is garbage.
 * Only three soft-UARTs have been tested.
 * Fourth soft-UART have been emulated, but data integrity is not verified.
 * Maximum baud rate of 57600 with 16x oversampling (x8 used by default allowing 115,200 baud).

Build Options
The PRU Soft UARTs use the McASP serializers to transfer data and therefore no other drivers can use the same McASP. If a conflicting item is selected in the catalog (Audio + PWM for AM17x/L137, or Audio + McBSP for AM18x/L138) the BSP will detect the error and halt during the build process.

Driver API
The serial drivers implement the streams driver interfaces required to support the standard serial communications port APIs.

Example Usage
The serial test application demonstrates how to use the serial interfaces:

…\ < BSPFolder > \SRC\TEST\APPS\UARTTEST

The serial test application implements a simple loop-back test. The application can be built for a desktop PC (solution file provided) and for the CE device.

Driver Features
The BSP includes a driver for the Universal Parallel Port (uPP) in the OMAP-L138 / AM18x.

The driver supports the following feature set:


 * uPP configuration via registry entries
 * Single and dual channel operation
 * 8-bit and 16-bit transfer support
 * Standard streams interface API (open, close, read, write)
 * DMA assisted transfers using internal DMA unit
 * Power management support for D0 and D4 states

Registry Entries
The uPP driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

See the uPP datasheet for full details of the port configuration parameters. The registry entries are as follows.

Limitations
No documented limitations

Build Options
No build options

Driver API
The uPP driver implements a standard streams interface API (open, close, read, write). Channel A is accessible via the UPP0: device name and channel B via the UPP1: device name.

Example Usage
The uPP test application demonstrates how to use the uPP driver interface:

…\ < BSPFolder > \SRC\TEST\APPS\UPPTEST

The uPP test application is design to work with the ADC and DAC chips on the OMAPL138/AM1808 Kit UI board. The application configures the chips and performs a simple write and read operation to/from them. A loopback cable on connectors J9 and J10 can be used.

Driver Features
The BSP includes an SD/MMC host controller driver that supports the SD/MMC controllers in the SOC (two in L138/AM18x, one in L137/AM17x). Reference information is available here:

The SD driver supports the following feature set:


 * SD card support (4-bit mode, 25MHz)
 * MMC card support (1-bit mode, 20MHz)
 * MMCplus card support (4-bit and 8-bit modes, 52MHz/26MHz). Note: Only the OMAPL137/AM17X Kit has an MMCplus 8-bit capable slot. On OMAPL138/AM18X 4-bit mode will be used and only at a maximum of 26MHz (see limitations).
 * Hot plugging of cards (detection via GPIO interrupt or configurable poll interval)
 * SD high-capacity card support (SDHC)
 * DMA assisted transfers
 * Tested with card sizes up to 4GB
 * SDIO support
 * Power management support for D0 and D4 states

Registry Entries
The SD/MMC driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
The SD/MMC host controller has issues handling SDIO transfers of less than 4 bytes. This may cause a client driver to fail if it performs reads or writes of less than 4 bytes (e.g. using SD command 53).

On the OMAPL138/AM18X Kit the maximum bus speed has been limited to 26MHz (via the registry) as communications errors have been seen at higher rates. The issue is believed to be caused by interference from the EMIFA lines running to the J28 connector.

Build Options
Support for the second SD host controller on the L138/AM18x can be enabled via the BSP_SDHC2 variable in:

…\ < BSPFolder > \OMAPL138_AM18X.bat

SD card command CRC failures may be seen when using SDIO cards. Command CRC checking can be disabled in the driver by setting the SDHC_DISABLE_CMD_CRC define in the following sources file:

…\ < SOCFolder > \SDMMC\BASE\sources

Driver API
The SD/MMC driver functionality is utilised by the Microsoft supplied SD bus driver and higher layers.

Driver Features
The BSP includes a driver for the Pulse Width Modulator peripheral. The driver uses the basic functionality of the eHRPWM peripheral to create a square wave output at configurable frequency (range 50Hz to 10MHz) and at a configurable positive duty cycle (0 to 100%).

To create the output signal the PWM up-count mode is used. In this mode, the time base counter (TBCNT) starts from zero and increments until it reaches the value in the period (TBPRD) register. The system is configured such that the output signal is high when TBCNT = 0, then set low when TBCNT is equal to the CMPA comparison register.

The time base clock is configured so that it is a multiple of the desired PWM output frequency. TBCNT then determines the period, and CMPA the positive duty cycle, as shown below.



At higher frequencies the accuracy is reduced since the time base clock is derived from the module clock via a fixed set of possible dividers.

Interrupts

The driver includes a demonstration interrupt handler which adjusts the duty cycle dynamically by modifying CMPA. To include this interrupt handler in the CE build, ensure that PWM_INTERRUPT_SUPPORT is enabled.

Registry Entries
The PWM driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
The following features of the eHRPWM peripheral are currently unused in this version of the driver:


 * Deadband
 * PWM chopper
 * Trip Zone

Build Options
No build options.

Driver API
The device driver supports some custom IOControl calls which can be sent using the Win32 API function DeviceIoControl.

A sample command line application pwmtest is provided that demonstrates use of the PWM IOCTLs.

Configure PWM output:

pwmtest -c

Start generation of PWM signal:

pwmtest –s

Stop generation of PWM signal:

pwmtest –h

The pwmtest application sources can be found here:

…\ < BSPFolder > \SRC\TEST\APPS\PWMTEST

Driver Features
The BSP includes a Notification LED driver that supports the LED ’ s on the Kit. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee481282.aspx

The driver supports the following feature set:


 * LED on, off, blink, blink/pause/blink support
 * Adjustable on and off times
 * Adjustable blink/pause/blink times

Registry Entries
The LED driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
No build options.

Driver API
The LED driver implements the standard Notification LED IOCTL ’ s (via the MDD).

Driver Features
The BSP includes a Touch Screen driver that supports the TPS65070 (PMIC) touch controller on the OMAPL138/AM18X Kit. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee485627.aspx

The driver supports the standard Windows CE Touch Screen Driver functionality. Additional features:


 * Polled mode operation for unmodified Kit boards (default mode)
 * Interrupt mode operation for modified Kit boards – SOM blue-wire connection from R160 (PMIC INT) to J3-6 (GPIO2 [ 3 ] )

Registry Entries
The driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
There are two build options defined in the BSP configuration file:

…\ < BSPFolder > \OMAPL138_AM18X.bat

The IMGNOCALIBRATION variable can be cleared to enable the touch screen calibration sequence when the platform boots.

The BSP_TOUCH_IRQ_ENABLE variable can be set to enable interrupt mode operation (requires a modified Kit board).

Driver API
The Touch driver implements the standard DDSI API entry points and links with the standard touch driver MDD.

Driver Features
The BSP includes a Touch Screen driver that supports the TSC2004 controller on the AM1707/L137 UI Board. Reference information is available here:

http://msdn.microsoft.com/en-us/library/ee485627.aspx

The driver supports the standard Windows CE Touch Screen Driver functionality.

Registry Entries
The driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
No documented limitations.

Build Options
There is a build option defined in the BSP configuration file:

…\ < BSPFolder > \OMAPL137_AM17X.bat

The IMGNOCALIBRATION variable can be cleared to enable the touch screen calibration sequence when the platform boots.

Driver API
The Touch driver implements the standard DDSI API entry points and links with the standard touch driver MDD.

Driver Features
The BSP includes a driver for the two multichannel buffered serial ports (McBSP) in the OMAP-L138 / AM18x.

The driver supports the following feature set:


 * Full McBSP configuration via the registry
 * I2S mode support, as master or slave
 * TDM mode (single frame sync phase only)
 * DMA assisted transfers using EDMA
 * External IOCTL API for integration with other drivers
 * McBSP peripheral powered off when no transfers in progress

Registry Entries
The McBSP driver registry entries are defined in:

…\OMAPL138_AM18X\FILES\platform.reg

There are a large number of McBSP configuration parameters and they are not all documented here. Please refer to the McBSP datasheet for full details of the port configuration parameters. The registry entries are as follows.

Limitations
No documented limitations.

Build Options
No build options.

Driver API
The McBSP driver provides an interface for other drivers to register function callbacks that fill and empty data buffers and control TX/RX operation. The API and callback definitions are defined in the following headers:

…\ < SOCFolder > \MCBSP\mcbsp.h

…\ < SOCFolder > \MCBSP\memtxapi.h

McBSP0 is accessible via the MCP0: device name and McBSP1 via the MCP1: device name.

Example Usage
The McBSP test driver and application demonstrate how to use the driver interface:

…\OMAPL138_AM18X\SRC\TEST\DRIVERS\MCBSPTEST

…\OMAPL138_AM18X\SRC\TEST\APPS\MCBSPTEST

The test driver performs simple TX and RX transfers with the McBSP in digital loopback mode.

Driver Features
The BSP includes a capture driver for the video port interface (VPIF) in the OMAP-L138 / AM18x. By default, the VPIF driver performs an internal loopback of captured frames as well as passing them up to applications.

The driver supports the ITU-BT.656 format.

Registry Entries
The VPIF driver registry entries are defined in:

…\ < BSPFolder > \FILES\platform.reg

The registry entries are as follows.

Limitations
Supports only ITU-BT.656 format.

Build Options
No build options.

Driver API
The VPIF driver implements a standard DShow CAMERA API. Channel is accessible via the CAM1: device name.

Example Usage
The VPIF test application demonstrates how to use the VPIF driver:

…\ < BSPFolder > \SRC\TEST\APPS\VPIFTEST

The VPIF test application starts the capture through DShow API.

Power Management
This BSP release implements support for some basic power management (PM). The drivers support D0 and D4 states and system suspend / resume support is implemented.

There is no support for voltage or frequency scaling.

System Power States
A sample PM configuration is included in the platform.reg file. The standard CE System Power States are configured as follows:


 * On:
 * All peripherals are powered up (D0 state)
 * UserIdle:
 * Entered after 2 minutes of inactivity (i.e. no interaction with the GUI)
 * No change to device power states
 * SystemIdle:
 * Entered after a further 5 minutes of inactivity
 * Devices are powered down (D4 state)
 * The NDIS Ethernet driver is left enabled by default so a telnet session can be used to power the system back up using the pmset tool
 * Suspend:
 * Can be entered using the pmsuspend tool

Power Management Configuration
The sample PM configuration is disabled by default in platform.reg. The configuration can be enabled by setting the BSP_POWERMAN variable in:

…\ < BSPFolder > \OMAPL138_AM18X.bat

…\ < BSPFolder > \OMAPL137_AM17X.bat

Notes:

1. When the sample PM configuration is disabled the default CE 6.0 PM configuration is used.

2. Power down of the LCD display has been disabled when the default CE 6.0 PM configuration is used (so the LCD is not switched off in a default OS build).

Suspend / Resume
This BSP release has suspend / resume support for the OMAP-L138/AM18x and OMAP-L137/AM17x platforms.

Notes:

1. When entering the suspend state the CE Power Manager powers down all the peripherals (sets all drivers to D4 state).

2. On L137 / AM17x all interrupts except RTC are disabled and the ARM is put into Wait For Interrupt mode.

3. On L138 / AM18x the SDRAM is put into self refresh mode and powered down, the PLL controllers are powered down and the SOC is put into Deep Sleep mode.

4. On L137 / AM17x the only wake source supported is the RTC alarm.

5. On L138 / AM18x there are two wake sources supported:


 * Internal source – RTC alarm
 * External source via the DEEPSLEEP pin – connected to UART2 CTS

6. The pmsuspend tool can be used to enter the system suspend state. The wake source can be specified on the command line.

7. On L138 / AM18x when resuming the SDRAM and PLL controllers are powered up.

8. On resume the CE Power Manager powers up all the peripherals (sets all drivers to D0 state).

Power Management Tools
When power management is enabled a number of tools are available:


 * pmtimeout – Sets the idle timeouts used to transition between PM states
 * pmsuspend – Sets an RTC alarm and puts the platform into suspend
 * pmset – Sets the system power state
 * pmget – Gets the current system power state
 * pmsetd – Sets the power state for a device
 * pmgetd – Gets the power state for a device
 * pmreq – Sets a device power requirement
 * pmmon – Monitors and reports on power state changes

Most of the tools display help if run with no command line parameters. Some example usage follows.

e.g. Put the system into the System Idle state by setting some short idle timeouts: pmtimeout set 10 10 After 20 seconds of idle time system will go into System Idle.

e.g. Set system power state to On: pmset On e.g. Go into suspend with a 1 min RTC alarm:  pmsuspend -t 1

Power Measurements
Some power measurements have been taken on an OMAP-L138 Kit using a Power Management Daughter Card (PMDC).

Notes:

1. Platform: OMAP-L138 Kit, 300MHz, base board + SOM + LCD + PMDC

2. CE OS Build: OMAPL138_AM18X_SAMPLE with KITL disabled

3. Drivers included: GPIO, EDMA, Audio, I2C, SPI, Display (LCDC), EMAC Ethernet, SD Host, TPS65070 Touch, USB OTG (OHCI NOT included)

4. EBOOT: In menu, SPI, LCDC enabled, Ethernet disabled

5. Full On: All peripherals enabled via PSC

6. System Idle: All peripherals disabled via PSC except EMAC and GPIO. USB PHYs powered down.

7. Suspend: All peripherals disabled, RAM in self-refesh, DDR2 powered down, PLLC ’ s powered off and SOC in Deep Sleep mode

Details of the channels:

Test Applications
The BSP includes a number of test applications. The test applications can be found in:

…\ < BSPFolder > \SRC\TEST

The test applications are included in the OS image by default. Inclusion of these modules can be disabled in the BSP configuration script:

…\ < BSPFolder > \OMAPL138_AM18X.bat

…\ < BSPFolder > \OMAPL137_AM17X.bat

by commenting out the following variables:

BSP_INCLUDE_TEST_APPS