Supported Platforms

From OMAPpedia

Revision as of 17:29, 15 April 2011 by Pngolla (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


[edit] Introduction

Generally used OMAP and Connectivity combinations are OMAP3 and WL127x (as in Zoom2, Zoom3 devices) or OMAP4 and WL128x (as in Blaze devices). However, few customers and internal TI teams need combinations OMAP3 + WL128x and OMAP4 + WL127x. So, the new requirement is to make it easy for customers and TI teams to move between WL127x and WL128x for OMAP3 and OMAP4.

There are multiple WiLink devices that can be supported on multiple OMAP platforms. Below list provides combination of platforms available:

[edit] Problem Description

OMAP and Connectivity chips use physical ports such as UART & SDIO for communication, GPIO(s) for device on/off, and McBSP port(s) for data communication. OMAP uses GPIO to enable Connectivity chip, UART is used for BT, FM, and GPS control & data flow , SDIO is used for WLAN control and data flow, and McBSP is used for Bluetooth PCM & FM TX audio paths.

In current solution, board configuration file (eg., board-zoom2.c) adds a platform device containing Bluetooth (BT), FM (if any) GPIO(s), and these GPIO numbers are defined in this file. Board configuration file may also contain code to perform (towards end of boot) correct pad settings for BT and FM GPIO(s), and BT FM McBSP lines. Also, this file is the place holder for any Connectivity chip related fixes that have to be applied during kernel boot.

So, board configuration file would have to be modified to add support for building kernel for required OMAP + Connectivity combinations. In general, users need to wade through lot of code to enable non-default platform configurations.

[edit] Proposed Solution for BT, FM, and GPS - FlexST

Instead of cluttering board configuration file with logic needed to support OMAP + Connectivity combinations, a neater approach would be to group generic BT, FM, and GPS related configurations to a separate file (called as Connectivity config file). And, board config file will be modified to use Connectivity config file. So, with FlexST solution, Connectivity config file:

Connectivity config file will expose API(s) for board config files. Board config file will invoke (at right places in boot procedure) API(s) of Connectivity config file to add Connectivity platform device and configure GPIO(s) lines. Connectivity config file will be built as part of kernel.

Board config file will call API(s) implemented in new Connectivity config file to perform generic Connectivity configurations. Thus, board config file will appear tidier. However, board config file will apply any non-generic-chip-specific fixes to Connectivity chip. For example, VIO leakage fix is specific for WL127x and not needed for WL128x. Thus, board config file for platform containing WL127x will apply VIO leakage fix, while other board config files will ignore this fix. So, with FlexST solution, board config file:

Note: Shared Transport uses the platform device added in the connectivity configuration file, details on the shared transport driver can be found at and information regarding source code can be found at

[edit] APIs exposed by FlexST

  1. void conn_board_init(int *gpios)
    Description: This API adds platform device needed for Connectivity chip and configures BT, FM, and GPS GPIOs. Main board configuration file will call this API from the board init function.

[edit] Steps to add support for new platform

Steps shall be followed to add support for new platform combination:

[edit] Support Contacts

Write your queries to WCG Leads

Back to Connectivity Home Page

Personal tools