AM35x-OMAP35x-PSP 03.00.00.05 UserGuide

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

Read This First

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

About this Manual

This document describes how to install and work with Texas Instruments' Platform Support Package (PSP) for OMAP35x, AM/DM37x, AM3517 platform running Linux. This PSP provides a fundamental software platform for development, deployment and execution on. It abstracts the functionality provided by the hardware. The product forms the basis for all application development on this platform.

In this context, the document contains instructions to:

• Install the release
• Build the sources contained in the release

The document also provides detailed description of drivers and modules specific to this platform - as implemented in the PSP.

Installation

System Requirements

Hardware Requirements:

• OMAP3 EVM Rev.G(preferred) or Rev.D for OMAP35x, AM/DM37x platforms
• AM3517EVM for AM3517 platform

Software Requirements:

• CodeSourcery ARM tool chain version 2009-q1

Important
This release has been tested on the following platforms:
OMAP35x Support : OMAP3 EVM (rev.G) and OMAP35x Processor board with ES3.1 Si
AM/DM37x Support : OMAP3 EVM (rev.G) and AM/DM37x Processor board with ES1.0 Si
AM3517 Support : AM3517 EVM

Package Contents

Extract the contents of release package with the following command:

$ tar -xvfz  AM35x-OMAP35x-PSP-SDK-MM.mm.pp.bb.tgz

This creates a directory AM35x-OMAP35x-PSP-SDK-MM.mm.pp.bb with the following contents:

\---AM35x-OMAP35x-PSP-SDK-MM.mm.pp.bb
   |    Software-manifest.html
   |    Arago-FS-Software-manifest.html
   +----docs
   |    |----Building-RootFs-Arago.html
   |    |----DataSheet-MM.mm.pp.bb.pdf
   |    |----ReleaseNotes-MM.mm.pp.bb.pdf
   |    |----am3517
   |    |    `----UserGuide-MM.mm.pp.bb.pdf
   |    |----omap3530
   |    |    `----UserGuide-MM.mm.pp.bb.pdf
   +----host-tools
   |    |----linux
   |    |    `----signGP
   |    |----src
   |    |    `----signGP.c
   +----images
   |    |----boot-strap
   |    |    |----am3517
   |    |    |    `----x-load.bin.ift
   |    |    |----omap3530
   |    |    |    `----x-load.bin.ift
   |    |----fs
   |    |    |----nfs-base.tar.gz
   |    |    |----ramdisk-base.gz
   |    |    |----rootfs-base.jffs2
   |    |    |----am3517
   |    |    |    |----nfs.tar.gz
   |    |    |    |----ramdisk.gz
   |    |    |    `----rootfs.jffs2
   |    |    |----omap3530
   |    |    |    |----nfs.tar.gz
   |    |    |    |----ramdisk.gz
   |    |    |    `----rootfs.jffs2
   |    |----kernel
   |    |    |----am3517
   |    |    |    `----uImage
   |    |    |----omap3530
   |    |    |    `----uImage
   |    |----u-boot
   |    |    |----am3517
   |    |    |    `----u-boot.bin
   |    |    |----omap3530
   |    |    |    `----u-boot.bin
   +----scripts
   |    |----am3517
   |    |    |----Readme.txt
   |    |    |----initenv-micron.txt
   |    |    `----reflash-micron.txt
   |    |----omap3530
   |    |    |----Readme.txt
   |    |    |----initenv-micron.txt
   |    |    `----reflash-micron.txt
   +----src
   |    |----boot-strap
   |    |    |----ChangeLog-MM.mm.pp.bb
   |    |    |----ShortLog
   |    |    |----Unified-patch-MM.mm.pp.bb.gz
   |    |    |----diffstat-MM.mm.pp.bb
   |    |    |----x-loader-patches-MM.mm.pp.bb.tar.gz
   |    |    `----x-loader-MM.mm.pp.bb.tar.gz
   |    |----examples
   |    |    |----examples.tar.gz
   |    |----kernel
   |    |    |----Readme.txt
   |    |    |----ChangeLog-MM.mm.pp.bb
   |    |    |----ShortLog
   |    |    |----Unified-patch-MM.mm.pp.bb.gz
   |    |    |----diffstat-MM.mm.pp.bb
   |    |    |----kernel-patches-MM.mm.pp.bb.tar.gz
   |    |    `----linux-MM.mm.pp.bb.tar.gz
   |    |----u-boot
   |         |----Readme.txt
   |         |----ChangeLog-MM.mm.pp.bb
   |         |----ShortLog
   |         |----Unified-patch-MM.mm.pp.bb.gz
   |         |----diffstat-MM.mm.pp.bb
   |         |----u-boot-patches-MM.mm.pp.bb.tar.gz
   |         `----u-boot-MM.mm.pp.bb.tar.gz
   +----test-suite
        `----lftb-MM.mm.pp.bb.tar.gz 

Important
The values of MM, mm, pp and bb in this illustration will vary across the releases and actually depends on individual component versions

Environment Setup

1. Set the environment variable PATH to contain the binaries of the CodeSourcery cross-compiler tool-chain.

   For example, in bash:

   $ export PATH=/opt/toolchain/2009-q1/bin:$PATH

2. Add location of u-boot tools to the PATH environment variable(required for mkimage utility that is built as part of u-boot)

For example, in bash

$ export PATH=/opt/u-boot/tools:$PATH

Note
Actual instructions and the path setting will depend upon your shell and location of the tools

X-loader

Introduction

X-loader is loaded by ROM boot loader into internal RAM. X-loader support boot from OneNAND, NAND, MMC/SD.

Compiling X-Loader

Change to the base of the X-Loader directory.

$ cd ./x-load

Remove the intermediate files generated during build. This step is not necessary when building for the first time.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm distclean

Choose the configuration for OMAP3 EVM.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm omap3evm_config

Alternatively, if you are building for AM3517 EVM, choose

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm  am3517evm_config

Initiate the build.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm

On successful completion, file x-load.bin will be created in the current directory.

Signing x-load.bin

The file x-load.bin needs to be signed before it can be used by the ROM bootloader. The signGP tool required for signing is available in the release package under the folder - host-tools/linux.

To sign the X-Loader binary:

$ signGP x-load.bin

The signing utility creates x-load.bin.ift in the current directory.

U-boot

Compiling U-boot

Change to the base of the u-boot directory.

$ cd ./u-boot

Remove the intermediate files generated during build. This step is not necessary when building for the first time.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm distclean

Choose the configuration for OMAP3 EVM.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm omap3_evm_config

Alternatively, if you are building for AM3517 EVM, choose

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm  am3517_evm_config

Initiate the build.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm

On successful completion, file u-boot.bin will be created in the current directory.

Flashing U-boot

OneNAND

To flash u-boot.bin to the OneNAND execute the commands listed below:

OMAP3_EVM # mw.b 0x80000000 0xFF 0x100000
OMAP3_EVM # tftp 0x80000000 u-boot.bin
OMAP3_EVM # onenand erase 0x00080000  0x001C0000
OMAP3_EVM # onenand write 0x80000000 0x80000 0x1C0000

Micron NAND

To flash u-boot.bin to the Micron NAND execute the commands listed below:

OMAP3_EVM # mw.b 0x80000000 0xFF 0x100000
OMAP3_EVM # tftp 0x80000000 u-boot.bin
OMAP3_EVM # nand erase 0x80000 0x1C0000
OMAP3_EVM # nandecc sw
OMAP3_EVM # nand write.i 0x80000000 0x80000 0x1C0000

Managing OneNAND

OneNAND is only supported on older OMAP3EVMs with OneNand parts. The default configuration under U-boot enables Micron Nand support. To enable OneNand the u-boot binary has to be re-compiled after enabling OneNand Support(instead of Nand) in the config file.

Marking a bad block

To forcefully mark a block as bad:

OMAP3_EVM # onenand markbad <offset>

For example, to mark block 32 (assuming erase block size of 128Kbytes) as bad block - offset = blocknum * 128 * 1024:

OMAP3_EVM # onenand markbad 0x400000
   

Erasing OneNAND

To erase OneNAND blocks in the address range:

OMAP3_EVM # onenand erase <stoffaddr> <endoffaddr>

This command skips bad blocks (both factory or user marked) encountered within the specified range.

For example, to erase blocks 32 through 34:

OMAP3_EVM # onenand erase 0x00400000 0x00440000

Important

If the erase operation fails, the block is marked bad and the command aborts. To continue erase operation, the command needs to be re-executed for the remaining blocks in the range.

Writing to OneNAND

To write len bytes of data from a memory buffer located at addr to the OneNAND block offset:

OMAP3_EVM # onenand write <addr> <offset> <len>

If a bad block is encountered during the write operation, it is skipped and the write operation continues from next 'good' block.

For example, to write 0x40000 bytes from memory buffer at address 0x80000000 to OneNAND - starting at block 32 (offset 0x400000):

OMAP3_EVM # onenand write 0x80000000 0x400000 0x40000

Important

If the write fails on ECC check, the block where the failure occurred is marked bad and write operation is aborted. The command needs to be re-executed to complete the write operation. The offset and length for writing have to be page aligned else the command will abort.

Reading from OneNAND

To read len bytes of data from OneNAND block at offset to memory buffer located at addr:

OMAP3_EVM # onenand read <addr> <offset> <len>

If a bad block is encountered during the read operation, it is skipped and the read operation continues from next 'good' block

For example, to read 0x40000 bytes from OneNAND - starting at block 32 (offset 0x400000) to memory buffer at address 0x80000000:

OMAP3_EVM # onenand read 0x80000000 0x400000 0x40000

Important

If the read fails on ECC check, the block where the failure occurred is marked bad and read operation is aborted. The command needs to be re-executed to complete the read operation. But, the data in just marked bad block is irrecoverably lost. The offset and length for reading have to be page aligned else the command will abort.

Scrubbing OneNAND

This command operation is similar to the erase command, with a difference that it doesn't care for bad blocks. It attempts to erase all blocks in the specified address range.To scrub OneNAND blocks in the address range:

OMAP3_EVM # onenand scrub <stoffaddr> <eoffaddr>

If a bad block is encountered during the read operation, it is skipped and the read operation continues from next 'good' block

For example, to read 0x40000 bytes from OneNAND - starting at block 32 (offset 0x400000) to memory buffer at address 0x80000000:

OMAP3_EVM # onenand read 0x80000000 0x400000 0x40000

Important
The command does not check whether the block is a user marked or factory marked bad block. This command fails on a factory marked bad block.

Important
If the erase operation fails, the block is marked as bad and the command aborts. The command needs to be re-executed for the remaining blocks in the range.

Managing NAND

Micron Nand parts are supported on OMAP3EVM(OMAP35x, AM/DM37x) and AM3517EVM platforms.

Note

The following sub-sections illustrate the usage of NAND specific commands on OMAP3EVM. The same set of commands should work on AM3517 as well.

Marking a bad block

To forcefully mark a block as bad:

OMAP3_EVM # nand markbad <offset>

For example, to mark block 32 (assuming erase block size of 128Kbytes) as bad block - offset = blocknum * 128 * 1024:

OMAP3_EVM # nand markbad 0x400000

Viewing bad blocks

To view the list of bad blocks:

OMAP3_EVM # nand bad

Note
The user marked bad blocks can be viewed by using this command only after a reset.

Erasing Nand

To erase NAND blocks in the address range or using block numbers:

OMAP3_EVM # nand erase <stoffaddr> <len>

This commands skips bad blocks (both factory or user marked) encountered within the specified range.

For example, to erase blocks 32 through 34:

OMAP3_EVM # nand erase 0x00400000 0x40000

Writing to Nand

To write len bytes of data from a memory buffer located at addrto the NAND block offset:

OMAP3_EVM # nand write <addr> <offset> <len>

If a bad block is encountered during the write operation, it is skipped and the write operation continues from next 'good' block.

For example, to write 0x40000 bytes from memory buffer at address 0x80000000 to NAND - starting at block 32 (offset 0x400000):

OMAP3_EVM # nand write 0x80000000 0x400000 0x40000

Reading from Nand

To read len bytes of data from NAND block at offset to memory buffer located at addr:

OMAP3_EVM # nand read <addr> <offset> <len>

If a bad block is encountered during the read operation, it is skipped and the read operation continues from next 'good' block.

For example, to read 0x40000 bytes from NAND - starting at block 32 (offset 0x400000) to memory buffer at address 0x80000000:

OMAP3_EVM # nand read 0x80000000 0x400000 0x40000

NAND ECC algorithm selection

To select ECC algorithm for NAND:

OMAP3_EVM # nandecc <sw/hw>

Note
To write X-loader from U-Boot, ECC algorithm to be selected is HW since bootrom uses this algorithm for reading. To write U-Boot from U- Boot, ECC algorithm to be selected is SW.

MUSB Host Support

The u-boot now supports USB Mass storage class (MSC) on the MUSB port. It can be used to load any file from USB MSC device.

Note
Ensure that USB MSC device is connected to the MUSB port before issuing any of the commands described in this section

To initialize the USB subsystem:

OMAP3_EVM # usb start

All the connected devices will, now, get recognized.

To view all connected USB devices in a tree form:

OMAP3_EVM # usb tree

To view filesystem information of MSC device:

OMAP3_EVM # fatinfo usb D:P

This command shows filesystem information of a partition on the MSC device.

Note
Substitute D with the storage device number and p with the partition number on the device.

To load a file from MSC device:

OMAP3_EVM # fatload usb D:P <addr>ADDR> <file-name>

This command reads specified file from MSC device and writes its contents at the specified address.

Note
Substitute D with the storage device number and p with the partition number on the device

Linux Kernel

This chapter describes the steps required to build and configure the Linux kernel. It also provides basic steps to boot kernel on the EVM.

Compiling Linux Kernel

Change to the base of the Linux source directory.

Choose default kernel configuration for your platform.

For OMAP35x, AM/DM37x

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm omap3_evm_defconfig

For AM3517

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm am3517_evm_defconfig

Initiate the build.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm uImage

Note
For the kernel image (uImage) to be built, mkimage utility must be included in the path. mkimage utility is generated (under tools folder) while building u-boot.bin.

On successful completion, file uImage will be created in the directory ./arch/arm/boot.

Copy this file to the root directory of your TFTP server.

Modifying Kernel Configuration

OMAP3EVM

Before building the Linux kernel, it should be configured for a specific platform. This chapter describes steps to configure the kernel for OMAP3 EVM and illustrates related configuration items for reference.

Start with the default configuration for your platform

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm omap3_evm_defconfig

To view configuration interactively:

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm menuconfig

From the onscreen menu, select System Type:

   General setup  --->
[*] Enable loadable module support  --->
[*] Enable the block layer  --->
   System Type  --->
   Bus support  --->
   Kernel Features  --->
   ...
   ...

These items would be selected by default:

• OMAP35x Family
• OMAP 3530 EVM board

    ARM system type (TI OMAP)  --->
    TI OMAP Implementations  --->
-*- OMAP34xx Based System
-*-   OMAP3430 support
[*] OMAP35x Family
   *** OMAP Board Type ***
[ ] OMAP3 LDP board
[ ] OMAP 3430 SDP board
[*] OMAP 3530 EVM board
    ...
    ...

Choose Exit to successively to return to previous menu(s) and eventually back to the shell.

Some of the key drivers are enabled in the default configuration are:

• Serial port
• Mentor USB in OTG mode
• USB EHCI
• Ethernet
• MMC/SD
• Video Display
• Audio
• NAND and OneNAND
• Touchscreen
• Keypad

AM3517EVM

Before building the Linux kernel, it should be configured for a specific platform. This chapter describes steps to configure the kernel for AM3517 EVM and illustrates related configuration items for reference.

Start with the default configuration for your platform

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm am3517_evm_defconfig

To view configuration interactively:

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm menuconfig

From the onscreen menu, select System Type:

   General setup  --->
[*] Enable loadable module support  --->
[*] Enable the block layer  --->
   System Type  --->
   Bus support  --->
   Kernel Features  --->
   ...
   ...

These items would be selected by default:

• OMAP35x Family
• OMAP 3517 EVM board

    ARM system type (TI OMAP)  --->
    TI OMAP Implementations  --->
-*- OMAP34xx Based System
-*-   OMAP3430 support
[*] OMAP35x Family
    *** OMAP Board Type ***
[ ] OMAP3 LDP board
[ ] OMAP 3430 SDP board
[ ] OMAP 3530 EVM board
[*] OMAP3517/ AM3517 EVM board
[ ] OMAP3 BEAGLE board
    ...
   ...
 

Choose Exit to successively to return to previous menu(s) and eventually back to the shell.

Some of the key drivers are enabled in the default configuration are:

• Serial port
• Mentor USB in OTG mode (Host/Slave)
• USB EHCI
• Ethernet
• MMC/SD
• Video Display
• Video Capture
• Audio
• NAND
• RTC
• Touchscreen
• Keypad

Booting Linux Kernel

Selecting boot mode

OMAP3EVM (OMAP35x, AM/DM37x)

The boot mode is selected by DIP switch SW4 on the main board. This selection identifies the location from where the x-loader and u-boot binaries are loaded for execution. The switch positions differ across the boards populated with Samsung OneNAND and Micron NAND parts.

EVM populated with Samsung OneNAND

To boot from OneNAND, use either of following switch settings:

To boot from MMC (on EVM with Samsung OneNAND), use either of following switch settings:

EVM populated with Micron NAND

To boot from NAND, use either of following switch settings:

To boot from MMC (on EVM with Micron NAND), use either of following switch settings:

Note
Position of switches SW4-6, SW4-7 and SW4-8 is Don't Care. These are grayed in the illustrations above.

AM3517EVM

The boot mode is selected by DIP switch S7 on the main board. This selection identifies the location from where the x-loader and u-boot binaries are loaded for execution.

To boot from NAND, use this switch setting:

To boot from MMC, use this switch setting:

Boot from NAND/OneNAND

Power on EVM and wait for u-boot to come up.

When kernel image and filesystem are flashed on the NAND/OneNAND device:

NAND Boot mode

$ nand read.i 0x80000000 280000 500000
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2 ip=dhcp'
$ bootm 0x80000000

ONENAND Boot mode

$ onenand read 0x80000000 0x280000 0x0220000
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2 ip=dhcp'
$ bootm 0x80000000

When kernel image is flashed on the NAND/OneNAND device, and NFS mounted filesystem is being used:

NAND Boot mode

$ nand read.i 0x80000000 280000 500000
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/nfs nfsroot=/mnt/nfs,nolock ip=dhcp'
$ bootm 0x80000000

ONENAND Boot mode

$ onenand read 0x80000000 0x280000 0x0220000
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/nfs nfsroot=/mnt/nfs,nolock ip=dhcp'
$ bootm 0x80000000

When kernel image and ramdisk image are fetched from a tftp server:

$ setenv autoload no
$ dhcp
$ setenv serverip <Server IP Address>
$ tftp 0x80000000 uImage
$ tftp 0x82000000 ramdisk.gz
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 root=/dev/ram0 initrd=0x82000000,40M ramdisk_size=32768 ip=dhcp'
$ bootm 0x80000000

Boot from MMC

Power on EVM and wait for u-boot to come up.

When kernel image and filesystem (ramdisk) are available on the MMC card:

$ mmc init
$ fatload mmc 0 0x80000000 uImage
$ fatload mmc 0 0x80000000 ramdisk.gz
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 root=/dev/ram0 initrd=0x82000000,40M ramdisk_size=32768 ip=dhcp'
$ bootm 0x80000000

When kernel image is available on the MMC card and NFS mounted filesystem is being used:

$ mmc init
$ fatload mmc 0 0x80000000 uImage
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 noinitrd rw  root=/dev/nfs nfsroot=/mnt/nfs,nolock ip=dhcp'
$ bootm 0x80000000

When kernel image is available on the MMC card and filesystem on the NAND device is used:

$ mmc init
$ fatload mmc 0 0x80000000 uImage
$ setenv bootargs 'mem=128M console=ttyS0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2 ip=dhcp'
$ bootm 0x80000000
   

Note
Once the Linux kernel boots, login as "root". No password is required.

Understanding boot arguments

mpurate

This argument is used to specify the MPU frequency to be set during the boot process. The desired frequency is set statically. The frequency can be specified in MHz; and it must correspond to the valid OPP for the processor.

For example, to set the MPU frequency to 600MHz, add the following to the bootargs:

mpurate=600

Since, the OPP definition varies across processors, the list of possible values will vary across the processors as well.

The change in MPU frequency results in appropriate change in the IVA2 frequency (where available).

Note
Setting the frequency through mpurate is independent of cpufreq.

Important
On AM/DM35x, choosing value corresponding to the OPP1 also results in changing the VDD2 OPP to OPP2.

Important
On AM/DM35x, support for 720MHz is indicated by SKUID. If a silicon doesn't support this frequency, next higher frequency (600MHz) shall be set.

Important
If the bootarg mpurate is not specified, the kernel uses a default frequency - which may not be the highest supported by the processor. See Release Notes for the maximum frequency supported by the Linux kernel for your processor.

Audio Driver

Audio Driver UserGuide

Video Display Driver

Display Driver UserGuide

Resizer Driver

Resizer Driver UserGuide

Video Capture Driver

• OMAP35x, AM/DM37x Video Capture Driver UserGuide
• AM3517 Capture Driver UserGuide

USB Driver

USB Driver UserGuide

MMC Driver

MMC Driver UserGuide

Ethernet Driver

Ethernet Driver UserGuide

Power Management

• OMAP35x/DM37x Power Management UserGuide
• AM35x Power Management UserGuide

Power Management IC

Power Management IC UserGuide