AM35x-OMAP35x-PSP 04.02.00.07 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!

Important changes

1. The NAND driver in Linux kernel now uses 1-bit hardware ECC. The x-loader and u-boot have been updated to use same ECC scheme.

   It is, therefore, mandatory to update the x-loader and u-boot when using the Linux kernel from this release. Filesystem residing on the NAND partition will need to be re-flashed as well.

   See detailed procedure in the User Guide

2. The serial console device has been renamed ttyOn (from ttySn).

   This impacts the bootargs passed to the kernel and console definition in the /etc/inittab of existing filesystems.

   See section Using the Correct Console Device in this document.

3. List of parameters passed to create the JFFS2 image via mkfs.jffs2 have changed.

   See section Creating JFFS2 filesystem in this document.

4. The steps for flashing the JFFS2 image to NAND from u-boot have changed.

   See section Flashing from u-boot in this document.

5. The Beagle and BeagleXM are added to list of supported platforms.
6. In Linux kernel (2.6.37), the entry corresponding to the root filesystem appearing in /proc/mounts has changed. This may cause failures in the init scripts.

   For example, when using NFS location for root filesystem, the DHCP script included in the filesystem may need to be changed.

   Click here for more details.

7. The EV_VERSION of input subsystem in the kernel has been changed to 01.00.01, so make sure that TSLIB is built with this new version change; else TSLIB throws an error.

About this Manual

This document describes how to install and work with Texas Instruments' Platform Support Package (PSP) for OMAP35x, AM/DM37x, AM3517 platforms 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 these platforms.

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:

• For AM/DM37x
  • OMAP3 Processor Module with AM37x ES1.2
  • OMAP3EVM Main Board (Rev G)
  • BeagleXM (Rev A1 and later)

• For AM3505/ AM3517
  • AM3517 Processor Module with ES1.2 Si
  • AM3517EVM (Rev C)
  • AM3517 Application board (Rev C)

• For OMAP35x
  • OMAP3 Processor Module with OMAP35x ES3.1 or later
  • OMAP3EVM Main Board (Rev G)
  • Beagle (Rev D and later)

Software Requirements:

• CodeSourcery ARM tool chain version 2009-q1

Important
This release has been system tested on the following platforms -

1. AM/DM37x Support : OMAP3 EVM (rev.G) and AM/DM37x Processor board with ES1.2 Si
2. AM3517 Support : AM3517 EVM (Rev C), Application board (Rev C) and ES1.2 Si

Only basic testing has been done on other platforms.

Package Contents

Extract the contents of release package with the following command:

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

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

\---AM35x-OMAP35x-LINUX-PSP-MM.mm.pp.bb
   |    Software-manifest.html
   +----docs
   |    |----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
   |    |    |----beagle
   |    |    |    `----x-load.bin.ift
   |    |----kernel
   |    |    |----am3517
   |    |    |    `----uImage
   |    |    |----omap3530
   |    |    |    `----uImage
   |    |    |----beagle
   |    |    |    `----uImage
   |    |----u-boot
   |    |    |----am3517
   |    |    |    `----u-boot.bin
   |    |    |----omap3530
   |    |    |    `----u-boot.bin
   |    |    |----beagle
   |    |    |    `----uImage
   +----scripts
   |    |----am3517
   |    |    |----Readme.txt
   |    |    |----initenv-micron.txt
   |    |    `----reflash-micron.txt
   |    |----omap3530
   |    |    |----Readme.txt
   |    |    |----initenv-micron.txt
   |    |    `----reflash-micron.txt
   |    |    |----initenv-samsung.txt
   |    |    `----reflash-samsung.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

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

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:

Beagle/ BeagleXM

On Beagle board by default system boots up in NAND boot mode, the boot mode is selected by User push button "S1" on the main board to force the system for MMC boot mode. Press the S1 push button and keep it holding while pressing and releasing User reset button S2. In case of BeagleXM, the only MMC boot mode supported, the switch is connected to GPIO4 only and doesn't function as a boot mode selector.

x-loader

Introduction

x-loader is the primary boot loader. It is loaded by ROM boot loader into the internal RAM. x-loader is responsible for initializing the external memory and loading the u-boot from the selected boot device.

x-loader supports boot from NAND, MMC/SD and OneNAND.

Compiling x-loader

1. Change to base of the x-loader directory.

   $ cd ./x-load

2. 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

3. Choose build configuration corresponding to the target platform
   • For OMAP3EVM:

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

   • For AM3517EVM:

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

   • For Beagle/ BeagleXM:

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

4. Initiate the build

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

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

Signing the x-loader binary

The generated x-loader.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

This creates x-load.bin.ift in the current directory.

Selecting ECC scheme

x-loader supports the following ECC schemes which need to be selected at compile time.

NOTE: For 4-bit BCH hardware ECC, 8-bit BCH hardware ECC or 1-bit Software ECC
you must first undefine ECC_HW_ENABLE.

To undefine ECC_HW_ENABLE:
1. Edit the file include/configs/<board_config>.h 
    Change from:
    #define ECC_HW_ENABLE
    Change to:
    #undef ECC_HW_ENABLE

• 1-bit hardware ECC:

Leave ECC_HW_ENABLE defined.
This is the default scheme. To build this scheme:

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

• 4-bit BCH hardware ECC:

First, undefine ECC_HW_ENABLE as described above.
To build this scheme:

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm PLATFORM_RELFLAGS+='-DFOUR_BIT_ERROR_CORRECT'

• 8-bit BCH hardware ECC:

First, undefine ECC_HW_ENABLE as described above.
To build this scheme:

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm PLATFORM_RELFLAGS+='-DEIGHT_BIT_ERROR_CORRECT'

• 1-bit software ECC:

First, undefine ECC_HW_ENABLE as described above.
To build this scheme:

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm PLATFORM_RELFLAGS+='-DONE_BIT_ERROR_CORRECT'

U-boot

Compiling U-boot

1. Change to base of the u-boot directory.

   $ cd ./u-boot

2. 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

3. Choose build configuration corresponding to the target platform
   • For OMAP3EVM:

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

   • For AM3517EVM:

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

   • For Beagle/ BeagleXM:

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

4. 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.

U-Boot Features

The generic u-boot manual is located here. It describes all generic u-boot commands.

This section describes platform specific features supported in the current release.

OneNAND Support

OneNAND is supported only 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.
• 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.

NAND Support

Micron Nand part (OMAP35x and AM3517) and Hynix Nand part (AM/DM37x) are supported.

Note

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

NAND Layout

The NAND part on the EVM has been configured in the following manner. The addresses mentioned here are used in the subsequent NAND related commands.

 +------------+-->0x00000000-> X-loader start
 |            |
 |            |-->0x0007FFFF-> X-loader end  
 |            |-->0x00080000-> U-Boot start
 |            |
 |            |-->0x001BFFFF-> U-Boot end  
 |            |-->0x001C0000-> ENV start
 |            |
 |            |
 |            |-->0x0027FFFF-> ENV end
 |            |-->0x00280000-> Linux Kernel start
 |            |
 |            |
 |            |
 |            |
 |            |-->0x0077FFFF-> Linux Kernel end
 |            |-->0x00780000-> Filesystem start
 |            |
 |            |
 |            |
 |            |
 |            |
 |            |
 |            |
 |            |
 +------------+-->0x10000000-> Filesystem end

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

Selecting ECC algorithm

NAND flash memory, although cheap, suffers from problems like bit flipping which lead to data corruption. However by making use of some error correction coding (ECC) techniques it is possible to workaround this problem.

The ECC algorithm to be used can be be selected by the command nandecc:

# nandecc [ hw <hw_type> | sw | bch4_sw | bch8_sw ] 

Usage: 

   sw           - Set software ECC for NAND
   hw <hw_type> - Set hardware ECC for NAND
                  <hw_type> - 1 for Kernel/FileSystem ECC layout
                              2 for X-loader/U-boot ECC layout
   bch4_sw      - Set 4-bit BCH ECC for NAND
   bch8_sw      - Set 8-bit BCH ECC for NAND

  (hw 1 is set as the default nandecc)

NOR Support (Only on AM3517EVM)

Intel Strata Flash (8 Mbytes) is supported, Please refer to the Application Note available at AM35x-NOR-Flash-Support-ApplicationNote for more details.

MUSB Host Support

The u-boot 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

Flashing from u-boot

OneNAND

Saving Environment variables

User can use standard u-boot command to save environment variable.

For Example, To set bootargs and save them to the environment, the following commands could be used:

OMAP3_EVM # setenv bootargs 'mem=128M console=ttyO0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2'
OMAP3_EVM # saveenv

Flashing x-loader

To flash MLO (x-load.bin.ift) to the OneNAND Flash, execute the commands listed below:

OMAP3_EVM # mw.b 0x80000000 0xFF 0x100000
OMAP3_EVM # tftp 0x80000000 MLO
OMAP3_EVM # onenand erase 0x0 0x50000
OMAP3_EVM # onenand write 0x80000000 0x0 0x50000

Flashing U-boot

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

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

Flashing Linux kernel

To flash uImage to the OneNAND Flash execute the commands listed below:

OMAP3_EVM # mw.b 0x80000000 0xFF 0x100000
OMAP3_EVM # tftp 0x80000000 uImage
OMAP3_EVM # onenand erase 0x280000 <kernel image size in HEX>
OMAP3_EVM # onenand write 0x80000000 0x280000 <kernel image size in HEX>

Flashing JFFS2 filesystem

To flash final.jffs2 to the OneNAND Flash execute the commands listed below:

OMAP3_EVM # mw.b 0x80000000 0xFF <file system size>
OMAP3_EVM # tftp 0x80000000 <file system image>
OMAP3_EVM # onenand erase 0x780000 <file system size in HEX>
OMAP3_EVM # onenand write 0x80000000 0x780000 <file system size in HEX>

NAND

Saving Environment variables

The default ECC scheme is 1-bit hardware ECC with Kernel/FileSystem ECC layout. Before saving the environment to NAND flash, always select this scheme. This will ensure that U-boot can read the environment from NAND without any ECC mismatch.

For example, to set bootargs and save them to the environment, the following commands could be used:

OMAP3_EVM # nandecc hw 1
OMAP3_EVM # setenv bootargs 'mem=128M console=ttyO0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2'
OMAP3_EVM # saveenv

Flashing x-loader

To flash MLO (x-load.bin.ift) to the NAND Flash, execute the commands listed below:

OMAP3_EVM # tftp 0x80000000 MLO
OMAP3_EVM # nand erase 0x0 0x50000
OMAP3_EVM # nandecc hw 2
OMAP3_EVM # nand write 0x80000000 0x0 0x50000

Flashing U-boot

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

OMAP3_EVM # tftp 0x80000000 u-boot.bin
OMAP3_EVM # nand erase 0x80000 0x1C0000
OMAP3_EVM # nandecc hw 2
OMAP3_EVM # nand write 0x80000000 0x80000 0x1C0000

Flashing Linux kernel

To flash uImage to the NAND Flash execute the commands listed below:

OMAP3_EVM # tftp 0x80000000 uImage
OMAP3_EVM # nand erase 0x280000 <kernel image size in HEX>
OMAP3_EVM # nandecc hw 1
OMAP3_EVM # nand write 0x80000000 0x280000 <kernel image size in HEX>

Flashing JFFS2 filesystem

To flash final.jffs2 to the NAND Flash execute the commands listed below:

OMAP3_EVM # mw.b 0x80000000 0xFF <file system size in HEX>
OMAP3_EVM # tftp 0x80000000 <file system image>
OMAP3_EVM # nand erase 0x780000 <file system size in HEX >
OMAP3_EVM # nandecc hw 1
OMAP3_EVM # nand write 0x80000000 0x780000 <file system size in HEX>

Important

The image size should be upward aligned to NAND page size which is 2KB (i.e. 0x800). For example, if the image size is 0x19B8004 the size to be passed to the NAND write command should be 0x19B8800.

NOR

Please refer to the Application notes available under - [1]

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

1. Change to the base of the Linux kernel source directory.

   $ cd ./kernel

2. 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

3. Choose build configuration corresponding to the target platform
   • For OMAP3EVM:

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

   • For AM3517EVM:

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

   • For Beagle/ BeagleXM:

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

4. Initiate the build

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

   On successful completion, file uImage will be created in the sub-directory arch/arm/boot. Copy this file to the root directory of your TFTP server.

Note

For the kernel image (uImage) to be built, location of mkimage utility must be included in the path. This utility is generated in tools sub-directory of u-boot sources when building u-boot.

Selecting NAND ECC scheme for Linux Kernel

Kernel is built with 1-bit hardware ECC scheme as a default ECC scheme. Currently, ECC scheme cannot be selected via menuconfig. Following steps should be followed to change default settings:

1. Edit files:
   • arch/arm/mach-omap2/board-flash.c
   • drivers/mtd/nand/omap2.c
   • Replace the macro "OMAP_ECC_HAMMING_CODE_HW" with either "OMAP_ECC_BCH4_CODE_HW" or "OMAP_ECC_BCH8_CODE_HW" based on ECC requirement.

Modifying Kernel Configuration

This table lists some of the key features and drivers supported by the default kernel configurations for all platforms supported in the release:

Driver	OMAP3EVM	BeagleBoard	AM3517EVM
Serial Port	Y	Y	Y
Ethernet	Y	Y	Y
MMC/SD	Y	Y	Y
Video Display (fbdev, v4l2)	Y	Y	Y
Video Capture	TVP514x, MT9T111	TVP514x, MT9T111	TVP514x
OneNAND	Y
NAND	Y	Y	Y
NOR			Y1
Touchscreen	Y		Y
Keypad	Y		Y
WDT	Y	Y	Y
RTC	Y	Y	Y
Mentor USB (in OTG mode)	Y	Y	Y
USB EHCI	Y	Y	Y
Power Management	Y	Y	Y2

¹ NOR Flash (PC28F640P30B85) is available on AM3517 Application Board

² AM3517 supports basic suspend resume only

To view and modify the kernel configuration interactively:

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

Using the Correct Console Device

In the new kernel version, the serial console device has been renamed ttyOn (from ttySn). The serial port associated with UART0 is now ttyO0 and so on...

The bootargs passed to kernel and definition of the terminal is the /etc/inittab needs must be updated to reflect this change.

Here is an illustration of changes required for ttyS0:

• Change the definition of console in bootargs

  from

  console=ttyS0,115200n8

  to

  console=ttyO0,115200n8

• Change the definition of terminal in /etc/inittab of the target filesystem

  from

  S:2345:respawn:/sbin/getty 115200 ttyS0

  to

  S:2345:respawn:/sbin/getty 115200 ttyO0

Note: The character 'O' in the serial port names stands for "OMAP UART port".

Creating JFFS2 filesystem

Since jffs2 is used only on flash devices, a standard Linux distribution does not have the tools to make a jffs2 file system. The Internet site http://sources.redhat.com/jffs2 explains where and how to obtain the latest source to MTD code and file systems. mkfs.jffs2 is the tool needed to build a jffs2 file system and the source is in this code. All of the MTD code will be downloaded but only the code to build mkfs.jffs2 is built.

The source code is maintained in a CVS tree. CVS is version control software and is usually installed when the Linux distribution is installed. CVS does not work across firewalls so a direct connection to the Internet is required. From the command line enter the following:

[root@localhost user]# cd /home/user/build
[root@localhost build]# cvs –d :pserver:anoncvs@cvs.infradead.org:/home/cvs login CVS password: anoncvs
[root@localhost build]# cvs –d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd

There should now be a mtd directory under /home/user/build. The source to mkfs.jffs2 is found in the util directory under mtd. To build mkfs.jffs2 simply change directory to mtd/util and enter “make mkfs.jffs2”. When the build is complete, copy the mkfs.jffs2 file to the /sbin directory; that is where the other utilities that make file systems reside.

[root@localhost build]# cd mtd/util
[root@localhost util]# make mkfs.jffs2
[root@localhost util]# cp mkfs.jffs2 /sbin

With the mkfs.jffs2 utility built and in place it is now time to make the jffs2 file system from of the target directory. Change to the /home/user directory and enter the mkfs.jffs2 command below. Probably the most important argument to the utility is the erase block size. For the NAND part on the EVM board the erase block is 128k Consult either u-boot, the kernel, or the data manual for the flash part used to find the erase block size.

[root@localhost util]# cd /home/user
[root@localhost util]# mkfs.jffs2 -lqn –e 128 -r target -o /tftpboot/rd-jffs2.bin

By building the file in the /tftpboot directory, the step of copying it over is eliminated. The file must now be written into flash at a specific location. In u-boot, the flash file system will get flashed to the physical address 0x780000 and will be mounted by the kernel from /dev/mtdblock<partition-number>, partition-number starts from 0, refer flash layout for exact number. The steps to perform this are:

Unprotect the flash area where the file system will reside.

Erase that area. Download the rd-jffs2.bin file. Write it to flash. Modify bootargs to support a JFFS2 file system as root on /dev/mtdblock<partition-number>. Save the environment variables.

Booting Linux Kernel

Boot from NAND

Select the boot mode as defined in section Selecting boot mode. Power on EVM and wait for u-boot to come up.

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

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

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

$ nand read.i 0x80000000 280000 500000
$ setenv bootargs 'mem=128M console=ttyO0,115200n8 noinitrd rw root=/dev/nfs nfsroot=192.168.1.1:/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=ttyO0,115200n8 root=/dev/ram0 initrd=0x82000000,40M ramdisk_size=32768 ip=dhcp'
$ bootm 0x80000000

Boot from OneNAND

Select the boot mode as defined in section Selecting boot mode. Power on EVM and wait for u-boot to come up.

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

$ onenand read 0x80000000 0x280000 0x0220000
$ setenv bootargs 'mem=128M console=ttyO0,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:

$ onenand read 0x80000000 0x280000 0x0220000
$ setenv bootargs 'mem=128M console=ttyO0,115200n8 noinitrd rw root=/dev/nfs nfsroot=192.168.1.1:/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=ttyO0,115200n8 root=/dev/ram0 initrd=0x82000000,40M ramdisk_size=32768 ip=dhcp'
$ bootm 0x80000000

Please note that steps for NAND boot mode are applicable to all platforms, where NAND Flash is supported. Please make sure to use right console number, e.g. in case of AM3517EVM, we use ttyO2, so please change ttyO0 => ttyO2.

Boot from MMC

Select the boot mode as defined in section Selecting boot mode. 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 0x82000000 ramdisk.gz
$ setenv bootargs 'mem=128M console=ttyO0,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=ttyO0,115200n8 noinitrd rw  root=/dev/nfs nfsroot=192.168.1.1:/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=ttyO0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2 ip=dhcp'
$ bootm 0x80000000

Boot from NOR

Configure the EVM in XIP boot mode as mentioned in the "Selecting boot mode" section above, power on the EVM and wait for u-boot to come up.

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

$ cp.b 0x80000000 0x08100000 0x400000
$ cp.b 0x82000000 0x08500000 0x2000000
$ setenv bootargs 'mem=128M console=ttyO0,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:

$ cp.b 0x80000000 0x08100000 0x400000
$ cp.b 0x82000000 0x08500000 0x2000000
$ setenv bootargs 'mem=128M console=ttyO0,115200n8 noinitrd rw  root=/dev/nfs nfsroot=192.168.1.1:/mnt/nfs,nolock ip=dhcp'
$ bootm 0x80000000

Note

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

Important

In the latest kernel (2.6.37) the entry corresponding to the root filesystem appearing in /proc/mounts has changed. Unless updated, the init scripts in the filesystem that use this entry to determine the device on which root filesystem is mounted will fail.

For example, the script /etc/udhcpc.d/50default doesn't send DHCP request if the root filesystem is network mounted. Although, the filesystem is successfully mounted, boot process my stall after showing errors from udhcpc.

The issue is fixed by updating the function root_is_nfs() as shown below:

Original code:

 root_is_nfs() {
       grep -qe '^/dev/root.*\(nfs\|smbfs\|ncp\|coda\) .*' /proc/mounts
 }

Updated code:

 root_is_nfs() {
       grep -qe 'nfs\|smbfs\|ncp\|coda.*' /proc/mounts
 }

When using an existing filesystem, review the init scripts to locate similar instances and make appropriate changes.

Audio Driver

Audio Driver UserGuide

Video Display Driver

Display 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

TI HECC CAN Controller

TI HECC CAN Controller