Boot Camp Local 20120904 v1

Giving Linux the Boot
This session covers all facets of the Linux boot process from power up to
running a user application beginning with ROM boot loader progressing
through secondary program loader, u-boot, kernel and finishing with userlevel initialization.
2012
Agenda
What you will learn
Overview of the Boot Process
Boot Modes
SPL
U-Boot
Kernel
User Level
Further Reading
What You Will Learn

The elements involved in
booting into a Linux Kernel
RBL Stage (ROM Boot
Loader)
Boot ROM Stage (boot mode
determination)
SD, NAND, NOR, USB,
Ethernet, Serial ......
SPL Stage (Secondary
Program Loader)
Processor initialization
Read in Linux Kernel
Memory Map of boot
process
Kernel Stage - Kernel
Initialization
Init process
Reads in U-Boot
Memory Map after Linux

boots
U-Boot Stage
User login
Go from nothing to Linux OS Environment

To this full OS
The different boot stages create
the Linux OS Stack
Boot process enables the Linux
environment of concurrent user
applications, management of HW
peripherals, common services.
Why are there stages to the

boot process????
Starting with bare silicon
Overview of Any Bootstrap Process

Basic components to any processor boot
Most processors boot through a chained loading method, each step
gains functionality.
Processor POR jumps to reset vector in ROM after reset line is
released
ROM Code initializes and reads persistent external storage source for
bootstrap code into memory (maybe internal or external depends on
ROM)
Processor jumps to load point of read in code, from here its the role of
the bootstrap code to continue to perhaps read in more code to stage
the boot process. Or perhaps this bootstrap code is all that is needed to
start intended operation.
Why are there Boot Stages?

At POR the internal ROM code in the processor knows nothing about
the system it is in. Therefore the processor uses pre-defined methods
on where to find the boot code that can be accessed with a minimal
standard configuration of external interfaces.
The internal RAM is limited in size and due to that only a portion of the
boot process can be read into it. Subsequent stages are enabled from
this partial boot from Internal RAM.
Biggest reason why is due to system configurations that can only be
defined during the application design process such as memory DDR
types and settings.
Linux Boot Process Components

Components of the Linux Boot Process (Stages)
RBL ROM Boot Loader, Contained in the ROM of the Part, minimal
capability to initialize the processor and read in from off chip into
internal RAM the SPL.
SPL Secondary Program Loader, called many different names
depending on processor (UBL,Xloader) but is code of a minimal
configuration specific to the target board that has the capability to setup
the processor to be able to read in the next stage which is U-Boot.
U-boot Enables most of the specific processor functionality for the
target board and end application to configure the part for booting Linux
and to load the kernel image from persistent storage.
Kernal image Final stage of the boot process. Kernel initilization,
MMU enable, Device Initilization, User Init process and finally user level
applications.
4 Stages of the Linux Boot Process

4 Stages to Boot Process ROM, SPL, u-boot, Kernel
1 ROM BL Reads from initialized persistent storage (selected by boot mode)
SPL into internal Ram
2 SPL does additional setup and reads from persistent storage the next stage
u-boot into DDR
3 u-boot continues the processor setup and reads the kernel into DDR
4 Linux boot and initializes user run time environment
Persistent Storage Readable by ROM
Processor
MMC
ROM BL
This particular
scenario is related
to the AM37x
Int. RAM
SPL
u-boot
kernel
Root FS
1
2
SPL
DDR
U-boot
Kernel
This is
discussed
later
4 Stages of the Linux Boot Process - Cont

(stage 1) ROM
(stage 2) UBL/X-loader/U-boot
SPL
(stage 3) U-boot
Boot mode indicates to the

ROM BL the order of boot
modes to try.
ROM BL may indicate to
SPL where it came from.
(stage 4) Kernel
Processor
Boot Mode
Selection
Each stage adds

functionality.
ROM BL
Int. RAM
-Selects which source of SPL

-Only used by the ROM BL
While SPL should use the

same method to find UBoot, U-Boot is free to do
as the user configures. For
simplicity here, we assume
it also uses that mode.
Overview Processor Boot Modes

Boot Modes in TI perspective is strictly related to hardware and about where to read the
next stage in the boot process. This is unrelated to traditional UNIX or Linux runlevels.
Boot Modes supported vary by device so please consult the data sheet. Typical boot
modes are NAND, I2C, MMC, SPI, Serial, Ethernet.
Boot mode pins are read and latched once, typically the pins are muxed with another
interface such as the video display lines, input on start and then output after that.
Each Processor has an app note on this topic
AM335x SYS_BOOT Pin Configuration Selection
Overview Boot Modes

Some processors support Boot Sequences based on the Boot Mode.
This allows the ROM code to handle possible failure modes in case the
primary selected persistent storage is not available. Please refer to the
appropriate Data Sheet and Technical Reference Manual (TRM) for the
part.
AM335x/AM37x/AM35x/AM387x/AM389x (Sequencing supported, good for
sys dev)
AM335x SYS_BOOT Pin Configuration Selection
Persistent Storage based Boot Modes

Booting from persistent storage
This is the most typical workflow.
Exact location and format of each chunk is media and processor specific
ROM BL sets requirements for how SPL looks so it can tell if it's found a
programmed device or not.
Persistent Storage Readable by ROM
Processor
ROM BL
Int. RAM
SPL
DDR
U-boot
Kernel
NAND
SPL
u-boot
kernel
Root FS
MMC
SPL
u-boot
kernel
Root FS
SPI
SPL
u-boot
kernel
Root FS
I2C
SPL
u-boot
kernel
Root FS
Connectivity Based Boot Modes

Booting over Serial Interface
Typically used for initial programming of persistent storage such as NAND or SPI when other
interfaces aren't available or practical.
After loading an SPL that sets up DDR a flash tool could be loaded for programming
NAND, SPI, etc.
In this case the ROM BL will try and initiate a serial download (often X or Y modem based) and if
that succeeds, execute what was downloaded.
SPL continues to read in next stage (u-boot) over the serial interface
u-boot may also continue to load the kernel and root filesystem over serial
Host Machine connected over serial cable
Processor
Flash Tool
ROM BL
Int. RAM
DDR
Flash tool
SPL
U-boot
SPL
u-boot
kernel
Root FS
1
2
Serial Mode can be used to bring up board initially, albeit
turn around time will be long. < 15 minutes for SPL, uboot, kernel and a 10MB root file system.
Kernel
But where in memory did it go?

Processors define a memory map that says where both internal
memory and DDR are mapped to
SPL, U-Boot and the Linux Kernel are all statically linked to start
running at specific locations within this map.
Once running they may relocate themselves elsewhere within DDR (once
initialized).
Different boot modes may require different link addresses.
For more details about the map for a given processor please refer to the
TRM
U-Boot Overview
Monolithic code image
Runs processor in physical or a single address space
Enables clocking, sets up some of the pin mux settings
Reads in Kernel image (uImage)
Jumps to load address pointed to in uImage header
What are environment variables and how are they used
Default environment variables and how they are used
Passes Kernel Command Line to Kernel

ATAGs (Memory, Command Line, etc)
Flattened Device Trees (FTDs) in the future
Debugging capabilities (just mentioning, not used during boot process)
U-Boot Environment Variables

U-boot example default u-boot environment print out (printenv)
U-Boot > printenv
baudrate=115200
bootargs_defaults=setenv bootargs console=${console} ${optargs}
bootcmd=if mmc rescan; then echo SD/MMC found on device ${mmc_dev};if run
loadbootenv; then echo Loaded environment from ${bootenv};run importbootenv;fi;if test -n
$uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;if run mmc_load_uimage; then run
mmc_args;bootm ${kloadaddr};fi;fi;run nand_boot;
bootdelay=3
bootenv=uEnv.txt
bootfile=uImage
console=ttyO0,115200n8
kloadaddr=0x80007fc0
loadaddr=0x82000000
Example printout shows boot arguments and boot command.

Other u-boot environment definitions telling u-boot what persistent storage to read
for the kernel and what parameters that need to be passed to the kernel and where
to load in memory. Advance knowledge is that the user has to know the kernel load
address and where u-boot is loaded, can use the iminfo command after the uimage
is loaded somewhere in memory, besides on top of u-boot
Kernel uImage What is it?

U-boot partial console output
## Booting kernel from Legacy Image at 80007fc0 ...
Image Name: Linux-3.2.0
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3163488 Bytes = 3 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
XIP Kernel Image ... OK
OK
uImage
uImage Header Info
Kernel Image
(Optional
Compression)
Starting kernel ...

Uncompressing Linux... done, booting the kernel.
uImage is a kernel image wrapped with a header that describes

among other things load point entry point and whether the kernel is
compressed of not.
mkimage utility from u-boot is used to make the kernel uImage
during kernel build process
After the boot the kernel message appears on the console u-boot
is no longer used.
Memory Map of Boot Process (AM335x)

Internal RAM
SPL is loaded into internal RAM
0x402f0400
SPL
U-Boot is loaded first into DDR

U-Boot then loads the uImage
from where directed
U-Boot performs a checksum and
then relocates (if required) the
Kernel found in the uImage to the
load address
U-Boot then jumps to the entry
address specified in the uImage
header, linux boot starts at this
point
DDR
0x80000000
0x80007fc0
uImage
0x80008000
0x80100000
Please note the addresses used

here are for reference only and do
not apply to all devices
Kernel
u-boot
Kernel Command Line

Need to define a few required items such as console port and where
the root filesystem is located. Please note the kernel command line in
the box below. The command line is printed out in the first few lines as
the kernel boots.
Linux version 3.2.0 (root@ubuntu) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 Tue Aug 28
18:43:59 PDT 2012
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: am335xevm
Memory policy: ECC disabled, Data cache writeback
AM335X ES1.0 (sgx neon )
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
ip=none
Optional Command Line

Specific peripheral initialization
Kernel Command Line NFS example

NFS boot command line (from below)
console=ttyO0,115200n8
Where to send console output and take user input, external serial terminal hooks up to this port
root=/dev/nfs
What device interface is the root file system mounted on
nfsroot=192.168.1.166:/home/user/ti-sdk-am335x-evm-05.04.01.00/targetNFS
Tells the kernel what external host has the Root FS, requires setup on external host
ip=dhcp
tells kernel method to configure IP addresses and set up the IP routing table. Here the kernel is being to
use DHCP
Linux version 3.2.0 (root@stevenliu-laptop) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 Mon May 28 13:38:48 CST
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: am335xevm
Memory policy: ECC disabled, Data cache writeback
AM335X ES1.0 (sgx neon )
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyO0,115200n8 root=/dev/nfs nfsroot=192.168.1.166:/home/userti-sdk-am335x-evm05.04.01.00/targetNFS,nolock rw ip=dhcp=/dev/nfs rw ip=dhcp
More Info on configuration for NFS can be found here at kernel.org

http://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
10
Overview Kernel Memory Usage

Kernel boot process begins
DDR
0x80000000
Kernel initializes MMU and takes

over DDR. Overwriting anything
previously there such as u-boot.
0x80008000
Kernel
Look at virtual memory layout printed

out by kernel
Linux Mem Mgmt
u-boot
Linux Kernel Start

Performs low level system setup
Initializes the virtual memory used the kernel and applications
Perform Device Initialization, interrupt handler setup, Idle Task and the
scheduler
Calls the init task which sets up user space context
11
Memory Map from User Application Perspective

Linux creates a virtual memory
space for each user application as
it is loaded. Each User Application
loaded sees a map based from a
start address of 0x00000000.
User Apps cannot write to
physical addresses listed in the
data sheet such IO ports, EMIF,
or DDR without causing a
segmentation fault.
To see how much memory is
available in a system type free,
this is total space of allowed for
executable programs, provided
swap space is disabled.
System Memory
0x00000000
0x80008000
0x8059CFFF
0x805DC000
0x80671023
Kernel text
Kernel data
Space being
used by Kernel
in this
configuration
Virtual Memory Map

These are components that make
up a virtual memory map system
CPU/MMU/Memory
All logical address go through an

MMU to be mapped to a physical
address
This allows run time link and load
of an application
Once the processor is running in
a virtual mode, the memory map
can no longer be considered
contiguous
Want to re-iterate the point of not

writing/reading physical addresses
in the data sheet of the part, this will
terminate the application with a
segmentation fault.
Please Note this picture was taken from Wikipedia discussion on virtual memory
http://en.wikipedia.org/wiki/File:MMU_principle.png
12
Linux Virtual Memory (.....Review....)

Linux memory map
Total address range supported by the part is no longer relevant, MMU
creates its own memory map
The actual memory on the board is hidden and managed by the OS virtual
memory manager.
You can use the /dev/mem interface with the devmem2 application to read and write
physical memory addresses.
Some drivers may offer an mmap functionality for their buffers and registers as well.
All apps are compiled to the same starting address

Linux sets up a process for an app so they all load to same address, this is
possible with an MMU that sets up a virtual memory map
Every Application sees the same memory map
Once virtual, the memory can no longer be considered contiguous
meaning a physical addressed DMA cannot be used.
Linux Memory Info Table Dump

Mem Info Table Dump
Board has 256MB on it
Note that the mem total
is less than 256M, this
difference is where the
kernel is stored.
Only usage described
here and not location in
the virtual memory map
Link that describes the components of meminfo
http://www.linuxweblog.com/meminfo
Google meminfo explained
13
System Physical Memory Map

The physical memory map that has
been registered on a platform.
Look at the data sheet for the part and
see how these addresses match up.
AM 335x Example
Has a serial interface (UART 0) starting at
0x44e09000
Has DDR starting at 0x80000000
These are peripherals specific to this particular part.
Read this article about how to use this

memory interface.
http://lwn.net/Articles/102232/
Google iomem linux explained
Kernel Root File System

Kernel Must Have a Root File System defined in the kernel command line
Must be of a certain format in terms of directories contained
Can be sourced from various device interfaces, examples are:
RAM Disk : /dev/ram0
MMC : /dev/mmcblk0p2
HDA : /dev/hda1
NFS : /dev/nfs
Acronyms Explained
HDA The master device on the first ATA channel,
NFS Network File System
MMC This is the MMC/SD interface or Multi-Media Card/Secure Digital
Link to Overview of Linux Root File Systems

http://www.linux-arm.org/LinuxFilesystem/WebHome
14
Linux Init Process

The last step of the Linux Kernel boot process is to call the user space
initilization function init
This is one call of several made by the kernel looking for the user space init function run_init_process("/sbin/init"); (in init/main.c)
Is the first User Space application to run that setups the user environment and
allows user interaction such as login. Below is a ps (process status) dump from
a console, init typically has a PID of 1, first process started.
/etc/inittab is the script that contains instructions for the init process that
sets up and calls other scripts as part of the user space initialization
Sets the run level, this in turn sets which init scripts based on run level
are run
Identifier:RunLevel:Action:Command
Based on sysv5init scheme
Q&A
15
Thank you!
16
ARM based multimedia using GStreamer &

FFmpeg
In this session we will discuss open-source multimedia codecs for ARM
processors, the capability of the NEON coprocessor to accelerate multimedia.
We will also introduce GStreamer, an open-source pipeline-based multimedia
framework, and the FFmpeg codec libs.
LAB: http://processors.wiki.ti.com/index.php/Sitara_Linux_Training
July 2012
Agenda
Overview
Multimedia on Cortex-A8
NEON support in opensource community
Example Applications
SDK codec portfolio
SDK multimedia framework
Gstreamer FFmpeg/Libav
NEON ecosystem
Performance and Benchmark
Software components & dependencies
References
Support
Lab
17
Pre-work check list

Installed and configured VMWare Player v4 or later
Installed Ubuntu 10.04
Installed the latest Sitara Linux SDK and CCSv5
Within the Sitara Linux SDK, ran the setup.sh (to install required host packages)
Using a Sitara EVM, followed the QSG to connect ethernet, serial cables, SD card
and 5V power
Booted the EVM and noticed the Matrix GUI application launcher on the LCD
Pulled the ipaddr of your EVM and ran remote Matrix using a web browser
Brought the USB to Serial cable you confirmed on your setup (preferable)
What you will learn

Features of Cortex-A8 architecture
Advantages of using NEON co-processor in Multimedia applications
NEON benchmarks
ARM Multimedia software stack
GStreamer
Plug-ins to source, parse and sink audio/video data
Codecs
FFmpeg/Libav opensource codecs
NEON optimization in codecs
Labs
Understand GStreamer pipelines
Enable decoding and Parsing elements pipelines
18
ARM Cortex-A8
Key Technology
Additions by
Architecture Generation
Thumb-EE
Execution
Environments:
Improved
memory use
VFPv3
ARM11
NEON
Adv SIMD
Improved
Media and
DSP
Thumb-2
ARM9
TrustZone
ARM10
SIMD
Low Cost
MCU
VFPv2
Thumb-2 Only
Jazelle
V5
V6
V7 A&R
V7 M
Cortex-A8 Features and Benefits
Dual-issue, in-order, superscalar architecture delivering high performance
First implementation of the ARMv7 instruction-set architecture, including the
advanced SIMD media Instructions (NEON)
Advanced dynamic Branch prediction
Integrated, 256 KB unified L2 cache
Dedicated, low-latency, high-BW interface to L1 cache
NEON : 64/128-bit Hybrid SIMD Engine for Multimedia
Supports both Integer and Floating Point SIMD
Enhanced VFPv3 doubles number of double-precision registers and new
instructions to convert between fixed and floating point
Efficient Run Time Compilation Target
Jazelle-RCT: Target for Java. Memory footprint reduced up to 3x
Can also target languages such as Microsoft .NET MSIL, Perl, Python
19
Neon Features and Benefits
Independent HW block to support advanced SIMD instructions
Comprehensive instruction set with support of 8, 16 & 32-bit signed & unsigned
data types
256 byte register file (dual 32x64/16x128 view) with hybrid 32/64/128 bit modes
Large register files enables efficient data handling and minimizes access to
memory, thus enhancing data throughput
Processor can sleep sooner which leads to an overall dynamic power saving
Independent 10-stage pipeline
Dual-issue of limited instruction pairs
Significant code size reduction
Neon Multimedia benchmark
Test Parameters:
Sep 21 2009 snapshot of gstffmpeg.org
Resolution
480x270
Frame Rate
30fps
Audio
44.1KHz
Video Codec
H.264
Audio Codec
AAC
Real silicon measurements on

Omap3 Beagleboard
Benchmarks released by ARM
demonstrating an overall
performance improvement of ~2x
20
NEON support on opensource community

NEON is currently supported in the following Open Source projects
ffmpeg/libav
NEON Video: MPEG-2, MPEG-4 ASP, H.264 (AVC), VC-1, VP3, Theora
NEON Audio: AAC, Vorbis, WMA
x264 Google Summer Of Code 2009
GPL H.264 encoder e.g. for video conferencing
Bluez official Linux Bluetooth protocol stack
NEON sbc audio encoder
Pixman (part of cairo 2D graphics library)
Compositing/alpha blending
X.Org, Mozilla Firefox, fennec, & Webkit browsers
e.g. fbCompositeSolidMask_nx8x0565neon 8xfaster using NEON
Ubuntu 09.04 & 09.10 fully supports NEON
NEON versions of critical shared-libraries
Android NEON optimizations
Skia library, S32A_D565_Opaque 5xfaster using NEON
Available in Google Skia tree since 03-Aug-2009
SDK: ARM multimedia framework

Matrix Application Launcher
ARM
Benchmarks
2D/3D
Pwr/Clk
Browser
Sys Info
WLAN
Qt Embedded
QGLWidget
GStreamer
QWidget
Wifi
FFMPEG
(MPG4, H.264, AAC)
2D Accel
OpenGL ES
BlueZ
FBDEV
V4L2
McSPI
Touch
screen
Ethernet
DSS2
ALSA
USB
MMC/SD
UART
System on Chip
Target Board
21
ARM multimedia framework
Gstreamer
Multimedia processing library
Provides uniform framework across
platforms
Includes parsing & A/V sync support
Modular with flexibility to add new
functionality via plugins
Easy bindings to other frameworks
FFmpeg/Libav
Free audio and video decoder/encoder
code licensed under LGPL (GPL licensed
codecs can be build seperately)
A comprehensive suite of standard
compliant and robust multimedia codecs
Audio, Video, Image, Speech
Codec software package
Codec libraries with standard C
based API
Audio/Video parsers that support
popular multimedia content
Use of SIMD/NEON instructions
Neon will give 1.6x-2.5x performance
on complex video codecs
Application
Layer
gst-launch
Framework
Media Player
GStreamer
NEON optimized gst-Ffmpeg plugin
Plug-ins
Audio &
Speech
Codecs
Kernel
Space
GStreamer software stack

Over 150 plugins available
Plugin
Collection of elements
Elements
Sources, filters, sinks
Bins and Pipelines
Bin is a container for collection of
elements
Pipeline is a top-level bin that allows
scheduling and running of all of the
elements
Pads
Element source / sink connection points
Caps
Capabilities organized by stream type
with a set of properties
Bus
Message interface that allows
asynchronous interaction with an active
pipeline
22
Video
Codecs
FBDev
Image
Codecs
Plugins
ALSA
GStreamer pipeline architecture

queue
sink
file-src
demuxer
src
video-decode
post-processing
sink
sink
src
video-sink
src
sink
Video
src1
src
sink
src2
Audio
audio-decode
queue
sink
src
sink
src
audio-sink
sink
Each elements are connected through src/sink pads

Data is queued until maximum specified buffer limit is reached
Element queue will create a new thread to decouple src/sink processing
Post-processing element
Eg: color conversion may be required to support various display panels
In AMSDK, AV decoders call into opensource libavcodecs via gst-ffmpeg plug-ins
Parsers can be used to cut streams into buffers, they do not modify the data otherwise
FFmpeg/Libav codecs
libavcodec is the code library developed as part of the FFmpeg/Libav project
Supports around 200 audio/video formats
Used by many free and open source media players and encoders
To enable NEON optimization extra compiler flags should be enabled
cflag mfpu should be set to neon
Setting cflag mfloat-abi to softfp enables generation of code using
hardware floating-point instructions
License
FFmpeg libraries include LGPL, GPLv2, GPLv3 and other license based
codecs, enabling GPLv3 codecs subjects the entire framework to GPLv3
license
Sitara SDK enables GPLv2+ codecs
Additional details of legal and license of these codecs can be found on
FFmpeg/libav webpage.
23
NEON ecosystem
Several third parties provide NEON optimized codec solutions
Company
Application
H.264, VC1, MPEG-4
VP6/7, MPEG-4, VC1, H.264, video stabilization
MPEG-4, MPEG-2, H.263, H.264, WMV9, VC1
MPEG-4, H.263, H.264, WMV9, audio
H.264, VC1
TEAMSpirit voice and video
H.264, MPEG-4, H.263, WMV
MobiClip
Video and audio codecs
Multichannel audio processing
MPEG-4
Audio and consulting
For complete list of supported codecs

please contact the respective 3P
GStreamer components & build dependencies
gstreamer: The core package

gst-plugins-base: An essential exemplary set of elements
gst-plugins-good: A set of good-quality plug-ins under LGPL
gst-plugins-ugly: A set of good-quality plug-ins that might have distribution problems
gst-plugins-bad: A set of plug-ins that need more quality
gst-ffmpeg: Plug-in with a set of elements which use libav codec libraries
24
GStreamer: Installed programs

gst-feedback-0.10
generates debug info for GStreamer bug reports
gst-inspect-0.10
prints information about a GStreamer plugin or element
gst-launch-0.10
is a tool that builds and runs basic GStreamer pipelines
gst-typefind-0.10
uses the GStreamer type finding system to determine the relevant GStreamer plugin
to parse or decode a file
gst-xmlinspect-0.10
prints information about a GStreamer plugin or element in XML document format
gst-xmllaunch-0.10
is used to build and run a basic GStreamer pipeline, loading it from an XML
description
SDK example application

SDK Codec Portfolio
gst-launch is used to construct
multimedia pipelines to
demonstrate ARM based
audio/video decoding examples
Video
MPEG-4
MPEG-2
H.264
Audio
AAC
Video clips are displayed in default
LCD resolution or in 480p when
DVI out is enabled
GStreamer elements such as
qtdemux are used for demuxing
AV content
25
Example applications
MPEG-2 Decode
MPEG-4 Decode
H.264 Decode
AAC Decode
MPEG-4 + AAC Decode
Mpeg4 + AAC decode pipeline

Pipeline:
gst-launch-0.10 filesrc location=$filename ! qtdemux name=demux demux.audio_00 ! faad !
alsasink sync=false demux.video_00 ! queue ! ffdec_mpeg4 ! ffmpegcolorspace ! fbdevsink
device=/dev/fb0
Src pad of each element links to the sink pad on the other element
Buffers flow between pads of the elements
Each element has a list of pad structures for each of their input (sink) or output (src)
Process of caps negotiation is used to configure each element to stream a particular media format
over their pads
Requirements for media format negotiation differs in each element
Source Element: filesrc
No sink pads that generates content for the next element
Reads from file and presents data on its source pad
Demuxer: Qtdemux
Demuxer element used to timestamp raw, unparsed data into elementary audio and video streams:
AAC header for audio and mpeg4 header for video
Creates output pad for the elementary stream
Set caps for audio/video stream
Has fixed caps since data type is embedded in the data stream
Supports push and pull-based scheduling, depending on the capabilities of the upstream elements
26

Queue
Creates a new thread on the source pad to decouple the processing on sink and source
pad.
Decoder: Faad/ffdec_mpeg4
Decodes header and data coming in through the sink pad
Typically each decoder can output data in different formats
List of supported formats can be viewed using gst-inspect
Downstream elements are notified of new caps only when data passes through their pad
Negotiation
Fixed caps
Having fixed caps on source pad restricts re-negotiation
While demuxers typically have fixed caps some decoders could also have fixed
caps on a pad
Fixed cap is a set-up property of a pad, called when creating a pad
Non-fixed caps
Involves downstream negotiation, format is set on a source pad to configure
output format
Allows re-negotiation since format is configured on the sinkpad caps or multiple
formats are supported

Filters: ffmpegcolorspace
Handles state changes
Inspects buffer data, by default sets same format on source and sink
Capsfilter could be used to restrict the data format
Sink Element: alsasink/fbdevsink/v4l2sink
Critical element which handles preroll- manages state change from pause to play
27
Performance and benchmark

%MEM
VGA 480p
CPU
WQVGA
480p
WVGA
WQVGA
480p WVGA
Frequency %MEM
%MEM
%CPU %CPU %CPU
%CPU %CPU %CPU
Audio/Video Codec
MPEG4 + AAC
WQVGA Clip: HistoryOfTIAV-WQVGA.mp4
480p Clip: HistoryOfTIAV-480p.mp4
720M
600M
500M
WVGA Clip: HistoryOfTIAV-WVGA.mp4
275M
95
NA
NA
96
NA
NA
MPEG4
WQVGA Clip: HistoryOfTI-WQVGA.m4v
720M
600M
42
45
88
98
71
78
42
46
76
88
60
69
480p Clip: HistoryOfTI-480p.m4v
500M
55
97
88
53
97
79
WVGA Clip: HistoryOfTI-WVGA.m4v
275M
88
96
95
87
96
96
MPEG2
WQVGA Clip: HistoryOfTI-WQVGA.m2v
480p Clip: HistoryOfTI-480p.m2v
720M
600M
500M
43
46
54
77
84
95
93
98
97
41
47
54
66
75
86
80
89
97
WVGA Clip: HistoryOfTI-WVGA.m2v
275M
85
96
96
84
96
96
H.264
WQVGA Clip: HistoryOfTI-WQVGA.264
480p Clip: HistoryOfTI-480p.264
720M
600M
500M
62
73
81
98
98
97
98
97
97
63
70
79
98
98
98
98
98
97
WVGA Clip: HistoryOfTI-WVGA.264
275M
95
96
92
96
98
93
720M
600M
500M
275M
9
2
3
26
AAC
22
16
16
16
10
44
52
58
86
98
97
91
97
97
Same Same
as VGA as VGA
22
15
15
16
10
41
49
61
73
88
97
80
87
96
2
4
2
25
Same Same
as VGA as VGA
Power benchmark
Total processor power is measured for the following peripherals
MPU set to OPP 300MHz, Core, on-chip SRAM, LDO, DPLL, DDR & Flash (POP)
Power measurement set-up
Default power consumption with Dynamic power switching
(DPS) enabled
With sleep_while_idle and enable_off_mode features
enabled
With Matrix GUI enabled
With sleep_while_idle and enable_off_mode features
enabled
Matrix GUI enabled
MPEG-4 decode running
Total power
[mW]
252.87
329.22
Dynamic voltage frequency scaling (DVFS) can be enabled to scale power values at runtime depending on system-level requirements.
scaling_governor is set to ondemand
Power consumption can be further optimized disabling clocks of unused modules.
Additional details of power optimization can be obtained from power management
guide and PSP user guide for 2.6.37 kernel
28
Profiling
Oprofile, a common
Linux profiling tool is
used
Uses hardware
performance counters
of CPU for profiling
hardware and
software interrupt
handlers
kernel modules
Kernel
shared libraries
Applications
Table depicts profiling
results for MPEG4
decode at 300MHz and
1GHz using video pipe
for display
300MHz
1GHz
samples|
%| app name
samples|
%| app name
------------------------------------------------------------ --------------------------------------------------------4968 89.2562 vmlinux-2.6.37
2294 61.1082 vmlinux-2.6.37
311 5.5875 libgstffmpeg.so
894 23.8146 libgstffmpeg.so
120 2.1559 libgstffmpegcolorspace.so
215 5.7272 libc-2.9.so
95 1.7068 libc-2.9.so
164 4.3687 libgstffmpegcolorspace.so
19 0.3414 libgobject-2.0.so.0.2400.1
45 1.1987 libgstreamer-0.10.so.0.26.0
18 0.3234 libgstreamer-0.10.so.0.26.0
34 0.9057 libglib-2.0.so.0.2400.1
14 0.2515 libglib-2.0.so.0.2400.1
33 0.8791 libgobject-2.0.so.0.2400.1
7 0.1258 libgstbase-0.10.so.0.26.0
28 0.7459 libgstmpeg4videoparse.so
5 0.0898 libgstmpeg4videoparse.so
16 0.4262 libpthread-2.9.so
4 0.0719 ld-2.9.so
13 0.3463 libgstbase-0.10.so.0.26.0
2 0.0359 busybox
9 0.2397 ld-2.9.so
2 0.0359 libpthread-2.9.so
6 0.1598 busybox
1 0.0180 libgthread-2.0.so.0.2400.1
1 0.0266 libm-2.9.so
1 0.0266 libgstcoreelements.so
1 0.0266 libgstvideo4linux2.so
Support
GStreamer
http://gstreamer.freedesktop.org/
FFmpeg/libav
29
Linux Power Management Overview

In this session you will learn how to improve product power performance by
minimizing power consumption and guaranteeing system performance. In
addition, power management techniques enabled via the Linux SDK will be
discussed.
Sep 2012
Agenda
What You Will Learn
Motivation for PM
Overview of Power Management Techniques
Understanding PM Features in the AMSDK
All of the above focused on AM335x.
30
Pre-work Check List

Using a Sitara EVM, followed the QSG to connect ethernet, serial cables, SD card
and 5V power
What you will learn

GOAL: Improve product power performance
Minimize power consumption
Guarantee system performance
Motivation for power management techniques

Understand power management techniques of AM335x system
DVFS: Dynamic Voltage and Frequency Scaling
SmartReflex (aka AVS: Adaptive Voltage Scaling)
Dynamic Power Switching (DPS)
Implemented by Linuxs Runtime PM Framework
Static Leakage Management (SLM)

Device Idle and Standby modes
Basic PM hardware architecture:
Voltage domains, Power domains, Clock domains
31
Why power management?
TI Customers
End Users
Competitive differentiator
Less heat dissipation
Smaller, sleeker products with smaller battery
Longer battery life
Better Features + Increased Usage = Increased Revenue
Quicker time-to-marked with advanced features
Smaller, sleeker products

Cooler device
More exciting, power hungry features like multimedia,
streaming video, etc.
Improved experience (longer battery life)
Lower cost
Power Management Principles

1) Power consumed is proportional to frequency and square of voltage.
Small reductions in voltage can be very significant

Applicable PM Techniques:
Dynamic Voltage and Frequency Scaling (DVFS)

SmartReflex (aka Adaptive Voltage Scaling or AVS)
2) Keeping devices powered on consumes a lot of power. Cut or reduce

power to entire device or idle device portions.
Applicable PM Techniques:
Dynamic Power Switching (DPS)

Turn off what youre not using!
At a granular, per-module level
Called Runtime PM in Linux
Static Leakage Management (SLM)
System level idle and/or suspend
32
Power Management Principles (cont.)

3) For proper operation, you should run at one of the recommended
operating voltage and frequency combinations (OPPs)
Too low voltages can result in data propagation errors and system failure
Too high voltages result in excessive power consumption
Hardware timing closure results in a few PROVEN operating performance
points (OPPs) which guarantee the system to work properly.
Power Management Techniques: Basics

PM Techniques can be categorized as Active or Idle:
Adaptive
Voltage
Scaling
Dynamic
Power
Switching
AVS
SLM
Static
Leakage
Management
Active PM
Technique
Performed while device is on and in use.

Involves all systems components: HW
modules, device drivers, OS & apps.
Techniques: AVS (SmartReflex), DPS &
DVFS.
DPS
Idle PM
Technique
DVFS
Dynamic
Voltage &
Frequency
Scaling
Entire device is idled. Various idle

states selected based on trade-off of
power consumption and wakeup
latency.
Techniques: SLM
Power
Management is centralized and is handled by the PRCM (Power,

Reset and Clock Management) module.
33
PM Architecture Basics
Devices are partitioned into the following architectural
blocks:
Clock Domain:
One or more modules fed with the same clock

Clock has independent gating control
Voltage
Control
Voltage
Regulator
Power Domain:
VDD
One or more modules fed with the same power rail

Power rail controlled by independent power switches
Voltage Domain
Group of modules supplied by the same voltage regulator

(embedded or external)
VDDn sometimes referred to in documentation as a power
rail
Domains hierarchy is generally:
CLK
Clock
Domain 1
Clock
Domain 2
Power Domain
Voltage domains contain one or more Power Domain

Power domains contain one or more Clock Domain
Voltage Domain VDD
Control of this infrastructure is done by the Power Reset

and Clock Manager (PRCM), which is split in two entities:
PRM: Handles voltage, power, reset, wake-up management,
system clock source control and clock generation
CM: Handles the clock generation, distribution and
management
AM335x Power Domains Overview

Refer to Ch. 8 of the TRM for more information:
Power Supply
Power Domain
Modules
VDD_CORE
PD_WKUP
PRCM, Control Module, GPIO0,

DMTIMER0, DMTIMER1, UART0, I2C0,
TSC, WDT1, SmartReflex, L4_WKUP,
DDR_PHY
VDD_CORE
PD_PER
EMIF4, EDMA, GPMC, OCMC, PRUSS,

LCD controller, CPSW, USB, MMC0..2,
DMTIMER2..7, Uart1..5, SPI0..1, I2C1..2,
DCAN0..1, McASP0..1,ePWM0..2,
eCAP0..2, eQeP0..1,GPIO1..3,ELM
VDD_CORE
PD_GFX
SGX530
VDD_MPU
PD_MPU
CPU, L1, L2 of MPU
VDD_RTC
PD_RTC
RTC
34
Dynamic Voltage and

Frequency Scaling (DVFS)
Active PM
Technique
Technique used to scale operating frequency and voltage of hardware

Well-characterized Operating Performance Points (OPPs) defined for each
device
OPP specified as pair: (MPU FREQUENCY, VOLTAGE (for weak silicon))

Indicates minimum voltage at which ALL devices can meet that frequency requirement
For each OPP, software sends control signals to external regulators (DC/DC converters) to set the
minimum voltage required.
The OS monitors the workload and can dynamically adapt voltage/frequency when using certain
governor policies (ondemand).
DVFS applicability:
AM335x: VDD_MPU and VDD_CORE
Software Support:
OPP can be statically selected by the user via Matrix, or at the Linux command line.
Only if governor is userspace!
The CPUFreq driver in Linux supports multiple governors.
Governors implement different policies for dynamically managing OPP selection.

powersave governor: selects the lowest possible frequency
performance governor: selects the highest possible frequency.
Dynamic Voltage and Frequency Scaling (DVFS)

These charts show the defined OPPs for current devices:
Active PM
Technique
35
Adaptive Voltage Scaling

SmartReflex (trademark of
Texas Instruments)
Active PM
Technique
Green line: hot device

Blue line: cold device
Silicon manufacturing process

yields a distribution of
performance capability
For a given frequency
requirement:
Hot/strong/fast devices can meet
this at a lower voltage
Cold/weak/slow devices needs
higher voltage
Simple system will set the higher

voltage for operating all devices
Smarter system will adapt
operating voltage per device!
SmartReflex Classes
Class-0: Manufacturing Test Calibration
At manufacturing test, the device-optimized operating point voltages are permanently fused into
each die. A one time optimization to account for process variations.
Class-1: Boot-Time Software Calibration
At boot-up time, device-optimized operating point voltages of the die are determined during
calibration. Optimization also accounts for process variations.
Class-2: Continuous Software Calibration (AM335x uses Class-2B)
SmartReflex sub-chip does real-time voltage optimization via software loop
Optimizes for process, temperature and silicon degradation effects
Variants:
Class-2A: Timer interrupt or other system event (e.g. frequency change) used to initiate interrogation of
SmartReflex sub-chip
Class-2B: SmartReflex sub-chip generates a host CPU interrupt when frequency is outside acceptable
range
Key: Software intervention required
Class-3 (AM37x): Continuous Hardware Calibration

SmartReflex sub-chip has a dedicated hardware loop to dynamically optimize voltage for process,
temperature and silicon degradation effects
MPU intervention not required SmartReflex sub-chip communicates any required voltage
change directly to the PMIC via a hardware interface (e.g. i2c)
Optimizes for process, temperature and silicon degradation effects
Key: No Software intervention required
Class-4: Fully Integrated Solution
Class 3 hardware control loop plus voltage regulator integrated on single die
36
DVFS vs AVS
DVFS:
125
OPP
1
OPP
2
OPP
3
Best case
100
Worst case
Performance
Select OPP from available

OPPs based on MIPS
requirement in scenario
Lower frequency
requirement -> lower
voltage
All die treated the same for
a particular application
scenario
75
50
SmartReflex
SmartReflex
25
0.9
1.1
Voltage
1.2
1.3
1.4
AVS (SmartReflex)
After selection of OPP, scale

voltage based on device-specific
properties (process capability,
temperature)
Faster (also stronger/warmer)
process -> lower voltage
Each die treated differently
Dynamic Power Switching
Active PM
Technique
Allows certain modules to idle when not being used.
Example use cases: during MP3 playback, we could idle CPSW (among others)
These modules operate in a high performance state to complete its tasks as

fast as possible, then dynamically switch to a low-power state (retention or off
state)
Context save/restore may be necessary if memory is lost additional overhead
Acceptable wakeup latencies on the order of microseconds
Software support: In Linux, handled by the Runtime PM framework. This is

driver-local suspend/resume, managed entirely by individual device drivers
operation independently. Drivers can relinquish clocks, resulting in portions of
the device in a clock stop state.
Overhead
Without DPS
With DPS
1
Normalized
Power
Power
0.1
Execution
Time
Execution
Time
1
37
Static Leakage Management
Idle PM
Technique
Device switches into low-power system modes automatically or under

user requests when no application is running
Example: Media player shuts off display and enters standby after 10seconds of on-time with no processing and no user input
Typically whole device is in some sort of standby mode
Acceptable latencies on the order of milliseconds. Deeper sleep state ==
longer wakeup latency.
Devices have multiple sleep states (or C-states)

AM335x supports two C-states
C1 MPU WFI
C2 MPU WFI + DDR Self Refresh (lowest power)
Software support:
CPUIdle algorithm automatically chooses from available sleep states based upon
the inactivity period and current HW state. Useful for power savings during shorter
periods of inactivity.
Suspend/Resume support available for long inactivity periods (Deep sleep state)
DPS vs. SLM Review

DPS
Active PM
Technique
SLM
Idle PM
Technique
Section of the device in low power mode
Entire device in low power mode (except

WKUP domain)
Some parts of system stay active
Full system is inactive
Smaller transition latencies (us)
Larger transition latencies (ms)
Use case :
Audio/video Playback - Some domains are
going into an idle mode when not needed
Use case:
OS idle: Drop into lower-power C-states
Suspend-to-RAM: lowest power case
38
U-Boot & Linux Kernel Board Port

In this session we will cover fundamentals necessary to port a TI Linux-based
EVM platform to a custom target platform. We will introduce the necessary
steps needed to port the following components: secondary program loader, uboot and Linux kernel.
LABS:
http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_UBoot_Board_Port
http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_Linux_Board_Port
July 2012
39
Pre-work Check List

Using a Sitara EVM, followed the QSG to connect ethernet, serial cables, SD card and
5V power
Agenda
Board Port Overview
Porting U-Boot to an AM335x Target
U-Boot Board Port Labs
Porting the Linux Kernel to a AM335x Target
Linux Kernel Board Port Labs
40
BOARD PORT OVERVIEW
Presentation Overview
Goal is to gain an understanding of the components of a board port for
both U-Boot and Linux
The board or target portion is the last part of a three step method
(Architecture/SOC/Target Board)
Explain how the SDK will support board ports going forward
41
Linux Board Background Assumptions

Already Familiar with :
SPL/U-Boot/Linux ()
SPL/U-Boot/Linux boot sequence
U-Boot/Linux build process (kernel configuration)
Minicom setup
Root File Systems
Very limited time,

Really only have time to show the tip of the iceberg, not going to all inclusive or
discuss every facet of board porting, this is a starting place
well have to take extended question/answer after the class in the foyer or later
over email. (or in the bar. You buy )
This information is good for today only always in flux..

Whats presented here today may not be the only way of implementation
Standard disclaimer of You can and should use what others have done as
a method on what to do to move forward
Things not covered today..

Not covering all of the board port steps
Limited time today, so we will just be focusing on the code portion of the
port
Directory setup
Machine ID discussion
Makefile modifications
Git Setup
Other Processors
42
Linux Board Port Workshop Agenda

The Mission: Sowhats a board port?
Look at the System Block Diagram of the target board being used
Stages of a port
Pin Mux Utility Tool Overview
U-Boot Port
source tree
introduce the target board file
Perform two labs that use an already ported example (the code added by with
each lab will be discussed )
Linux Kernel Port

source tree
introduce the target board file
Perform four labs that use an already ported example (the source additions for
each lab will be discussed)
The Mission
Good Morning the AM335x has been chosen as the processor for
your new exciting market cornering product. Your job (no choice but to
accept it ) is to get U-Boot and the Linux kernel running on this new
platform as soon as possible.
To accomplish this you will take the board design from your HW team and
use the AM335x EVM and accompanying Sitara Linux SDK and port UBoot and the Linux kernel to your new Hardware.
43
So.Whats a board port?

It is taking the Sitara Linux SDK that is working on a known platform
and moving it to a new target platform that is based on the same TI
AM335x processor
Target Board for this Exercise. Beagle

Bone
44
Target Board Port Configuration Example
Will be adding an LCD to the system..
45
Board Port. Tip of the iceberg
Used to show the balance of work necessary
Architecture vs. SOC vs. Board Porting
46
A Tale of Two Board Files
Both U-boot and Linux follow a similar board file abstraction approach
The Core Architecture is ported first
The SOC supporting functions are ported next
The last part to tie U-Boot/Kernel to the target is the Board file that
defines well known initialization or entry functions that U-Boot and the
Linux Kernel will call to handle a priori type board knowledge
Where the U-boot and Kernel Sources are after

TI-SDK-AM335x-05.05.00.00 installation
Both the U-Boot and the Linux Kernel Sources are found in the installed
TI-SDK-AM335x-05.04.01.00 directory
ti-sdk-am335x-05.05.00.00/
ti-sdk-am335x-05.05.00.00/board-support/
ti-sdk-am335x-05.05.00.00/board-support/u-boot-2011.09-psp04.06.00.08/
ti-sdk-am335x-05.05.00.00/board-support/linux-3.2-psp04.06.00.08.sdk/
Later in the presentation you will see references to just the specific subtree that has the respective source such as U-Boot or Linux
47
Pin Mux
Utility
GPIO Signals are muxed with peripheral interfaces. These can be

configured into one of several modes either supporting the peripheral or
remaining in a GPIO mode.
Selecting a mode using Pin Mux Utility

Each Pin has a mode selection, using UART0 as an example here
UART0 RXD Mode 0 is selected and GPIO 1.9 is de-selected
UART0 RXD Mode 0 is selected and GPIO 1.9 is de-selected, notice

Pad config changed too.
Utlitity helps find conflicts, two pins are simultaneously selected
Each Pin has a mode selection, using UART0 as an example here
Pin Mux Utility User Guide

http://processors.wiki.ti.com/index.php/Pin_Mux_Utility_for_ARM_MPU_Processors
48
PORTING U-BOOT TO AN
AM335X TARGET
U-Boot Port Agenda

Introduce the board file, where it fits in the Port Picture, where it is in
the source tree
What is the anatomy of the board file
Introduce the Board File Template that can be used to port u-boot
Labs Introduction
49
U-Boot Board Port Exercises and Source

Links
Link to the U-Boot Labs
http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_UBoot_Board
_Port
Link to the U-Boot Template Source tree (clone this tree)

git://gitorious.org/sitara-board-port/sitara-board-port-uboot.git
PSP U-boot Repo

http://arago-project.org/git/projects/?p=u-boot-am33x.git;a=summary
SPL and U-Boot Builds

Dude. Wheres my X-Loader?
It has left the building. Been replaced by SPL
The same code base is used to build U-Boot (u-boot.img) and the SPL
(still called MLO). Since the same code base is used pre-processor
flags are used to isolate the code between the two builds. For example,
you do not want the DDR and MPU clock init code in both builds. Also
of merit is that one build yields both images.
Below are examples of the pre-processor flags used:

#ifdef CONFIG_SPL_BUILD
#ifndef CONFIG_SPL_BUILD
50
U-Boot Source Directory

Using the existing
am335x source
directory
The developer will be
concentrating on one
source directory and
for the most part one
include directory
U-Boot Anatomy of a board

File
Defines Required interface functions for SPL
and U-Boot
One source file contains the code for both
SPL and U-Boot and are separated by preprocessor flags
SPL handles the initialization of clocks,
DDR, Serial Port and PMIC
Some functions are defined twice in both an
SPL context and then again in a U-Boot
context (s_init & board_init)
The board file is where the developer will
spend most of their effort for a port
51
U-Boot/SPL Board Template File

The board file (evm.c) used here today is
different from the one provided in the SDK
Contains the code for both SPL and U-Boot
This Board Template only enables MPU
Clock, DDR and the Serial Port
Its up to developer to decide how much
functionality they choose to put into the
board file and hence the u-boot.img. If the
target board supports more peripherals but
only one or two is needed to boot into the
kernel why add that code?
U-BOOT BOARD PORT LABS
52
Board Port Labs

Lab 1
Introduce the template board file and how SPL and u-boot.img are built
Lab 2
Build on the template file demonstrating how to add the MMC and Ethernet
peripherals
Board Port Source Tree being used

Currently Source is derived
from AM-SDK-05.05.00.00,
the Port Tree will follow or
track each SDK release
A git tree has been setup
for these labs on the host
machines
Using existing board file
name and build methods
Using the default U-Boot
configuration supplied with
the SDK
53
U-Boot Board Port Exercise 1 - Overview

Goal : Introduce workshop attendees to a board template file that can
be used later for a U-Boot Board port
How this is Demonstrated
Build both an SPL and u-boot.img using provided AM335x board template
file, which has:
Base processor configuration for u-boot, ddr, clocks and a serial console are
initialized
What is being done:

Examine the board file to see what is being initialized
Perform the Lab
First Burning Question:
SO WHERE ARE THE DDR

TIMINGS AND THE CLOCK SET?
54
First Burning Question: So where are the

DDR timings and the clock set? DDR First
DDR Setup requires portions of 4 functional
blocks to be setup. (Block Diagram)
EMIF , CMD, DATA and EMIF0 CLK are
dependent on Memory selected
First Burning Question: So where are

the clock and DDR timings set? DDR First
The DDR is set up within the SPL context

enable_ddr_clocks in pll.c,
ddr_defs.h and cpu.h
55
Here is link to a Tool that can be used to

generate necessary values to configure DDR
Spread Sheet Tool can be found here
http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips
The SPL entry function

s_init is called from
lowlevel_init.S to setup
system PLL, RTC, UART,
timer and finally
configures DDR
56
And now to Set the MPU Clock Rate.

SPL Context Function
Before setting the MPU
PLL the voltage and
current are increased
using I2C commands to
the tps65217.
Called from
arch/arm/cpu/armv7/start.S
If you have a different PMIC you will
most likely need a different code
base than what is shown here
Board File Template for u-boot.img

Within the u-boot context this is
the entry function
Same source file as used for SPL
Pin Mux config is setup for i2c,
uart (already done in SPL) and
57
DO LAB 1.
U-Boot Board Port Exercise 2 - Overview

Goal : Take the board template file (evm.c) and add both MMC and
Ethernet support
Using the supplied git tree checkout a Ethernet tagged branch, this has both
the MMC and Ethernet support code. Build the kernel.
This adds Pin Mux support for both Ethernet and MMC
Adds the init functions for Ethernet and MMC.
What is being done:

Examine the code changes necessary to implement Ethernet and MMC
Perform the Lab
58
Steps to adding MMC and Ethernet to the

target board file
Review system info to see how peripheral is attached
Pin Mux
Use the Pin Mux Utility to configure Pin Init data
Create Device Init function

If device is supported in U-Boot, set the desired include in include/configs
Add Device Init Function to board file
Pin Mux Utility

Pin Mux tool capture for MII
interface
While the tool shows GMII
this is the MII interface, doc
bug in tool
59
Adding MMC to the U-Boot Board file

Find the pre-processor flags in the am335x_evm.h
config file that control inclusion of MMC
Use the name found for a weak alias to define in
the board file
Create the init function in the board file
Adding Ethernet to the U-Boot Board File

Use the name found for a weak alias to define in the board file, in net/eth.c
Create the init functions in the board file
2 functions are created one to init the phy (local) and the board_eth_init
definition for u-boot network driver to call
There are additional supporting structures define in the board file
60
git diff Code Difference between

template and mmc commit
git tag is used to list tags on the
git tree
git diff this is used to isolate
code between git commits.
Do not be
concerned
about knowing
git at this
point, here we
are using this
for illustration
purposes.
git diff Code Difference between mmc

and ethernet commit
git diff commands
goes across several
screens
Type q to quit
command at any
point
Note the plus sign
on the edge of the
diagram, code
addition
61

and ethernet commit (cont)
Code continuation for Ethernet
PHY setup
This code was extracted from
Beagle Bone specific code from
the SDK release.

setup
the SDK release.
62

setup
the SDK release.
How is board_eth_init(..) called?
DO LAB 2.
63
U-Boot Board Port Summary

Introduced a board port template file with a minimal feature set.
Discussed the components in this file. This file could be used for actual
board ports.
Performed two labs demonstrating the template file in action.
PORTING THE LINUX KERNEL

TO AN AM335X TARGET
64
Linux Port Agenda

What are the different stages of a Port
Introduce the board file, where it fits in the Port Picture, where it is in
the source tree
Discuss the OMAP2+ Machine Shared Common Code
Labs Introduction
Linux Board Port Exercises and Source

Links
Link to the U-Boot Labs
http://processors.wiki.ti.com/index.php/Sitara_Linux_Training:_Linux_Board
_Port
Link to the Linux Template Source tree (clone this tree)

git://gitorious.org/sitara-board-port/sitara-board-port-linux.git
PSP Linux Kernel Repo

http://arago-project.org/git/projects/?p=linux-am33x.git;a=summary
65
Linux Kernel Overview

(AHHHHH. The Kernel)
A very complex and
overwhelming kernel
block diagram, this is
just to make you aware
of whats below the
waterline..
With a target port the
architecture and SOC
port has already been
done. Therefore, the
majority of this block
diagram has been
taken care of for the
target port developer.
Source is:
http://en.wikipedia.org/wiki/File:Linux_kernel_map.png
Architecture vs. SOC vs. Board Porting
Board Developers
only need to be
looking at the last
phase which is
board porting, all
the architecture
and SOC port
support has been
done.
66
The Target Port Starts with a

Board File
Defines the Machine Name
Declares Initialization Data for Peripherals being
used
Declare Pin Mux initialization Data
Defines Initialization functions
Provides required Machine Initialization functions
Calls Common Initialization functions
Summary is that this file defines several required
elements required to boot a Linux kernel, one of
several bricks in the wall so to speak.
Linux Kernel Source Tree Overview

(Where is the Board file.)
The board file is located in a source directory
called arch/arm/mach-omap2/ where all other
board files are located of the same machine type.
67
How the Board File fits in the stack

Board Developer will spend
most of their time in the Board
file.
The Board file makes use of the
machine shared common code
The underlying port to the ARM
Architecture Shared common
code is already done and does
not need to be looked at
Finally everything rests on the
Linux Kernel Shared Common
Code.
The lower in the stack you go the less direct interaction the board
developer will or need to have.
OMAP2+ Machine Shared Common Code

There are several board files in the mach-omap2 directory. These
board files typical use the support functions defined within this
directory. Below is a sampling of some of the supporting common code,
not all are mentioned here.
68
OMAP2+ Machine Shared Common Code

Provided as means to provide a common interface to the SOC
peripherals to reduce the time necessary to implement a board port
This interface is not always a clear dividing between maintainers and
board developers.
This is not a documented interface and due to the changing nature of
the Linux kernel will almost always be in flux. Maintainers in the end
have the authority to accept reject code for their particular tree.
LINUX BOARD PORT LABS
69
Board Port Labs

Lab 1
Introduce the template board file
Lab 2
Build on the template file demonstrating how to add the MMC peripheral to
provide a Root file system
Lab 3
Build onto template file again this time adding Ethernet for network
connectivity
Lab 4
Demonstrate how to add an LCD panel to the board file
Board Port Source Tree being used

Currently Source is derived from AMSDK-05.04.01.00, the Port Tree will
follow or track each SDK release
A git tree has been setup for these labs
on the host machines
Using existing board file name and build
methods
Using the default kernel configuration
supplied with the SDK
70
Linux Board Port Exercise 1 - Overview

Goal : Introduce workshop attendees to a board template file that can
be used later for a Linux board port
Build a kernel using provided AM335x board template file, which has:
Base processor configuration for Linux, just serial console peripheral is initialized
This board will not completely boot no peripheral is defined for a Root File
System
What is being done:

Examine the board file to see what is being initialized
Perform the Lab
Template Board File

Anatomy
Binds Linux to a particular target
Interfaces with the OMAP2+
Machine Shared Common Code.
Defines pin mux configuration
The file contains device
initialization functions and data.
Defines the Machine ID and
identifies to the Linux Kernel
initialization functions
71
Template Board File Elements

MACHINE_START Key Interface To Kernel
The Machine Start Macro is used to indentify

initialization functions to the Linux kernel.
The am335x_evm_map_io is declared locally in
the board file.
The am335x is define in the board file but calls
common code to initialize the abstractions for
the L3/L4 registers, this is existing code from the
OMAP2+ Shared Common Code, no need to
modify.
Template Board File Elements (cont.)

The am33xx_init_early is a function within

the OMAP2+ Shared common code.
This is called directly from the common code
without modification
72
Board Template File Elements (cont)

All three of these functions defined come from

the OMAP2+ Shared Common Code, none of
these needed to be modified.
Template Board File Elements (cont)

The am335x_evm_init() is defined by the developer, but uses several

functions from the OMAP2 Common Code without modification.
73
Question
Within the kernel source, where is the am335xevm

board file located?
arch/arm/mach-omap2
DO LAB 1.
74

Goal: Build on the template file demonstrating how to add the MMC peripheral
to provide a Root file system
How this is demonstrated:

Using the provided lab git tree branch that has the code additions necessary
to enable MMC
With MMC enabled the root file system can now be mounted
What is being done:

Explaining the code addition components
Perform the Lab
Steps to adding an MMC

interface to target board file
Review system info to see how peripheral is
attached
Pin Mux
Device/Platform Initialization data

Some peripherals may not require init data
Add Device Init function to EVM Init Function
75
How is the peripheral attached?

Schematic to Pin Mux Utility
Beagle Bone
Schematic
Pin Mux Tool

Capture
Beagle Bone
does not use the
WP pin
Lab 2 Board File Additions

Pin Mux Initialization Data
Capture from the Pin
Mux tool, AM3358
ZCZ package
Use existing pinmux_config

struct to create pin mux
initialization data for mmc0
Number of pins has to
match
76
Lab 2 Board File Additions

MMC Device Initialization Data
MMC initialization structure to

enable interface #1
This init data is from EVM, BB
does not use WP signal
OMAP 2 mmc structure

definition
Only the elements used
are shown, several more
Initialization Function Call Sequence for

MMC Enabling
This sequence of code is adding in the MMC initialization code to the
template file.
77
mmc0 initialization did it work?

template and mmc commit
Code for MMC setup
This code was extracted
from Beagle Bone
specific code from the
SDK release.
git tag result for linux
board port tree
git diff command for this
commit
78

template and mmc commit (cont)
Code for MMC setup
Pin mux was started on
previous page
from Beagle Bone
SDK release.

template and mmc commit (cont)
Code for MMC setup
Note this looks like a
repeat from previous
page, only these lines
are different
How is mmc0_init()
called?
from Beagle Bone
SDK release.
use q to quit
79
DO LAB 2.
Lab 2 Summary
Added code to the board port template file to handle pin mux, MMC
controller initialization and evm initialization function.
All changes happened within the board file
80

Goal: Build onto the template file again adding Ethernet for Network
connectivity
Using the lab git tree branch with the code additions necessary to enable
Ethernet
With Ethernet enabled Remote Matrix will be brought up on the browser on
the Host machine
What is being done:

Explaining the code addition components (in multiple files this time)
Perform the Lab
Steps to adding Ethernet to

target board file
Review system info to see how peripheral is
attached
Pin Mux
Device/Platform Initialization data

None required for this integration

Additional Init code required outside the board file
Add Device Init Function to EVM Init Function
81
MII Ethernet connection

Captured from Beagle
Bone SRM
Please use RMII for MII
here in this example, doc
bug.
MII Interface
signals that
need to be
indentified to
the driver
Pin Mux Utility and

pinmux config struct
Pin Mux tool capture for MII
interface
While the tool shows GMII
this is the MII interface, doc
bug in tool
This demonstrates how

the Pin Mux utility can
assist in filling out the
pinmux_config structure
82
devices.c - code addition outside of board

file
Reason - This is code
added to devices.c to
supplement existing
am33x_cpsw_init, does
not require eeprom
support.
Reads the MAC IDs
Sets the PHY type
Registers MDIO
Register CPSW with
Linux kernel
Ethernet Device Init

and EVM Init functions
The MII init function call pin mux
setup.
The EVM init function calls mii1_init and the cpsw init function.
83
Ethernet Initialization Did it work?
DO LAB 3.
84
Lab 3 summary
Followed the steps of system attach review, pin mux config, device init
to evm init
Had to add additional code outside the board file to support initializing
the cpsw for a generic case

Goal: Build onto the template file again adding support for an LCD
panel
Using the lab git tree tagged branch with code additions necessary to
enable an LCD Panel
What is being done:

Explaining the code addition components (multiple files this time)
Perform the Lab
85
Steps to adding an LCD Panel

to target board file
Review the system
3 interfaces used: PWM (backlight), LCD, Touch Screen
Pin Mux
Device/Platform Initialization data?

Backlight , LCD and Touch screen all have initialization
data
Create Device Init function initializes all 3 components
Add Device init to board_init
LCD Panel Functional Components
LCD is the same 7 panel currently found on the EVM

The respective controllers require data initialization
86
LCD Panel Pin Mux

Initialization
Pin Mux Tool capture for the

LCD Panel
LCD Touch Screen Pin Mux Initialization

Pin Mux Capture of Pins used for Touch Screen
4 Wire Resistive touch
2 Wire for Voltage reference
Pin connections are determined by schematic reference
87
LCD Back Light Pin Mux Initialization

Just a single pin used
for the backlight.
This is a pwm signal
that is used to control
brightness
Add LCD Panel Data Initialization
This configures the registers in

the LCD Controller.
The datasheet for LCD will
provide information (to name a
few)
BPP
Clock polarity
Data Format
DMA
88
LCD Panel Initialization data used by the

LCDC
LCD Panel interfacing numbers have to be added in the da8xx-fb.c if

they are not alreay defined.
These numbers are derived from the datasheet for the panel (to name a
few)
Screen resolution
Timings
Pixel Clock and Polarity
Backlight Initialization Data

PWM is used to control the LCD Panel Brightness
89
LCD Init Function

The steps are:
Pin mux setup
Assign a GPIO to support VDD_en to the LCD
Refer to schematic on which to use
Define PLL value for the pixel clock

Register with the kernel
LCD Clocking Layout
90
Touch Screen and Backlight Init Functions

These init functions call the pin mux config function with the earlier
defined initialized structures
LCD Init Sequence in the EVM Init function

Calling three functions, initialization of
Backlight
LCD
touchscreen
91
DO LAB 4.
Summary Lab 4
LCD required 3 functions to be configured, Backlight, Touch Screen
and LCDC
required device initialization data
required init functions
required pin mux configurations
Made additions to the board file and the frame buffer support file
92
So. does it work yet?
THANK YOU
93
Works Enough!
ADDITIONAL INFORMATION
SOURCES FOR POST
WORKSHOP REVIEW
94
U-Boot Debug using CCSv5

In this session we will cover fundamentals necessary to use CCSv5 and a
JTAG to debug a TI SDK-based U-Boot on an EVM platform.
July 2012
95
Pre-work Check List

Using a Sitara EVM, followed the QSG to connect ethernet, serial cables, SD card and
5V power
Agenda
Sitara Linux SDK Development Components
Example Development Environment
U-Boot Debug Overview
U-Boot Debug Lab
96
Background for this Workshop

Understand the SPL/U-Boot/Kernel boot process
Knowledge of the Sitara Linux SDK and that it contains a cross
compiler for the target device, CCSv5.1 and the source code for SPL/UBoot/Kernel
Have run the setup scripts in the Sitara Linux SDK to configure the
target to boot the Linux kernel from tftp.
Some knowledge of CCSv5
Techniques presented here are not the only way to do things.
SITARA LINUX SDK

COMPONENTS
97
Where to get the Sitara SDK w/ CCS

SDK Installer
CCSv5 Installer
The list of available Sitara Linux SDKs can be found at:

http://www.ti.com/tool/linuxezsdk-sitara
CCS Installation Key things to know..

JTAG use requires a License
The XDS100v2 can be used without a license
You can use a free 90 day evaluation license for all other emulators
To get JTAG support the CCS installer needs to be run in root mode
using sudo
98
EXAMPLE DEVELOPMENT
ENVIRONMENT
Example AM335x EVM Debug Environment

Ubuntu 10.04 LTS
Sitara Linux SDK
CCSv5.1
XDS560v2 USB JTAG
Serial Console
Ethernet
SD Card
MLO/U-Boot Pre-builts
Root File System installed
99
AM335x Image Load Addresses

These addresses are related to the AM335x, other processors will have
different addresses, please refer to respective TRMs. The Addresses
here are pulled from the AM335x TRM.
U-BOOT DEBUG OVERVIEW
100
U-Boot Debug Overview

Familiarize yourself with the u-boot load address. This can be found in
the configuration file (i.e. include/configs/am335x_evm.h) and look for
the following variables:
For SPL - CONFIG_SPL_TEXT_BASE 0x402F0400
For U-boot - CONFIG_SYS_TEXT_BASE 0x80100000
Define a CCS project and point to the source tree within the SDK
This will take a couple minutes since CCS will index the u-boot source tree
Create a target configuration (can specify a gel file)

Power on the EVM with no SD card installed
Launch the target configuration
From CCS connect to the Target, this suspends the target
U-Boot Debug Overview - Cont.

Switch from THUMB2 to ARM mode
Load the SPL image
Load the binary (bin) image if you are not debugging the SPL on the
persistent storage
If using persistent storage you do not need to load anything
Load the U-Boot information

Load the ELF image if you are not debugging the u-boot on the persistent
storage (i.e. SD card or NAND)
Load the symbols only if you are using the u-boot from the persistent
storage
Navigate Source Code and set desired HW Break Point
101
U-Boot Debug Overview - Cont.

Depending on how code was loaded:
Start target execution from the U-boot load address if your loaded the ELF
image
Perform system reset from CCS if you loaded the symbold for u-boot in the
persistent storage
These steps will be performed in the Debug Lab and will emphasize
that how U-Boot is loaded matters (i.e. whether in SPL context or not)
U-BOOT DEBUG LAB
102
U-Boot/SPL building
Have to build U-Boot to get an binary SPL and ELF U-Boot image to
work with.
Add the debug information in the binary SPL and ELF U-Boot
Modify the ti-sdk-am335x-evm-05.05.00.00/board-support/u-boot-2011.09psp04.06.00.08/config.mk:
278 ALL_AFLAGS = $(AFLAGS) $(AFLAGS_$(BCURDIR)/$(@F))
$(AFLAGS_$(BCURDIR)) -g
279 ALL_CFLAGS = $(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F))
$(CFLAGS_$(BCURDIR)) -g
Build the image

Follow the guide in http://processors.wiki.ti.com/index.php/AM335x_UBoot_User%27s_Guide#Building_U-Boot.
U-Boot/SPL building Cont.

Produced images
Locations: ti-sdk-am335x-evm-05.05.00.00/board-support/u-boot-2011.09psp04.06.00.08/am335x
Images
MLO, u-boot.img are the SPL/U-Boot used for boot.

u-boot, U-Boot ELF image, also includes the symbol information.
u-boot.map, contains the memory map for each symbol
u-boot-spl.bin, the binary of SPL
u-boot-spl, SPL U-Boot ELF image, also includes the symbol information
u-boot-spl.map, contains the information for each symbol
103
CCS Import the U-Boot project

Menu File -> Import
CCS Configure the target

View -> Target Configurations
104
CCS Configure target cont.
CCS Connect to the Cortex-A8 core

Right click on the target, click Launch Selected Configuration.
When it successes, it shows the following UI.
Now, the CCS successfully connect to the emulator.
105
CCS Connect to the Cortex-A8 core, cont

Right click on the CortxA8 in last page, click Connect Target. Get the following picture
When it is ready.
Now the CCS connect to the Coretex-A8 Core correctly.
SPL Debug Load the image

Select the CortxA8 core of the target.
Menu Tools -> Load memory, select the u-boot-spl.bin, the binary of the SPL
106
SPL Debug Load the image cont.

Start Address refers to 0x402f0400 mentioned as before.
Type-Size is 32 bit. This is because it is ARM code, not Thumb code.
The memory loading may fail for the first time, then trying it again will be OK.
SPL Debug Load symbols

Menu Run -> Load -> Load Symbols
Choose the image with symbols information, u-boot-spl
107
SPL Debug Change ARM core mode

The initial status for the Cortex-A8 core here is Thumb, while, the system running
On the SOC is in ARM mode.
Menu View -> Registers. Change T bit to 0.
SPL Debug Start to debug
The SPL binary was loaded to 0x402F0400, and this is the start point for SPL.
So the PC of the ARM core should be reset to this address.
This operation is the same as to set the ARM mode in last slide.
Click the Assembly Step Into button as in Red, and you can find the PC jumps to
the code as below.
108
Uboot Debug
In general, the CCS debugging for SPL and Uboot has the same
procedures in most steps, but there are still some differences. So only
list the difference here
For U-boot, it can only run when the SPL finishes the DDR and other related
low level initialization. So when debugging U-Boot, the SPL needs to be
executed firstly.
U-Boot ELF image can be used directly for debugging.
There is the code relocation in the U-Boot, that is, part of the code will be
relocated to higher memory. So the code memory map will be switched to
an offset.
Uboot Debug Load image

Here, the U-Boot ELF image can be loaded directly.
Menu Run -> Load -> Load Program, choose u-boot.
You can see that load address is the one mentioned previous, which is
extract from ELF header.
109
U-boot Code relocation

The code relocation is done in the function relocate_code(), which is
called by board_init_f(). And the code offset here is 0x9FF88000. So if
need to debug the code after relocate_code(), the symbol relocation is
necessary before relocate_code().
Menu Run -> Load -> Add Symbols, the image is still u-boot, and
data/code offset is 0x9FF88000.
SPL/U-Boot Debug -- Tips

Although the debug information, the breakpoint cant be placed in the
assembly code. So if want to place the breakpoint in the assembly code,
it is necessary to find the entry address for the assembly function,
which can be found in the memory map file, and read the code in
disassembly window to find the correct place.
Not every line of C code can place the breakpoint, so it can use the
above approach as well.
110
Q&A
Thank you!
111
Sitara Resource Introduction

This session means to make it clear for you to have an overview about Sitara
resources . This presentation is a guide to help you to get the concept for
the device / platform quickly.
Resource Guide:
http://processors.wiki.ti.com/index.php/AM335x_Resource_Guide(English/%E4%
B8%AD%E6%96%87)
2012
Agenda
Hardware Design Resource
Software Design Resource
Tools & Utilities for AM355x
Online support
112
Hardware Reference Resource
Symbol for AM335x

http://www.ti.com/product/am3359#symbols
For EVM schematic and PCB Layout.

Beaglebone http://beagleboard.org/hardware/design/
GP EVM
http://www.ti.com/tool/tmdxevm3358
StarterKit
http://www.ti.com.cn/tool/cn/tmdssk3358
BSDL/IBIS model for both ZCZ and ZCE package

http://processors.wiki.ti.com/index.php/Device:AM335x:Device_Evaluation
#Important_Documentation
Hardware Design Guide
Schematic & PCB layout checklist

http://processors.wiki.ti.com/index.php/AM335x_Schematic_Checklist
http://processors.wiki.ti.com/index.php/AM335x_Layout_Checklist
DDR2/3 design & layout guide

More detail in AM335x Datasheet.
Multiple options to choose Power management Chips based on Cost

Feature requirements.
http://processors.wiki.ti.com/index.php/Device:AM335x:Device_Evaluation
#Power
113
Power Solution for AM355x

We have provided power-consumption summary
http://processors.wiki.ti.com/index.php/AM335x_Power_Consumption_Su
mmary
Power Estimation Tool

http://processors.wiki.ti.com/index.php/AM335x_Power_Estimation_Tool
Hardware Migration Guide

AM37x to AM335x Hardware Migration Guide
http://processors.wiki.ti.com/index.php/AM37x_To_AM335x_Hardware_Mi
gration_Guide

gration_Guide

gration_Guide

http://processors.wiki.ti.com/index.php/AM387x_To_AM335x_Hardware_M
igration_Guide
114
Sitara Linux SDK
OS Platform
Based on a Arago Open project

http://www.arago-project.org/wiki/index.php/Main_Page
Formal release
The SDK User guide

In the installed folder.
http://processors.wiki.ti.com/index.php/Sitara_Linux_Software_Developer%
E2%80%99s_Guide
More resources can be found in

http://processors.wiki.ti.com/index.php/Category:Linux
AM335x Uboot Resource

The Source Code
The formal release is inside the Ezsdk.
The OpenSource Project: http://arago-project.org/git/projects/?p=uboot-am33x.git;a=summary
The Guide for the AM335x u-boot

http://processors.wiki.ti.com/index.php/AM335x_UBoot_User%27s_Guide
http://processors.wiki.ti.com/index.php/AM335x_board_bringup_tips
115
AM335x Kernel Resource

The User Guide. This contains the guide for all the drivers
http://processors.wiki.ti.com/index.php/AM335x_PSP_User%27s_Gui
de
The performance evaluation
http://processors.wiki.ti.com/index.php/AM335xPSP_04.06.00.07_Features_and_Performance_Guide
The Source Code. (Now update to Linux Kernel 3.2)
The formal release is inside the Ezsdk.
The OpenSource Project: http://aragoproject.org/git/projects/?p=linux-am33x.git;a=summary
AM335x DDR Configuration

AM335x support LPDDR/DDR2/DDR3
AM335x EMIF Configuration Tips:

http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuratio
n_tips
AM335x DDR PHY register configuration for DDR3 :

http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_registe
r_configuration_for_DDR3_using_Software_Leveling
116
Android on AM335x
OS Platform
Rowboat (www.arowboat.org)
A community portal for Android on Sitara
Android 4.0 available on AM335x.
Mail Group, experts always on Line
TI Android Development Kit

Stable periodic snapshots (approx. every 6 months)
http://www.ti.com/tool/androidsdk-sitara
AM335x Android Documents

How to use the AM335x Android SDK
http://processors.wiki.ti.com/index.php/TI-Android-ICS-4.0.3-DevKit3.0.1_UserGuide
The Evaluation on the AM335x Android SDK
http://processors.wiki.ti.com/index.php/TI-Android-ICS-4.0.3-DevKit3.0.1_UserGuide
How to develop the AM335x Android SDK

http://processors.wiki.ti.com/index.php/TI-Android-ICS-4.0.3-DevKit3.0.1_DevelopersGuide
http://processors.wiki.ti.com/index.php/TI-Android-ICS-PortingGuide
More resources can be found in:

http://processors.wiki.ti.com/index.php/Category:Sitara_Android
117
Windows Embedded OS Platform

The WinCE package for AM335x
http://www.ti.com/tool/wincesdk-a8
The WinCE documents

e2e support
http://e2e.ti.com/support/embedded/wince/default.aspx
RTOS on AM335x
OS Platform
RTOS Overview
http://www.ti.com/lsds/ti/dsp/support/software/os_overview.page
For the 3rd party RTOS, please contact the Vendor directly.
118
Starterware on AM335x
Non-OS Platform
Where to download the AM335x starterware

http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/starterware/
02_00_00_07/index_FDS.html
How to use the AM335x Starterware
http://processors.wiki.ti.com/index.php/StarterWare_02.00.00.07_User_Guide
How to develop the AM335x Starterware
http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Booting_And_Flash
ing
http://processors.wiki.ti.com/index.php/AM335X_StarterWare_Environment_Setu
p
More resources can be found in

http://processors.wiki.ti.com/index.php/Category:StarterWare
Development Environment
Ubuntu 10.04 LTS downloading:
http://www.ubuntu.com/download/desktop
How to Build a Ubuntu Linux host under Vmware:

http://processors.wiki.ti.com/index.php/How_to_Build_a_Ubuntu_Linux_hos
t_under_VMware
119
CCSv5
The Sitara SDK also comes with CCSv5.1 available as:
Download for web updates
On the 3rd partition of the in-the-box SD card
CCSv5 provides the following features
Eclipse based
Runs on Linux for debugging Linux
Multi-core debug
Run-Mode Linux debug support
Remote GDB debug
Debug Linux applications and kernel
Stop-Mode Linux support

Control target using JTAG
Enables examination of target and current Linux process
Requires installation of emulator package
Download page :http://processors.wiki.ti.com/index.php/Category:CCS

In addition to the standard CCSv5 package the Sitara SDK also adds the
following plugins
Remote System Explorer
2012-9-4
Emulators for AM335x

TI has different level emulators for AM335x
For the high end emulator
https://estore.ti.com/XDS560v2-System-Trace-P2124.aspx
For the low end emulator
http://www.ti.com/devnet/docs/catalog/embeddedsoftwarefulldetails.tsp?a
ctionPerformed=productFolder&productId=10013
The JTAG interface for Sitara, is not compatible with the ARM JTAG.
The Document s for the emulators & JTAG

http://processors.wiki.ti.com/index.php/XDS560
http://processors.wiki.ti.com/index.php/XDS100
http://processors.wiki.ti.com/index.php/JTAG_Adapters
120
Sitara online support

The wiki page
The hardware, software design guide are all on TI wiki as below
http://processors.wiki.ti.com/index.php/Sitara
Resource Guide:
http://processors.wiki.ti.com/index.php/AM335x_Resource_Guide(English/%E4%B8%
AD%E6%96%87)
The online forum

E2E forum -- Global export will support you here
http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/default.aspx
http://e2e.ti.com/support/embedded/linux/default.aspx
http://e2e.ti.com/support/embedded/android/default.aspx
http://e2e.ti.com/support/embedded/starterware/default.aspx
http://e2e.ti.com/support/embedded/wince/default.aspx
DeyiSupport -- Local FAE will support you here

http://www.deyisupport.com/question_answer/f/25.aspx
Q&A
121
Thank you!
122
Hands-on with the Sitara Linux SDK

This presentation provides a hands-on overview of the Sitara Linux SDK. It
focuses on the software and tools found in the SDK and how to use these
tools to develop for a Sitara device. This presentation is a guide to the actual
hands-on demonstration.
LAB: http://processors.wiki.ti.com/index.php/Sitara_Linux_Training
2012
Pre-work Check List

Installed Ubuntu 10.04 LTS

Installed the latest Sitara Linux SDK
Ready for the Sitara ARM Processors AM335x Starter Kit
Power supply with international adapter

1 StarterKit Board
2 Micro SD cards (Linux + Android)
1 Micro-SD to SD card adapter
1 USB 2.0 cable
AM335x Starter Kit Quick Start Guide
123
Agenda
Starter Kit Overview
SDK Overview
Obtaining the SDK
Installing the SDK
Sitara Linux SDK Directory Structure
Building MLO and U-boot
Building Kernel
Creating an SD Card For EVM Booting
Starter Kit Overview

http://processors.wiki.ti.com/index.php/AM335xStarterKitHardwareUsersGuide
124
What is an SDK?
Definitions and solutions vary, but we think an SDK should be.
More than just a board support package (BSP) or a Demo
An SDK should also contain tools for developing on TI parts
Pre-built libraries that customer applications can link against without
requiring building their own
Documentation
Provide a known good starting point for product development

Start with the SDK reference distributions
Add and remove packages as needed
Sitara Linux SDK Objectives

The purpose of the Texas Instruments Sitara Linux SDK is to provide
customers with a unique out-of-box experience and a quick path to their
application development.
The Sitara Linux SDK accomplishes this by providing
Example applications for key, high touch IP and peripherals

Tools for cross development and environment configuration
Host tools for device configuration
Documentation of SDK components
Out-of-box in < 10 minutes and Development in < 1 hour

A unified look and feel scaling across all Sitara devices from ARM9 to
Cortex-A8 and beyond
125
Sitara Linux SDK Overview
Board Support Package (BSP)
Documentation
Easy installation of all target and host software

components and documentation
CCSv5
ARM Benchmarks, Power, Multimedia, Camera,

Cryptography, WLAN/Bluetooth, Profiling, 3D Graphics
SDK Installer
GUI based on PHP and HTML5

Touchscreen, Mouse & Keyboard, Web Browser
Example Applications
Quick Start Guide & SW Developers Guide
Matrix Application Launcher
Linux Kernel, Bootloaders & File System
Linux aware debug

Preconfigured projects for example applications
Host Tools
Flash Tool, PinMux Utility
Obtaining the SDK

The Sitara SDK is provided on an SD card in the box with the EVM
NOTE: Some boards like the BeagleBoard and BeagleBone may come
without the SDK SD card in the box
Often you will want to download the latest SDK from ti.com to get
updates.
There is now a central location for finding all Sitara Linux SDKs at
126
Obtaining the SDK Cont.

Each SDK page contains not only the single SDK installer, but also has
many individual SDK components pulled out for smaller and quicker
downloads
Single Installer
Individual
Components
Installing the SDK

The Sitara Linux SDK is delivered as a single installer
NOTE: The Sitara Linux SDK will also provide the option to
install CCSv5 if the CCSv5 installer in found in the local
directory. When installing from the SD card the CCSv5 installer
is already placed in the local directory
The Sitara Linux SDK installation has been streamlined to

make installation quick and easy. The customer only needs
to select:
The installation location
Whether or not to install CCSv5 if present
The installer also notifies the user of important information

such as
The default recommended environment
Notice of GPLv3 content within the SDK and information on how
to remove it
The location of the setup scripts within the SDK for additional
configuration
The installer has been designed such that root permission

is not required to install and evaluate the SDK.
127
Sitara Linux SDK Directory Structure
bin - Contains the helper scripts for configuring the host system and target device. Most of these scripts are
used by the setup.sh script.
board-support - Contains the SDK components that need to be modified when porting to a custom platform.
This includes the kernel and boot loaders as well as any out of tree drivers.
docs - Contains various SDK documentation such as the software manifest and additional user's guide. This
is also the location where you can find the training directory with the device training materials.
example-applications - Contains the sources for the TI provided example applications seen during the outof-box demonstration.
filesystem - Contains the reference file systems. These include the smaller base file system as well as the
full-featured SDK file system.
host-tools - Contains the host side tools such as pinmux and flash tool.
linux-devkit - Contains the cross-compile toolchain and libraries to speed development for the target device.
Graphics_SDK_setuplinux_<version>.bin - This is the installer for the graphics SDK. The graphics SDK
components are used by the Sitara Linux SDK to provide additional demos as well as integrated with the prebuilt Qt libraries to accelerate various Qt functions.
Makefile - Provides build targets for many of the SDK components from the top-level of the SDK.
Rules.make - Sets default values used by the top-level Makefile as well as sub-component Makefiles
setup.sh - Configures the users host system as well as the target system for development
Building MLO and U-boot

Preparing to Build
export PATH=/usr/local/ti-sdk-am335x-evm/linux-devkit/bin:$PATH;
Compiling MLO and u-boot

$ cd /usr/local/ti-sdk-am335x-evm/board-support/u-boot-2011.09psp04.06.00.08
$ make O=am335xsk CROSS_COMPILE=arm-arago-linux-gnueabiARCH=arm am335x_evm
You can find the MLO and u-boot.img ready in the current document.
Reference:
1. http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User%27s_Guide
2./usr/local/ti-sdk-am335x-evm/docs/sitara-linuxsdk-sdg-05.05.00.00.pdf
128
Building Kernel
Configuring the Kernel
make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabiam335x_evm_defconfig;
or
make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- menuconfig
Compiling the Kernel

make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- uImage
make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- modules
Installing the Kernel

make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabiINSTALL_MOD_PATH=/usr/local/ti-sdk-am335x-evm/targetNFS modules_install
Reference:
1.http://processors.wiki.ti.com/index.php/AMSDK_Linux_User%27s_Guide
2. /usr/local/ti-sdk-am335x-evm/docs/sitara-linuxsdk-sdg-05.05.00.00.pdf
Creating an SD Card For EVM Booting

The create-sdcard.sh script is in /usr/local/ti-sdk-am335x-evm/bin.
The create-sdcard.sh script must be run with root permissions.
host# sudo /usr/local/ti-sdk-am335x-evm/bin/create-sdcard.sh
You will succeed in creating a 2 partition card by following the prompts.

The 2 partition SD card need to be made as below:
Partition No.
Format
Content
FAT32
MLO, u-boot.img, uImage
Ext3
The File System
Reference :
1.http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_create_SD_card
_script
2./usr/local/ti-sdk-am335x-evm/docs/sitara-linuxsdk-sdg-05.05.00.00.pdf
129
Q&A
Thank you!
130

Boot Camp Local 20120904 v1

Uploaded by

Copyright:

Available Formats

Boot Camp Local 20120904 v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Boot Camp Local 20120904 v1

Uploaded by

Copyright:

Available Formats

Giving Linux the Boot

What You Will Learn

Memory Map after Linux

Go from nothing to Linux OS Environment

Why are there stages to the

Starting with bare silicon

Overview of Any Bootstrap Process

Why are there Boot Stages?

Linux Boot Process Components

4 Stages of the Linux Boot Process

4 Stages of the Linux Boot Process - Cont

Boot mode indicates to the

Each stage adds

-Selects which source of SPL

While SPL should use the

Overview Processor Boot Modes

AM335x SYS_BOOT Pin Configuration Selection

Overview Boot Modes

AM335x SYS_BOOT Pin Configuration Selection

Persistent Storage based Boot Modes

Connectivity Based Boot Modes

But where in memory did it go?

Passes Kernel Command Line to Kernel

Debugging capabilities (just mentioning, not used during boot process)

U-Boot Environment Variables

Example printout shows boot arguments and boot command.

Kernel uImage What is it?

Starting kernel ...

uImage is a kernel image wrapped with a header that describes

Memory Map of Boot Process (AM335x)

SPL is loaded into internal RAM

U-Boot is loaded first into DDR

Please note the addresses used

Kernel Command Line

Optional Command Line

Kernel Command Line NFS example

More Info on configuration for NFS can be found here at kernel.org

Overview Kernel Memory Usage

Kernel initializes MMU and takes

Look at virtual memory layout printed

Linux Mem Mgmt

Linux Kernel Start

Calls the init task which sets up user space context

Memory Map from User Application Perspective

Virtual Memory Map

All logical address go through an

Want to re-iterate the point of not

Linux Virtual Memory (.....Review....)

All apps are compiled to the same starting address

Linux Memory Info Table Dump

Google meminfo explained

System Physical Memory Map

Read this article about how to use this

Google iomem linux explained

Kernel Root File System

Link to Overview of Linux Root File Systems

Linux Init Process

ARM based multimedia using GStreamer &

Pre-work check list

What you will learn