Overview

The initial development boards for OMAP3530 such as the OMAP3EVM and the Beagle Board used an earlier silicon revision, ES2.1. Many people may be doing development on ES2.1 silicon and as ES3.1 silicon emerges, which is the production version of the silicon, they will be migrating to the new revision.

For the most part, ES2.1 to ES3.1 involves bug fixes. Migration effort should be very small. This article is intended to make sure users are aware of any changes they need to make with regard to Linux kernel options, driver versions, etc. as they move to the latest silicon.

How can I tell what revision a given device is?

Please see the article How to Find the Silicon Revision of your OMAP35x.

Bug fixes

A list of bug fixes can be found in the OMAP35x silicon errata. Note that this does not contain errata that are part of the Cortex A8. The Cortex A8 errata is owned and distributed by ARM Ltd. If you would like a copy you need to request it from ARM Ltd by emailing them at support-cores@arm.com. The ES2.1 silicon contains the r1p2 revision of the Cortex A8 whereas ES3.1 contains a newer r1p3 revision.

USB Host Controller

ULPI vs UTMI configuration

Compatibility break The USB Host Controller now allows you to independently configure each of the 3 ports to operate as ULPI or UTMI. Previously this was configured though UHH_HOSTCONFIG[BIT0]. In ES2.1 when this bit was cleared to 0 (default) then all 3 ports functioned in ULPI mode, but when set to 1 all 3 ports functioned as UTMI. The USB Host Controller is more flexible in that it allows you to independently configure these 3 controllers. Two new bits have been added to UHH_HOSTCONFIG. Now bit 0 controls only port 1. The new bits (11 and 12) control ports 2 and 3 respectively. To get the "old" behavior you would need to make sure bits 11 and 12 are always configured the same as bit 0.

Configurable Polarity for txen

A new register has been added called CONTROL_WKUP_CTRL. It allows you to configure the polarity of the mmn_txen_n signal. It defaults to 'active low' which was the only option in ES2.1. Therefore this change does not break compatibility because doing nothing will result in the same behavior as ES2.1.

Display Subsystem (DSS)

Changes were made to make the timings more flexible. Specifically the DISPC_TIMING_H and DISPC_TIMING_V registers made some of their bit-fields larger. That is, some of the bits that were "reserved" in ES2.1 are now functional.

DISPC_TIMING_H register
Field Name	ES2.1 Width	ES2.1 Bits	ES3.1 Width	ES3.1 Bits
HBP	8-bits	[27:20]	12-bits	[31:20]
HFP	8-bits	[15:8]	12-bits	[19:8]
HSW	6-bits	[5:0]	8-bits	[7:0]

DISPC_TIMING_V register
Field Name	ES2.1 Width	ES2.1 Bits	ES3.1 Width	ES3.1 Bits
VBP	8-bits	[27:20]	12-bits	[31:20]
VFP	8-bits	[15:8]	12-bits	[19:8]
VSW	6-bits	[5:0]	8-bits	[7:0]

Graphics Issues

For Linux:
A newer version of the graphics core is present in ES3.1. There are some minor changes in the graphics core but these changes have already been handled by the graphics driver as of version 3.00.00.09 of the graphics SDK. The script that loads the graphics driver /etc/rc.d/omap-demo interrogates the chip at run-time to determine which version of the graphics engine is present and loads the appropriate driver binary accordingly.

OpenGL ES 1.1/2.0 support in Qt/embedded 4.5.2 only works with the ES3.x silicon and corresponding graphics driver. A fix is available at http://gitorious.org/ti/ti.

There is still one small issue related to shader compatibility with OpenGL ES 2.0 and the use of the offline shader compiler. You must compile your shader program with the correct version of the shader compiler that targets the version of the graphics driver in use. An easier solution is to just use the run-time compilation which will use the correct version of the shader compiler that matches the currently enabled graphics driver. There is a small run-time penalty to do this, but this would be the best option if you need to support shader programs on multiple versions of the silicon.

For WinCE6R2:
Currently the driver is built for ES2.x silicon, but it will work on ES3.x silicon without any changes. However you do loose the ability to use the VRFB for rotated output.

ROM Changes

USB OTG Boot

On ES2.x, the USB descriptor for serial number is N/A, which is not USB compliant. On ES3.1, the USB descriptor was changed and the serial number is left blank in the descriptor list, which is USB compliant. The result of this change is very minor. Let's take the scenario where the driver was loaded on the host side to interface with ES2.x and was working successfully. When connecting an ES3.1 device to that same host it would be recognized as a new device since the descriptor is different. The host would need to reload the driver (which is actually the exact same driver) that one time. To end-users that have never used an ES2.1 device this would never be noticed as you would need to install the driver for either silicon revision regardless.

Linux kernel

The silicon revision of an OMAP3 device can be determined by reading the CONTROL_IDCODE register (refer to section 1.5 of the OMAP35x Introduction User Guide) . For OMAP3 devices, the Linux kernel should check and store the device revision by calling the function omap34xx_check_revision() (in file arch/arm/mach-omap2/id.c) during the board initialization on start-up. For example, if you refer to the OMAP3 Beagle Board board-file you will see a function called omap3_beagle_map_io(). This function calls omap2_map_common_io() which then calls omap2_check_revision() and finally calls omap34xx_check_revision(). The function omap34xx_check_revision() stores the silicon revision in a static variable called omap_revision and the value stored in this variable can be retrieved by calling the function omap_rev() (in file arch/arm/mach-omap2/id.c). Therefore, drivers and board specific code that needs to know the device revision should call the function omap_rev().

Please note that the latest stable kernel revision at the time of writing the above is 2.6.31 (see http://www.kernel.org).

For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article Migration from ES2.1 to ES3.1 here.