DM814x AM387x PSP User Guide

DM814x AM387x PSP User Guide

Linux PSP

IMPORTANT

DM816x refers to DM816x/AM389x devices unless specified.
DM814x refers to DM814x/AM387x devices unless specified.
DM81xx refers to both DM816x, DM814x and DM813x.

Read This First

1) HDVPSS binaries are no longer packaged with release tar ball, instead they can be downloaded from the PSP Software Download page
2) Suspend to memory/resume is supported, if UART wake-up/resume is desired then "no_console_suspend" needs to be passed as part of bootargs.For more details refer to Suspend to Memory

About this Manual

This document describes how to install and work with Texas Instruments' Platform Support Package (PSP) for the DM8148 platform. This PSP provides a fundamental software platform for development, deployment and execution on DM8148 EVM. 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.

Important
This release has been tested on DM8148 EVM (Base board + daughter card required to verify  NOR)

Installation

Prerequisites

Before you begin with the installation of the package please make sure you have met the following system requirements:

• Windows machine
• Host machine running a version of Linux such as RedHat Enterprise Linux or Ubuntu.
• DM8148 EVM

The Windows machine is used for running CCSv4, which will be used to build flash writers and also to burn the boot images (U-Boot) onto the flash using the flash writers provided.

The Linux host is used for the following:

• Recompiling U-Boot and the Linux kernel.
• Hosting the NFS server to boot the EVM with NFS as root filesystem

You can use either the Windows machine or the Linux host for

• Hosting the TFTP server required for downloading kernel and file system images from U-Boot using Ethernet.
• Running a serial console terminal application

Software Overview

To begin developing applications, you need to install PSP package and the toolchain.

Package Contents

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

Extract the contents of release package on your Linux host with the following command:

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

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

\---TI814x-LINUX-PSP-MM.mm.pp.bb
|----TI814xPSP_Software_Manifest
+----docs
|    |----DM814x_AM387x_PSP_MM.mm.pp.bb_Release_Notes.pdf
|    |----DM814x_AM387x_PSP_User_Guide.pdf
|    |----DM81xx_AM38xx_Audio_Driver_User_Guide.pdf
|    |----DM81xx_AM38xx_EDMA_Driver_User_Guide.pdf
|    |----DM814x_AM387x_PSP_U-Boot.pdf
|    |----DM814x_AM387x_VPSS_Video_Driver_User_Guide_PSP_MM.mm.pp.bb.pdf
|    |----DM81xx_AM38xx_PSP_McSPI_Driver_Guide.pdf
|    |----DM814x_AM387x_PSP_MM.mm.pp.bb_Feature_Performance_Guide.pdf
|    |----DM81xx_AM38xx_PSP_MMC_SD_Support.pdf
|    |----DM816x_AM389x_HDMI_User_Guide.pdf
|    |----DM81xx_AM38xx_PCI_Express_Root_Complex_Driver_User_Guide.pdf
|    |----DM81xx_AM38xx_PCI_Express_Endpoint_Boot_Driver_User_Guide.pdf
|    |----DM81xx_AM38xx_USB_User_Guide.pdf
|    |----DM81xx_AM38xx_PSP_WDT_Support.pdf
|    |----DM814x_AM387x_PSP_Flashing_Tools_Guide.pdf
|    |----DM81xx_AM38xx_PSP_TouchScreen_Driver_Guide.pdf
|    |----DM814x_AM387x_PM_Suspend_resume_overview.pdf
+----host-tools
|    |----nand-flash-writer.out
|    |----nor-flash-writer.out
|    |----spi-flash-writer.out
|    |----mksd-ti814x.sh
|    |----DM814x_gel.zip
|    +----src
|    |    |----nandflash-MM.mm.pp.bb.tar.gz
|    |    |----norflash-MM.mm.pp.bb.tar.gz
|    |    |----spiflash-MM.mm.pp.bb.tar.gz
+----images
|    +----kernel
|    |    +----ti814x
|    |    |    |----uImage
|    +----u-boot
|    |    |----ti814x
|    |    |    |----u-boot.bin
|    |    |    |----u-boot.min.nand
|    |    |    |----MLO
|    +----examples
|    |    |----pcie
|    |    |    |----saBootApp
+----src
|    +----kernel
|    |    |----ChangeLog-MM.mm.pp.bb
|    |    |----diffstat-MM.mm.pp.bb
|    |    |----kernel-patches-MM.mm.pp.bb.tar.gz
|    |    |----linux-MM.mm.pp.bb.tar.gz
|    |    |----ShortLog
|    |    |----Unified-patch-MM.mm.pp.bb.gz
|    +----u-boot
|    |    |----ChangeLog-MM.mm.pp.bb
|    |    |----diffstat-MM.mm.pp.bb
|    |    |----ShortLog
|    |    |----u-boot-patches-MM.mm.pp.bb.tar.gz
|    |    |----u-boot-MM.mm.pp.bb.tar.gz
|    |    |----Unified-patch-MM.mm.pp.bb.gz
|    +----examples
|    |    |----examples.tar.gz
|    |    |----pcie
|    |    |    |----bootscript.txt
|    |    |    |----saBootApp.c
|    |    |    |----Makefile
|    |    |    |----README

Few points to note about the above structure:

Assuming the release package is extracted inside directory represented as $TI814x-PSP-DIR:

• U-Boot source tarball is u-boot-MM.mm.pp.bb.tar.gz needs to be extracted on Linux build host. This will create U-Boot source base for TI814x

$ cd $TI814x-PSP-DIR/TI814x-LINUX-PSP-MM.mm.pp.bb/src/u-boot
$ tar -xvfz u-boot-MM.mm.pp.bb.tar.gz

• Similarly kernel source tarball linux-MM.mm.pp.bb.tar.gz from TI814x-LINUX-PSP-MM.mm.pp.bb/src/kernel directory needs to be extracted to have kernel source directory setup for building kernel and/or modules

$ cd $TI814x-PSP-DIR/TI814x-LINUX-PSP-MM.mm.pp.bb/src/kernel
$ tar -xvfz linux-MM.mm.pp.bb.tar.gz

• Various Video and Audio example sources are included inside $TI814x-PSP-DIR/examples/examples.tar.gz
• Additionally, PCIe Endpoint boot application is provided in pcie directory inside $TI816X-PSP-DIR/examples

Toolchain

To build U-Boot and the Linux kernel, you will need to download and install CodeSourcery ARM tool chain version 2009-q1. For additional documentation on installing the CodeSourcery tools, please visit the CodeSourcery website.

To help you get started quickly the PSP package comes with pre-built binaries. However, after making any changes to U-Boot and Linux Kernel you need to cross-compile them using the CodeSourcery toolchain and use the new binaries that are generated

Environment Setup

After you have installed the CodeSourcery toolchain you need to setup the environment in the Linux host.

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 the location of U-Boot tools directory to the PATH environment variable (required for mkimage utility that is built as part of U-Boot build process and is needed to generate uImage when building the kernel)

   For example, in bash:

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

Note
Actual commands to be used for setting the environment variables will depend upon your shell and location of the tools

Flashing Tools

On DM8148 EVM, the Cortex-A8 core boots up first. On boot-up, the ARM core runs the U-Boot image which need to be present in the flash memory of the EVM.

The flash-writers are a part of the PSP package. Instructions on how to use the flash-writers in CCSv4/v5 can be found in PSP Flashing Tools Guide (DM814x_AM387x_PSP_Flashing_Tools_Guide.pdf).

U-Boot

Please refer to U-Boot User Guide for details about U-Boot in the context of DM814x.

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.

$ make CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm ti8148_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 of U-Boot) while building the U-Boot binary.

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

DM8148 EVM

This section describes the steps to configure the kernel for DM8148 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 ti8148_evm_defconfig

To view configuration interactively:

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

From the onscreen menu, select System Type and press ENTER:

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

Select ARM system type

ARM system type (TI OMAP)  --->   
TI OMAP Common Features  --->
TI OMAP2/3/4 Specific Features  ---> 

You will be presented with various ARM based SoCs. Select OMAP as

(X) TI OMAP

After pressing ENTER, you will be presented earlier menu. Select "TI OMAP2/3/4 Specific Features" and press ENTER. Select various options as shown below (marked with '[*]') by pressing Y on each item after selecting it.

[*] Typical OMAP configuration 
[ ] TI OMAP2
[ ] TI OMAP3
[ ] TI OMAP4
[*] TI 81XX
[ ] TI816X support
[*] TI814X support
...
*** TI81XX Board Type ***
[*] TI8148 Evaluation Module

Note that the "TI814X support" option will be shown only if you enable "TI 81XX". Similarly, "TI8148 Evaluation Module" option will be presented only after selecting "TI814X support"

Choose Exit successively to return to previous menu(s) and eventually back to the shell. Make sure to save the changes you have made when prompted at exit.

Some of the key drivers which may be enabled in the default configuration are:

• Serial port
• SATA
• Ethernet
• I2C
• Audio
• MMC/SD
• NAND
• PCI Express Root Complex
• PCI Express Boot Driver
• PCI Express EP Driver (mutually exclusive with RC driver)

If you are looking for some particular functionality please double-check that it is enabled in the config options.

Auto detection of Kernel Load Address and Run Time RAM Base Determination

Note: This section is only applicable to 04.01.00.07 DM814x and onwards release of Linux kernel.

By default, the DM814x kernel is built to be loaded at physical address 0x80008000 in RAM and take start of RAM as 0x80000000.

It is possible to load the kernel at a different location in RAM with kernel automatically determining RAM base depending upon the load address.

This is achieved by the combination of two features added the kernel:

1. Run time PHYS_OFFSET determination: This feature enables determining physical to virtual translations dynamically depending upon the position of kernel in system memory.
2. Auto calculation of address for uncompressed kernel: This feature enables the compressed kernel entry code (part of kernel zImage) to determine the address to uncompress the kernel depending upon the location it is loaded (started from).

Subsequent sub-sections assume that you have already downloaded and extracted the kernel snapshot from above mentioned link/page or set up git working directory with latest PSP kernel from repository associated with the above page. It is also assumed that the environment for kernel build is setup and 'mkimage' executable utility from U-Boot is available in the PATH (this utility gets built with U-Boot and available inside 'tools' directory form U-Boot source base).

Configuring the Kernel

Note: The run time physical offset support is treated as EXPERIMENTAL feature currently. The default kernel configurations for DM8148 EVM have this feature enabled in latest source. You can follow steps similar to those described below and build the kernel to enable this support for any custom board as well as to view/disable this feature as per the need.

Generate default config for the Board

For DM8148 EVM:

BUILDHOST$ make ARCH=arm ti8148_evm_defconfig

The above steps should configure the kernel to include run time physical to virtual translation support (CONFIG_ARM_PATCH_PHYS_VIRT=y) and auto detection of load address (CONFIG_AUTO_ZRELADDR=y).

If you desire to view the exact configuration options to be controlled to enable or disable these features, read the next steps.

Enter the configuration menu

BUILDHOST$ make ARCH=arm menuconfig

You will be presented with configuration menu as shown below:

[*] Patch physical to virtual translations at run time (EXPERIMENTAL)
General setup  --->
[*] Enable loadable module support  --->
...
Kernel Features  --->
Boot options  --->

Enable/Disable runtime physical to virtual translation feature
Ensure that the "Patch physical to virtual translations..." option is highlighted and press 'n' key (without quotes) to disable it (the default kernel configuration done in the earlier step had enabled this option).

[ ] Patch physical to virtual translations at runtime (EXPERIMENTAL)
General setup  --->
[*] Enable loadable module support  --->
...

Pressing 'y' on this option will (again) enable it.

Enable/Disable auto calculation of decompressed kernel location
Now navigate to "Boot options --->" option by using DOWN arrow key and press SPACE to enter the sub-menu shown below.

Here, using DOWN ARROW key, navigate to the option "Auto calculation..." and press 'y' to enable or 'n' to disable it. You should see a '*' in the box '[ ]' in front of that option when 'y' is pressed (enable) otherwise the box will be empty (disabled) when 'n' is pressed.

(0) Compressed ROM boot loader base address
(0) Compressed ROM boot loader BSS address
()  Default kernel command string
[ ] Kernel Execute-In-Place from ROM
[ ] Kexec system call (EXPERIMENTAL)
[*] Auto calculation of the decompressed kernel image address

Using RIGHT arrow key, highlight the 'Exit' option on the menu page and press ENTER key subsequently till you are asked to save the configuration. Now ensure that 'Yes' is highlighted and press ENTER again to save and exit the configuration.

Building the Kernel

Use following command to build the kernel:

BUILDHOST$ make ARCH=arm zImage

Notice that we are building the standard zImage (compressed kernel image) instead of usual uImage. This is so because the uImage built as part of kernel build will have the load address and entry point @0x80008000 by default while, in this case we desire to load the kernel at different load address. Hence we build a zImage and then pass the desired address to 'mkimage' to get uImage as shown below.

Here we use 0x90008000 as the kernel load address and entry point.

Note: You can chose any other address as per your requirement and available RAM space but please refer next section Points to Note/Restrictions for various important points and constraints.

Use 'mkimage' to generate uImage. Note that the command is run from the kernel source base after zImage is built successfully.

BUILDHOST$ mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n 'Linux-2.6.37' -d arch/arm/boot/zImage uImage
    Image Name:   Linux-2.6.37
    Created:      Mon Oct 29 21:05:21 2011
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2570504 Bytes = 2510.26 kB = 2.45 MB
    Load Address: 90008000
    Entry Point:  90008000

You can build the zImage once and just execute the 'mkimage' step for different load address requirements with same kernel.

Alternate Method: Single Step Build

You can still achieve the above in single step as part of kernel build by passing zreladdr-y=<desired-load-address> to make when building the uImage.

For example, to build the uImage with load address 0x90008000 considered in earlier case:

BUILDHOST$ make ARCH=arm zreladdr-y=0x90008000 uImage

The above command will build the kernel zImage and then uImage by internally invoking 'mkimage' with the specified load address (passed as zreladdr-y).

Note: In any case, you need to rebuild the uImage for specific load address.

Points to Note/Restrictions

• Load address and entry point parameter passed to 'mkimage' must be same, that is, values passed for '-a' and '-e' must be same.
• The auto address calculation of load address is only possible when using compressed kernel image (zImage) and thus, the uImage must be built from zImage - using uncompressed kernel image (Image) will not support this feature.
• The run time physical RAM base calculation support (called as p2v) adds a string "p2v8" to module version and thus the modules built without p2v support cannot be loaded on the kernel built with p2v support enabled and vice verse. This prevents incompatible modules being loaded mistakenly.
• This feature may not be used with XIP kernels.
• Run time physical offset determination feature is an EXPERIMENTAL feature presently.
• The kernel compressed entry code which determines the address for loading uncompressed kernel considers that the compressed kernel image (zImage) is loaded within first 128MB of the RAM, this also means that the RAM base is determined by masking least significant (LS) 27 bits of the load address.
• There must be at least 32KiB space available *after* the determined RAM base (see above point) and *before* the kernel load address specified when preparing uImage.

Refer Choosing Load Address and Determination of RAM Base section below for details and examples.

Choosing Load Address and Determination of RAM Base

As mentioned earlier, the load address must be chosen such that it leaves at least 32KiB space below it from the RAM base. This is required since the kernel uses this region of RAM below the image to store page tables (in normal execution as well as during decompress).

Also note that since the RAM base is calculated by truncating to the nearest 128MiB boundary (masking LS 27 bits of the load address), the LS bits getting masked need to evaluate to at least 32K offset from the RAM base (that is, 0x8000 minimum).

Following are some examples of correct load addresses (with automatically calculated RAM base) followed by a few incorrect ones:

Correct Load Addresses

Load Address	Calculated RAM Base
0x90008000	0x90000000
0x90010000	0x90000000
0x91000000	0x90000000
0x98100000	0x98000000
0x98104000	0x98000000
0x80008000	0x80000000
0x88100000	0x88000000

Incorrect Load Addresses

Following addresses would result into a non bootable kernel (kernel will hang/halt during boot):

Load Address	Problem Area
0x90000000	Calculated RAM base = 0x90000000 (masking to 0xF8000000), which means the 32KiB requirement for load address is not met
0x98000000	RAM base = 0x98000000, 32KiB requirement not met
0x98004000	RAM base = 0x98000000, only 16KiB available below the load address

Modifying Pin Mux settings

On DM814x devices, the pins are tri-stated and set to Mode 0 or any other mode as required for specific module (e.g., MMC) in U-Boot. If you desire to use a particular pin to any other function than Mode 0 or override any other pin mode which was already set in U-Boot, the kernel needs to be modified and rebuilt.

You can change default mux mode by adding specific mux entry in the beginning of board_mux array in arch/arm/mach-omap2/board-ti8148evm.c or calling omap_mux_init_signal() during initialization (e.g., in device specific initialization function called from omap2_init_devices() in arch/arm/mach-omap2/devices.c).

The names of multiplexed signals are specified in arch/arm/mach-omap2/mux814x.c file in kernel source directory.

EXAMPLE: for setting xref_clk0 pin (mode 0) to usb1_drvvbus (mode 7 or FUNCTION 8), to the board_mux structure in the board file add

TI814X_MUX(XREF_CLK0, OMAP_MUX_MODE7) 

or call

omap_mux_init_signal("xref_clk0.usb1_drvvbus", 0)

Note: The string passed above should be mode0_name.desired_mode_name format.

The API approach is useful if you desire to set the pin-mux run time depending upon the board/hardware detected without need of maintaining separate kernel binaries.

Note: On DM814x devices, the bit positions for pull up/down are different and hence use macros TI814X_PULL_DIS (to disable pull up/down) or TI814X_PULL_UP to select pull up.

Alternatively, you can set particular pins by passing respective pinmux details to kernel command line in following format

omap_mux=<mode0_name>.<signal_name>=<value>,<mode0_name>.<signal_name>=<value>

EXAMPLE: to set mmc1_cmd_mux0 (mode 0) pin to gpio0_0 and enable pull down, append following to kernel command line passed from the boot loader:

omap_mux=mmc1_cmd_mux0.gpio0_0=0

For pull up (set bit 17):

omap_mux=mmc1_cmd_mux0.gpio0_0=0x20000

You can pass configuration for multiple pins separated by comma.

For details about this boot parameter, refer Documentation/kernel-parameters.txt in kernel source directory.

Distinguish between chip revisions run time

Sometimes a kernel module/driver may require to do specific handling depending upon DM814x chip revision. To achieve this, the exported kernel API omap_rev() can be used as shown in following example:

• Ensure that plat/cpu.h file is included in your driver file

#include<plat/cpu.h>

• Use following kind of block to handle specific configuration for chip revisions which or PG 2.0 and onwards:

...
if (omap_rev() != TI8148_REV_ES1_0)
 /* Handle non PG 1.0 device configurations */
else
 /* Do the configuration for PG 1.0 devices */ 
...

You can find all the supported chip revision macros by searching for "TI8148_REV_ES" (without quotes) in arch/arm/plat-omap/include/plat/cpu.h file from kernel source.

Using The Correct Console Device

On the latest kernel packaged in this release, the serial device names are changed from ttySx to ttyOx. Thus, the serial port associated with UART0 is now referred as ttyO0.

• This means you will need to update 'bootargs' as passed to kernel to use ttyS0 as console. For example, change

console=ttyS0,115200n8 

to,

console=ttyO0,115200n8

• The subsequent example 'bootargs' use the new console name and will not work with kernel from older releases.
• Similarly, you will need to update the /etc/inittab file in the filesystem used for kernel by replacing lines with 'ttySx' by 'ttyOx'. For example, replace following

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

by,

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

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

Updating the DHCP Script

The latest (2.6.37-rc3) kernel has changed the entry for root filesystem name as appear in /proc/mounts file. This might impact boot process if some of the init scripts in your filesystem read this entry to determine the root device type.

The existing scripts checking /proc/mounts may not work as intended.

One such case is the /etc/udhcpc.d/50default script in the filesystem, which skips sending DHCP requests if the root device is a network mounted filesystem.

If you face any issue where the filesystem is mounted successfully but hangs after showing udhcpc related prints. The issue is most likely with incompatibility between latest kernel and the udhcpc script.

To fix this, open the /etc/udhcpc.d/50default in your DM81xx filesystem and check if a check like the one shown below exists:

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

Update the above fragment by replacing the check as below:

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

Proceed to use this filesystem with kernel.

Booting Linux Kernel

Kernel along with root filesystem can either be booted from on board storage device or can be fetched over the Ethernet or UART to RAM using TFTP or serial protocols like YMODEM and booted from there. Also, the root filesystem can be formatted as JFFS2 or UBIFS, flashed and mounted. Please refer to the U-Boot User Guide for details about flashing and supported storage devices.

Following sections describe various kernel boot options possible.

• Note: The offsets and MTD partition numbers used in examples below may vary depending upon actual partition layout used on particular storage device. Also, selecting multiple storage device support in kernel (e.g., NAND & SPI) may change the effective partition number to be used as root partition.

Boot from NAND

Make sure the Boot Mode/Configuration Select Switch is set for the NAND boot mode as described in Booting U-Boot section.

Power on EVM and wait for U-Boot prompt of the 2nd stage (TI8148_EVM#) to come up on the serial console.

When kernel uImage and JFFS2 or UBIFS filesystem are flashed on the NAND device:

TI8148_EVM# nand read.i 0x81000000 280000 500000

For JFFS2 file system:
TI8148_EVM# setenv bootargs 'mem=128M console=ttyO0,115200n8 noinitrd root=/dev/mtdblock9 rw rootfstype=jffs2 ip=dhcp'

For UBIFS file system:
TI8148_EVM# setenv bootargs 'console=ttyO0,115200n8 noinitrd mem=256M rw ubi.mtd=9,2048 rootfstype=ubifs 
root=ubi0:rootfs init=/init'


TI8148_EVM# bootm 0x81000000

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

TI8148_EVM# nand read.i 0x81000000 280000 500000
TI8148_EVM# setenv bootargs 'console=ttyO0,115200n8 root=/dev/nfs nfsroot=172.24.179.98:/nfs_root,nolock rw mem=128M'
TI8148_EVM# bootm 0x81000000

Boot from SPI

Make sure the Boot Mode/Configuration Select Switch is set for the SPI boot mode as described in Booting U-Boot section.

Power on EVM and wait for U-Boot prompt of the 2nd stage (TI8148_EVM#) to come up on the serial console.

Assuming kernel image is flashed on the SPI flash @0x42000 and NFS based root filesystem is used:

TI8148_EVM# sf read 0x81000000 0x42000 0x200000
TI8148_EVM# setenv bootargs 'console=ttyO0,115200n8 root=/dev/nfs nfsroot=172.24.179.98:/nfs_root,nolock rw mem=128M'
TI8148_EVM# bootm 0x81000000

Boot from NOR

Make sure the Boot Mode/Configuration Select Switch is set for the NOR boot mode as described in U-Boot User Guide.

Power on EVM and wait for U-Boot to come up on the serial console.

Assuming kernel uImage and JFFS2 filesystem are flashed on the NOR device @0x08060000 (Partition 2) and @0x08460000 (Partition 3) respectively:

TI8168_EVM# cp.w 0x08060000 0x81000000 0x200000
TI8168_EVM# setenv bootargs 'mem=128M console=ttyO2,115200n8 noinitrd root=/dev/mtdblock3 rw rootfstype=jffs2 ip=dhcp'
TI8168_EVM# bootm 0x81000000

Boot over Network (Ethernet)

Note
When setting a MAC address please ensure that the LS-bit of the 1st byte is not 1 i.e. when setting the MAC address: y in xy:ab:cd:ef:gh:jk has to be an even number. For more info this refer to the wiki page http://en.wikipedia.org/wiki/MAC_address

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

• Ensure that the EVM is connected to network with DHCP and TFTP server set up
• Set 'ethaddr' U-Boot environment variable with proper ethernet address in format 'xx:xx:xx:xx:xx:xx' (replace 'xx' with proper hexadecimal values)
• Copy kernel image and ramdisk to TFTP server's root directory.
• Ensure that the "Options Negotiation" box in the tftp server settings is not checked.
• Execute following commands at U-Boot prompt. We assume kernel image name as 'uImage' and ramdisk file name as 'ramdisk.gz'

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

• Alternatively, kernel can be made to use the same IP address as assigned to U-Boot instead of doing DHCP request again by setting U-Boot parameters as follows:

TI8148_EVM# print ethaddr                          <-- Check if MAC address is assigned and is unique
TI8148_EVM# setenv ethaddr <unique-MAC-address>    <-- Set only if not present already, format xn:yy:zz:aa:bb:cc
TI8148_EVM# setenv bootcmd 'dhcp;run addip; tftp 81000000 uImage;bootm'
TI8148_EVM# setenv hostname <unique-hostname>
TI8148_EVM# setenv addip 'setenv bootargs ${bootargs} ip=${ipaddr}:${nfsserver}:${gatewayip}:${netmask}:${hostname}:eth0:off'
TI8148_EVM# setenv autoload no
TI8148_EVM# setenv nfsserver <nfs-server-ip>         <-- Make sure the same NFS server IP is used below
TI8148_EVM# setenv bootargs 'console=ttyO0,115200n8 root=/dev/nfs nfsroot=<nfs-server-ip>:<path-to-nfs-share>,nolock rw mem=128M'
TI8148_EVM# setenv serverip <tftp-server-ip>
TI8148_EVM# saveenv
TI8148_EVM# boot

• After saving the environment variables, you need not set them again on reboot unless a change is required.
• Note that the above example uses NFS mounted root file system accessed over 'eth0' interface (as available on the base EVM)

Note: You need not set 'ethaddr' for devices having valid MAC IDs set. In such cases, U-Boot will automatically detect and set the ethernt address (should show message like "Detected MACID:...").

Power Management

Note: On PG 1.X revisions of DM814X chip, only clock framework is supported, other PM features are not supported

Clock details

H/W Details

DM814x has two on chip oscillators which are the main source of clock, OSC0 - 20 MHz and OSC1(20-30MHz). Centaurus has 13 PLLs, by default OSC0(20 MHz) provides the input clock source for all PLLs.These PLLs are configured to generate higher frequencies required for interface and functional clocks of various modules on the device.Clock out from PLLs is distributed to various modules as per the hardware connections and requirements, with divider at place where lower frequencies are required.

Clock Framework Overview and Usage

For clock framework software implementation, features and usage refer to Clock Framework User Guide

Suspend to Memory

NOTE: Lowest 1 KB(1024 Bytes from the end) of OCMC RAM is used by Suspend code to execute from OCMC when DDR is placed in Self-refresh mode during suspend/resume.This memory area will be over-written by Suspend code when kernel is loaded, during SRAM initialization so drivers should avoid using the lowest 1KB of OCMC RAM

Suspending a system drives the system to a low power state there by saving power as and when desired by the user. For overview of Suspend to memory implementation, features and usage refer to DM814x AM387x Suspend Resume User Guide

GPIO Driver

DM814X has four GPIO modules provides 32 dedicated general-purpose pins with input and output capabilities, total 0 - 127 pins are available for usage.

GPIO Driver User Guide have more details of driver usage

EDMA3 Driver

EDMA Driver User Guide

Audio Driver

The audio driver in the PSP package conforms to the ASoC framework in the Linux kernel. The current driver supports audio capture and playback using the AIC3106 codec on the EVM. For more details on the audio driver refer to the following page:

• Audio Driver User Guide

SATA Driver

The SATA subsystem supports one 3Gbps SATA host port capable of supporting Port Multiplier and direct connect SATA devices.

SATA driver in the Linux kernel has support for

• HDD
• CD/DVD
• Port Multiplier

NOTE: In case of external RAID storage towers (via ahci), the storage tower should be configured using the windows/Linux(x86) tool before connecting it to TI8148 EVM

Features not supported,

• Port Multiplier support has some issues when port 0 of port multiplier is used. Do not use port 0 of PM and connect devices to other ports in PM, OR hotplug devices after Linux is up. These are just workarounds.

Note: Refer SATA FAQ for more information.

USB Driver

The USB subsystem includes two USB(mentor) controller.

• DM81xx-PSP-USB-User-Guide 

Note for DM814X: For EVMs with PG2.1 silicon, there is jumper J22/J23 for usb0/usb1 ports respectively. For usb host mode, short the jumper J22/J23 for usb0/usb1 ports and connect the mini-A to A-receptacle connector to usb0/usb1 port. For device mode operation, J22/J23 shall be left open(do not short) and connect mini-B to standard A plug to usb0/usb1 port of EVM to usb-host/PC. If EVM has micro connector use micro-A to A-receptacle (for host mode) and micro-B to standard-A plug (for device mode).

USB_ID configuration: The USB0-ID/USB1_ID input to DM814X decides the role of usb mode to be either host or device for USB0/USB1 mentor usb controllers. USBx_ID should be floating (open) for device mode and grounded for host mode operations The configuration of USBx_ID pin can be done by

• software control (only supported on DM814X PG1.x revision)

• usb plug type inserted to usb connector (micro/mini-A plug for host mode, micro/mini-B plug for device mode).

• by on board USBx_ID jumper setting to either short/open the ID pin for force host/device mode respectively.

The USBx_ID is always software controlled for DM814X PG1.x silicon. In PG2.0 onwards USBx_ID is configured through either external usb plug type or onboard jumper setting. This configuration is done by chosing appropriate configuration through USBx_ID menuconfig selection. more information refers to USB Configuration page

SD driver

SD Driver supports SD/SDHC/uSD cards. HSMMC peripheral (and driver) has support for 4 data lines at the max operating frequency of 48MHz. HSMMC is a slave DMA peripheral and uses EDMA to move data between SD card and system memory.

Supported Features

• SD
• SDHC
• uSD
• uSDHC

Not supported Features

• PIO mode of operation

Please refer MMC/SD guide for more details.

Ethernet Switch Driver

Ethernet Switch driver follows standard Linux Network Interface Architecture.

Please refer Ethernet Switch User Guide for more details.

VPSS Video Driver

VPSS Video Driver User Guide

VPSS Video Capture driver

VPSS Video Capture Driver User Guide

NOTE: V4L2 capture driver is added in PSP04.00.01.13 for DM816x class of devices and PSP04.01.00.06 for DM814x class of devices.

HDMI Driver

HDMI Driver User Guide

McSPI Driver

Please refer DM81xx_AM38xx_PSP_McSPI_Driver_Guide.pdf in the release package or refer online McSPI Driver Guide.

NOR Flash Support

NOR Porting Guide

Refer to NOR Porting guide for interfacing NOR on various daughter boards to DM81xx.

Board Modification

Following board modifications have to be done in the Catalog board (CATA_x) / Base Board for NOR  to work.

1. catalog board: Replace the resistor R230 in the  with 0-ohm        

       This is required for NOR XIP (Execute in place) to work.

     NOTE:
     Without the above board modifcation(1), NOR boot will not work.

2. DM814X Base board: Remove the resistors R410, R248 (Both values are 22 ohms)

      This is required to access the entire NOR memory. NOR address lines (A22 and A23)  and HDMI lines are shared.

   a) Populating the resistors R410, R248 (Both are 22 ohms) will enable HDMI

   b) removing the resistors will disable the HDMI and enable the NOR address lines.

      By default, resistors R410, R248 are populated and HDMI is enabled. This puts limitation on the size of NOR memory that can be accessed. With HDMI enabled, NOR device lines A22 and A23 cannot be used and hence the maximum addressible memory is 2^22  = 4 MB. Hence, if the entire NOR memory has to be accessed, then the above modification (2) has to be done.
NOTE: HDMI will not work after this modifcation(2).

NOR Driver Guide
Please refer DM81xx_AM38xx_PSP_NOR_Driver_Guide.pdf in the release package or refer online NOR Driver Guide.

PCI Express Root Complex Driver

Please refer the PCIe RC Driver User Guide for particular release in PDF format from the release package. The latest document is available online.

PCI Express Endpoint Boot Driver

Please refer the PCIe Boot Driver User Guide in PDF format from the release package for details about booting DM814x PCIe Endpoint connected to DM814x/DM816x PCIe Root complex using PCIe boot driver (running on RC). The latest document is available online.

PCI Express Endpoint Driver

Please refer the PCIe Endpoint Driver User Guide in PDF format from the release package for details about using this driver on DM814x PCIe Endpoint part of PCIe topology. The latest document is available online.

TouchScreen Driver

Please refer DM81xx_AM38xx_PSP_TouchScreen_Driver_Guide.pdf in the release package or refer online TouchScreen Driver Guide.

Watchdog Timer (WDT)

The following document covers the details regarding the watchdog timer in DM81xx:

Please refer WDT guide.

TILER

TILER driver has dependency on Multimedia. TILER support is disabled in defconfig. TILER driver can be enabled from,

  Device Drivers  ---> 
<*> Multimedia support  ---> 
    <*>   TI TILER support  ---> 
            --- TI TILER support                                  
            (128) Allocation granularity (2^n) (NEW)              
            (4096) Allocation alignment (2^n) (NEW)               
            (40)  Memory limit to cache free pages in MBytes (NEW)
            (1)   Process security (NEW)                          
            (0)   Use SSPtr for id (NEW)                          
            [ ]   Secure TILER build (NEW)                        
            [*]   Expose SSPtr to userspace (NEW)                 
                                                  
                                  

Leave the default values as those are the one's which were validated for this release.

Following features are supported in the current TILER driver,

• Single PAT and run-time memory allocation

Features not supported,

• Dual PAT
• PAT by-pass mode

IOMMU

Please refer DM81xx_AM38xx_PSP_IOMMU_Driver_Guide.pdf in the release package or refer online IOMMU Driver Guide.