From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search

Translate this page to

OMAP35x to AM35x Software Migration Guide

DVSDK

AM35x contains only ARM cortex A8 and the SGX graphics processor. Hence, AM35x SDK does not contain the DSP codecs, BIOS as well as BIOS Utils.

AM35x SDK does not contain DVSDK demos, Digital Multimedia Application Interface (DMAI), Multi-media Framework Package (MFP), DSP Link, Digital Video Test Bench (DVTB), and XDAIS Tools

There is no DVSDK corresponding to AM35x EVM. Instead there is AM35x SDK.

AM35x SDK

AM35x SDK contains the following packages as seperate installers.

Linux Platform Support Package (Linux PSP) - Use the Linux PSP v3.xx release for working with AM35x EVM boards. Refer to Getting Started Guide (GSG:_AM35x_EVM_Software_Setup) for more information with respect to installation and build.
Graphics Software Development Kit (Graphics SDK) - Use Graphics SDK v3.01.xx for working with AM35x EVM boards. For further information, refer AM35x-OMAP35x_Graphics_SDK_Getting_Started_Guide
Graphics Demonstration Software - For further information, refer OpenGLES_Texture_Streaming_-_bc-cat_User_Guide

AM35x Linux PSP

This section describes software interface level changes for drivers supported as part of the BSP and should serve as an aid for migrating existing applications from OMAP35x to the AM35x SoC.

Supported Boot Modes

OMAP35x and AM35x SoCs support multiple boot modes such as boot from Nand,OneNand,MMC,UART,NOR.

From a SW support standpoint, the list of supported boot modes is constrained by what is populated on the EVM.

For OMAP35x(on OMAP3EVM), BSP package includes support for boot from Nand,OneNAND and MMC (UART mode verified separately)

For AM35x, BSP package includes support for boot from Nand and MMC (NOR not supported though the EVM includes NOR)

X-Loader/U-boot

The Boot-up procedure is two-stage involving a preliminary bootloader(x-loader) running out of SRAM and secondary bootloader(u-boot) that runs out of DDR.

Only notable difference from bootloader perspective is inclusion of support for on-chip EMAC peripheral on AM35x.

Ethernet Driver

OMAP35x does not include on-chip ethernet controller. On the OMAP3EVMs, an external SMSC 9115/9220 is interfaced to OMAP35x over GPMC. SMSC 9115/9220 is mid-end ethernet controller - with limited FIFO space and no DMA capability. The ethernet driver implementation for the controller complies with Linux NAPI framework (for interrupt load mitigation) and relies on the CPU to move data to-from the SMSC controller FIFO. Hence the performance that can be realized with this implementation is constrained (CPU load, latency)

With AM35x, the ethernet controller is integrated to the SoC. Most notably the MAC module on AM35x includes DMA mastering capability that can relieve precious CPU cycles. The driver for AM35x MAC module complies with Linux NAPI framework and should sustain better at higher traffic load.

Overall from SW migration standpoint the interfaces, features supported are broadly compatible between OMAP35x and AM35x though AM35x should be capable of supported higher bandwidth with integrated on-chip MAC controller.

Audio Driver

The basic components that make-up the audio subsystem like McBSP,I2C,sDMA are unchanged from OMAP35x. Only notable difference is with respect to the audio codec - that is different between OMAP3EVM(TPS65950 audio codec) and AM3517EVM(AIC23b).The SW implementation is built around the ASOC framework in Linux that ties the sub-components together. Applications interface through the ASOC user space library which insulates them from changes in underlying sub-components.

AM3517EVM supports Mic-In - in addition to Line-In and Line-Out as on OMAP3EVM

Storage Subsystem - NAND, MMC/SD

OMAP35x and AM35x share the same GPMC(interfacing NAND, NOR)and MMC/SD Host controller implementation. The SW drivers are hence re-used and support the same set of features.

Only differences arise due to board related differences - AM3517EVM includes 4-bit MMC slot, whereas OMAP3EVM can support 8-bit MMC.

Display Sub-system

The Display controller module is similar in both OMAP35x and AM35x supporting various features like, 3 plane (gfx, video1 and video2), 2 overlay manager (LCD/DVI out and TV out), VRFB rotation engine, alpha blending, and color keying.

Other differences in the features supported can be attributed to EVM dependencies and SW framework differences. The differences are summarized below:

LCD resolution: OMAP35x EVM supports portrait orientated (480x640) LCD panel. AM35x EVM supports landscape oriented (480x272) LCD panel. Software transparently selects default resolution/orientation.

LCD backlight control: OMAP35x LCD backlight is controlled through power IC TPS65950, which in turn supports scaling brightness over scale of 0-100. On AM35x, LCD backlight is controlled by GPIO pin that can only be turned on/off. There is no backlight class driver available for AM35x unlike OMAP35x.

Brightness control in case of OMAP35x -

# echo 70 > /sys/class/backlight/sharp-ls/brightness

LCD panel on/off in case of AM35x

# echo 0 > /sys/devices/platform/omapdss/display0/enabled
OR
# echo 4 > /sys/class/graphics/fb0/blank

NOTE: The above on/off method will also work on OMAP35x.

Tv Out support: OMAP35x EVM supports both S-Video and CVBS. On the AM35x EVM only S-Video out is supported. From software point of view, the default TV out is S-Video on both OMAP35x and AM35x, user can change it to CVBS (in case of OMAP35x) using menuconfig option.

DVI support: DVI output is supported through external TFP410 DVI encoder. OMAP35x controls DVI output enable through GPIO whereas AM35x controls it through on board switch (SW7.8) mounted on EVM.

Video Display Driver

The video display sub-system on OMAP35x and AM35x is largely unchanged. Hence the same implementation(both fbdev and v4l2) is leveraged for both these platforms. From application standpoint(barring the changes summarized above) the migration should be seamless.

V4L2 Capture Driver

On Capture side, OMAP35x supports various IPIPE features like previewer, resizer and histogram. AM35x consists of CCDC block allowing user to capture raw data(without any processing). The SW implementation supports BT656 interface through TVP5146 decoder.

Driver Framework: OMAP35x video capture driver complies with V4L2-Int framework(legacy). The capture driver for AM35x is based on (latest) V4L2 Sub-device framework. Since this applies to the driver organization only and doesnt bubble up to application level, the user space API remains largely unaffected.

Buffer Management(scatter-gather support): OMAP35x consists of separate IOMMU block for Capture module allowing driver/user to use non-contiguous memory. Applications can thus use malloced(virtually contiguous ) memory or memory allocated through vmalloc()(in kernel-space). On AM35x, the driver can only support physically contiguous buffer.

Buffer Pre-allocation: OMAP35x capture driver doesn't allocate any buffers during init time, whereas AM35x capture driver allocates 2 static buffers of size "720 * 576 * 2" during init(as memory can get fragmented and the driver supports physically contiguous buffers only).

Stand-Alone Resizer Driver

On OMAP35x, the catpure sub-subsytem includes resizer functionality that can be exported to the user for memory-to-memory resize operation(one-shot mode). This is supported through a char device interface on Linux (WIP for Mem-to-Mem framework under V4L2)

On AM35x, with no native HW support - resize operations will now have to be managed in SW completely if need be.

USB Drivers

MUSB OTG Driver

Mentor OTG core version for AM35x has been upgraded as compared to OMAP35x - some of the hardware issues applicable to OMAP35x have been addressed with this upgradation. Additionally AM35x USB controller uses an enhanced version of DMA controller which allows chaining of requests - thereby boosting throughput along with reduction of CPU loading.

The following sections describe the impact of these changes as applicable to specific uses cases

Mass Storage Class(Host)

On AM35x MSC Host class driver should see throughput improvement as the DMA can be used for for concurrent transfers(both Tx and Rx)

CDC/RNDIS Class

With the enhanced DMA (one interrupt for complete transfer) and chaining capability , CDC/RDNIS gadget should see throughput improvement.

Isochronous Transfer Class(UVC,UAC)

Request chaining ability should translate into improvement in FPS rate as turnaround time between transfers can be minimized. As compared to OMAP35x, the USB driver should be able to sustain simultaneous audio recording along with video streaming(VGA resolution).

Since applications interface through class/gadget drivers and these are unchanged between OMAP35x and AM35x, there should be no interface level changes from application standpoint.

USBHOST(EHCI) Driver

There is no change in USBHOST interface.

Power Management

AM35x do not have any extensive power management capabilities. The only supported power management software feature is suspend to RAM with the lowest possible power state being Retention. The software interface for suspend is same as that used for OMAP35x.

Additional Info

Refer to AM35x Getting Started Guide (AM35x_Getting_Started_Guide) for more information on setup, demonstrations and development.

Hardware Migration Guide

Refer to the OMAP35x to AM35x Hardware Migration Guide

For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article OMAP35x to AM35x Software Migration Guide here.