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

1

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

2

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 it’s 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.

3

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

3

Kernel

4

4

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

5

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

6

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

7

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

8

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

9

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

Multimedia on Cortex-A8
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

Multimedia on Cortex-A8
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

Multimedia on Cortex-A8
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

Mpeg4 + AAC decode pipeline
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

Mpeg4 + AAC decode pipeline
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
 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
• 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 Linux’s 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 you’re 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 OPP’s 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.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

1

0.1

Execution
Time

Execution
Time
1

2

3

1

4

37

2

3

4

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
 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)

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
– we’ll 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…..
• What’s 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: “So…what’s 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….What’s 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……. Where’s 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
• It’s 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
• How this is Demonstrated
– 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

git diff – Code Difference between mmc
and ethernet commit (cont)
• Code continuation for Ethernet
PHY setup
• This code was extracted from
Beagle Bone specific code from
the SDK release.

git diff – Code Difference between mmc
and ethernet commit (cont)
• Code continuation for Ethernet
setup
• This code was extracted from
Beagle Bone specific code from
the SDK release.

62

git diff – Code Difference between mmc
and ethernet commit (cont)
• Code continuation for Ethernet
setup
• This code was extracted from
Beagle Bone specific code from
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 what’s 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
• How this is Demonstrated
– 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.)
MACHINE_START – Key Interface To Kernel

• 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)
MACHINE_START – Key Interface To Kernel

• 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)
MACHINE_START – Key Interface To Kernel

• 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

Linux Board Port Exercise 2 - Overview
• 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
– Use the Pin Mux Utility to configure Pin Init data

• Device/Platform Initialization data
– Some peripherals may not require init data
• Create Device Init function
• 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?

git diff – Code Difference between
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

git diff – Code Difference between
template and mmc commit (cont)
• Code for MMC setup
• Pin mux was started on
previous page
• This code was extracted
from Beagle Bone
specific code from the
SDK release.

git diff – Code Difference between
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?
• This code was extracted
from Beagle Bone
specific code from the
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

Linux Board Port Exercise 3 - Overview
• Goal: Build onto the template file again adding Ethernet for Network
connectivity
• How this is demonstrated:
– 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
– Use the Pin Mux Utility to configure Pin Init data

• Device/Platform Initialization data
– None required for this integration

• Create Device Init function
• 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

Linux Board Port Exercise 4 - Overview
• Goal: Build onto the template file again adding support for an LCD
panel
• How this is demonstrated:
– 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
– Use the Pin Mux Utility to configure Pin Init data

• 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
 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)

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 can’t 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

• AM35x to AM335x Hardware Migration Guide
– http://processors.wiki.ti.com/index.php/AM35x_To_AM335x_Hardware_Mi
gration_Guide

• AM18x to AM335x Hardware Migration Guide
– http://processors.wiki.ti.com/index.php/AM18x_To_AM335x_Hardware_Mi
gration_Guide

• AM387x to AM335x Hardware Migration 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
 http://www.ti.com/tool/linuxezsdk-sitara

• 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 and configured VMWare Player v4 or later

 Installed Ubuntu 10.04 LTS
 Installed the latest Sitara Linux SDK
 Within the Sitara Linux SDK, ran the setup.sh (to install required host packages)
 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 Developer’s 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
http://www.ti.com/tool/linuxezsdk-sitara

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

1

FAT32

MLO, u-boot.img, uImage

2

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