From Texas Instruments Wiki
Exploring the MCSDK
Last updated: 01/06/2017
The Multicore Software Development Kit (MCSDK) provides foundational software for TI KeyStone II device platforms. It encapsulates a collection of software elements and tools intended to enable customer application development and migration.
The foundational components include:
SYS/BIOS real-time embedded operating system on DSP cores
Linux high-level operating system running on ARM A15 cluster (SMP mode)
DSP chip support libraries, DSP/ARM drivers, and basic platform utilities
Interprocessor communication for communication across cores and devices
SoC resource management
Optimized application-specific (transport) and application non-specific algorithm libraries
Trace debug and instrumentation
Bootloaders and boot utilities, power-on self test
Demonstrations and examples
ARM software libraries available in Linux devkit or via Arago/Yocto
Latest toolchain (ARM Linaro, DSP TI CodeGen)
Host tools, integrated development environment
This Chapter provides a high level overview of the different pieces so you will gain a sense of what they are and what they do. After reading this chapter you should have a sense of the different pieces that make up the MCSDK. You can then refer to the chapter, Developing with the MCSDK to get the details.
Here is a high-level picture of the software ecosystem that MCSDK is a part of:
Not all items in the genric picture above applies to all parts.
Please see the release notes for the comprehensive list of co the latest release notes is
For licensing information, please see t the latest software manifest is
Support for BIOS5 or older releases
Support for CCS 4.x or older releases
Support for platforms not listed
DSP image format other than ELF (e.g., COFF)
Big endian ARM
Big endian DSP with ARM Little endian configuration
Put a condensed acronym table here. That is one that addresses acronyms that this Chapter uses. This means you should add/remove from the Table below.
The following acronyms are used throughout this chapter.
Advanced Mezzanine Card
Texas Instruments Code Composer Studio
Texas Instruments Chip Support Library
Double Data Rate
Dynamic Host Configuration Protocol
Digital Signal Processor
Texas Instruments Data Analysis and Visualization Technology
Enhanced Direct Memory Access
Electrically Erasable Programmable Read-Only Memory
Evaluation Module, hardware platform containing the Texas Instruments DSP
High Performance Digital Signal Processor Utility Application
HyperText Transfer Protocol
Internet Protocol
Texas Instruments Inter-Processor Communication Development Kit
Joint Test Action Group
Texas Instruments Multi-Core System Analyzer
Texas Instruments Multi-Core Software Development Kit
Texas Instruments Network Development Kit (IP Stack)
Network Interface Management Unit
Texas Instruments Programmers Development Kit
Random Access Memory
Eclipse Real-Time Software Components
Secondary Program Loader
Serial Rapid IO
Transmission Control Protocol
Texas Instruments
Universal Asynchronous Receiver/Transmitter
User Datagram Protocol
Texas Instruments Unified Instrumentation Architecture
Universal Serial Bus
We use the abbreviation TMS when referring to a specific TI device (processor) and the abbreviation TMD when referring to a specific platform that the processor is on. For example, TMS320C6678 refers to the C6678 DSP processor and TMDSEVM6678L refers to the actual hardware EVM that the processor is on.
ARM subsystem runs following software components:-
U-Boot - Boot loader
Boot Monitor - Monitor and other secure functions
SMP Linux - ARM A15 port of SMP Linux
This section describes details of these components delivered as part the Linux ecosystem in MCSDK.
This section provides information on the features, functions, delivery package and compile tools for the Linux Kernel release for KeyStone II. This document describes how to install and work with Texas Instruments' Linux Kernel for the KeyStone II platform. The MCSDK provides a fundamental Linux based software platform for development, deployment and execution on the ARM A15 processor of the KeyStone II architecture. In this context, the document contains instructions to:
Install the release
Build the sources contained in the release and run it on the target keystone II EVM
Kernel and peripheral driver design and/or implementation details
It is strongly recommended to upgrade all images to the same release which includes: uboot, boot monitor, kernel and file system.
This section describes the list of changes that impacts the user
Starting with this release, the git repo for linux, boot monitor and u-boot has been moved to
(previously on Arago). Also Linux kernel is rebased to v3.10.10. Please see the build location for the URL for these repos.
In these tags, kernel started using 512M capacity of the NAND available on the EVM. The ubifs partion size in dts file is changed accordingly to use the increased size.
The u-boot is upgraded to increase the mtd partition size to reflect the new size. The u-boot tag for this
is K2_UBOOT_.09_01. There are dts changes that requires the kernel to be in sync with DTS.
DTS file name is changed to match with EVM name, k2hk-evm.dts. So the DTB file name has k2hk to indicate the EVM name.
Linux upstream kernel changed to 3.8.4. Last release was based on 3.6.6. As a side effect, the location of dtb file generated by the Linux kernel build is now at arch/arm/boot/dts folder.
Changed the name of dtb file populated in the release to uImage-tci6638-evm.dtb.
Changed the name of u-boot command install_skern() to mon_install()
Changed the name of dtb file populated in the release binaries from tci6638-evm.dtb to uImage-keystone-evm.dtb
Before you begin with the installation of this package please make sure you have met the following system requirements:
CCS v5.3.0 or later: Available on Windows or Linux Host
Keystone II Simulator: Available on Windows or Linux Host
Toolchain: Must be installed on Linux Host. Ubuntu 12.04 recommended.
Terminal Emulator: Tera Term on Windows or Minicom on Linux Host can be used.
For CCS and Simulator installation
please refer to corresponding documentation, which comes with CCS and/or Simulator.
Please see
Please refer to
The Linux kernel related utilities and pre-built binaries are provided in the release under the folder mcsdk_linux_&version&.
Please refer the "Getting Started" section for more details on installation.
U-Boot release tag is named in the following format:-
K2_UBOOT_&upstream release version&&year_& &month_&&[iteration]&
For Example, K2_UBOOT_.08 indicates, the u-boot is based on upstream version 2013-01 and the release is done in August 2013. This done to make it intuitive for anyone to identify the baseline upstream u-boot version used in a release from the tag name.
Linux release tag is named in the following format:-
K2_LINUX_-&upstream release version_&&year_& &month_&&[iteration]&
For example K2_LINUX_03.08.04_13.08_01 indictaes the Linux kernel is based on upstream kernel version 03.08.04 and the release is done in August 2013 and iteration is 1. Iteration is optional and is used when multiple tags are to be used for the same month for what ever reason.
For RT Preempt patched kernel, the tag name also include the word "RT"
RT Preempt patched Linux kernel is available on a seperate master branch (master-rt). master branch is without RT patches. This will be available under release_&build number&/master-rt and release_&build number&/master branches respectively on Arago git repo.
Boot Monitor release tag is named in the following format:-
K2_BM_&year_& &month_&&[iteration]&
For example K2_BM_13.08 is released in August 2013
There are two possible ways to build the linux kernel:
The first is to build the standalone kernel by cloning the kernel Yocto git repository on the local host. Please refer the Yocto section below for details.
The second is to build the kernel together with the filesystem using Yocto project on Arago
Ubuntu 12.04 LTS distribution and sudo access should be available to the user.
Install the tool chain as described in the section Toolchain Installation above for cross compiling.
Install and configure git in the Ubuntu machine. Use the following command to install git:
$ apt-get install git-core
To configure git please refer here. If your network is behind a proxy, those settings need to be configured as well.
Packages needed at build-time can be fetched with a simple command on Ubuntu 12.04:
$ sudo apt-get install build-essential subversion ccache sed wget cvs coreutils unzip texinfo docbook-utils gawk help2man diffstat file g++ texi2html bison flex htmldoc chrpath libxext-dev xserver-xorg-dev doxygen bitbake uboot-mkimage libncurses5-dev
If you are running a distribution other than Ubuntu 12.04 LTS, please refer to your distribution documentation for instructions on installing these required packages.
From the MCSDK 3.0.4 release onward, the size of the the rootfs has increased beyond 80MB. As a result use of ramfs is not possible. The filesystem needs to be under 80M for use with ramfs
If your network is behind a firewall/proxy additional settings are needed for bitbake to be able to download source code repositories for various open source projects. Some of these configuration items are:
wgetrc: A “.wgetrc” needs to be created under the $HOME directory. A sample wgetrc can be found here. Please update configuration variables http_proxy, https_proxy and ftp_proxy as per your network environment.
Set proxy environment variables. These may be added to your .bashrc or shell initialization script:
export http_proxy="&your_proxy&:&port&"
export ftp_proxy="&your_proxy&:&port&"
export https_proxy="&your_proxy&:&port&"
$HOME/.subversion/servers needs to be updated if the network is behind a proxy. The following lines need to be modified as per settings for your network:
http-proxy-exceptions = “exceptions”
http-proxy-host = “proxy-host-for-your-network”
http-proxy-port = 80
First clone the U-Boot source tree from Arago git repository
$ git clone
u-boot-keystone
$ cd u-boot-keystone
$ git reset --hard &Release tag&
where release tag can be obtained from the release notes. For example, release tag used is DEV.MCSDK-
1. To build u-boot.bin that can be loaded and run from MSMC SRAM, do the following
make &soc&_evm_config
To do 2 stage SPI NOR boot, following images are to be built.
2. To build u-boot-spl.bin that can be booted from SPI NOR flash, do the following:-
make &soc&_evm_config
make spl/u-boot-spl.bin
The u-boot-spl.bin will be available at spl/ folder
3. To build secondary boot u-boot.img (in uImage firmware format) that can be flashed and booted through SPI NOR flash do the following:-
make &soc&_evm_config
make u-boot.img
The u-boot.img will be created at root directory of u-boot source tree.
Alternately both u-boot-spl.bin and u-boot.img can be combined and flashed to SPI NOR flash. To do so, use the following command to build a single gph image for programming on SPI NOR flash
make &soc&_evm_config
make u-boot-spi.gph
The u-boot-spi.gph image will be created in the root folder.
4. To build a single u-boot-nand.gph image that can be programmed on EMIF16 NAND flash, do the following:-
make &soc&_evm_config
make u-boot-nand.gph
Note: &soc& is "k2hk", "k2l" or "k2e"; for MCSDK 3.0.x, &soc& is "tci6638"
To build boot monitor code, first clone the git repository as
$ git clone
$ cd boot-monitor
$ git reset --hard &Release tag&
where release tag can be obtained from the release notes. For example, DEV.MCSDK-03.00.00.11 is the release tag.
$ make clean
skern-&soc&.bin (for MCSDK 3.0.x, skern.bin) will be created in the current working directory.
Note: &SOC& is "k2hk", "k2l" or "k2e"
This section assumes that the Linaro toolchain for ARM is installed and environment variables CROSS_COMPILE, ARCH are set up as per instructions given in section Toolchain Installation .
export CROSS_COMPILE=arm-linux-gnueabihf-
export ARCH=arm
PATH=&path to installed toolchain&/bin:$PATH
The first step in building the kernel is downloading the kernel source code from the git repositories to the local Ubuntu 12.04 host. This is performed as follows:
$ git clone
linux-keystone
$ cd linux-keystone
$ git reset --hard &Release tag& where release tag can be obtained from Release notes. For example tag is DEV.MCSDK-03.08.04.11 for the release.
Before building the linux kernel for Simulator, user has to modify the source file linux-keystone/drivers/net/ethernet/ti/keystone_ethss.c
The line u8 mac_addr_nic[6] = {0x5c, 0x26, 0x0a, 0x80, 0x0d, 0x43}; /* NIC addr */ has to be modified
The NIC address should be appropriately modified with the NIC address of the host where CCS and the simulator are installed.
To build the kernel for execute the following commands inside the linux-keystone folder:
$ make keystone2_defconfig
$ make uImage
The next step is to build the device tree file:
For building DTB for EVM use the following command:-
$ make &soc&-evm.dtb
Note: &soc& is "k2hk", "k2l" or "k2e"
For building DTB for simulator use the following command:-
$ make keystone-sim.dtb
Note that starting 3.8.4, location of dtb binary is moved to arch/arm/boot/dts.
To Build Linux for Full RT Preempt mode, do the following
$ git reset --hard &Release tag& where release tag can be obtained from Release notes. For example tag for RT kernel is DEV.MCSDK-RT-03.08.04.11 for the release.
$ make keystone2_fullrt_defconfig
$ make uImage
TransportNetLib software package provides a library for ARM user space application to gain direct access to networking h/w. This is for such use cases as fast path packet processing.
The TransportNetLib includes HighPerformanceLib(HPLIB) and Network API(NetAPI) modules. Detailed description of these modules and build insructions are available at .
Before loading the u-boot to EVM you need to create u-boot.uart blob. That is the u-boot.bin binary with preceding 4096 zeros. Assuming you are in the u-boot source top level directory execute the following commands after building u-boot:
& dd if=/dev/zero of=4k_zeros bs=4096 count=1
& cat 4k_zeros u-boot.bin & u-boot.uart
You should run two terminals on a PC. One connected to the BMC and another to the UART0 of the K2HK SOC. The terminal connected the the SOC UART0 port must support xmodem protocol. For example to use minicom on Linux, follow the steps at []
At the UART0 terminal, user should initiate transfer of the u-boot.uart file using the xmodem protocol. User should see
's: Give your local XMODEM receive command now."
Using BMC console set the ARM UART boot mode and reboot the K2HK SOC.
BMC& bootmode #4
BMC& reboot
This would initiate the transfer. Once transfer is complete, user would see
Transfer complete
READY: press any key to continue...
Once any key is pressed, u-boot starts up and boot up log is seen at the UART0 terminal
If you do not have a target configuration for the EVM, you have to create one. Create a new target configuration for the TCI6638 device using the "Texas Instruments XDS2xx USB Emulator" connection. You have to do that only once.
Launch the target configuration.
Power on the EVM and connect CCS to the CortexA15_1 target.
Connect serial cable between the PC and the EVM. Open Teraterm or Hyper Terminal, create a connection with 115200 baud rate, 8 data bits, no parity, 1 stop bits and no flow control.
Copy the images from the images folder of the installed release directory to the loadlin folder. Copy the latest tci6638-evm.ccxml to the loadlin folder. Also the script may need tweaking to suite the environment on which you are running this
script. The example given here is for reference only.
Edit the loadlin-evm-uboot.js java script from the &release folder&/host-tools/loadlin folder for the following
PATH_LOADLIN = &path of release folder&/host-tools/loadlin
var pathUboot = PATH_LOADLIN + "/u-boot-keystone-evm.bin";
var pathSKern = PATH_LOADLIN + "/skern-keystone-evm.bin";
Save the file. Copy the image files (u-boot-keystone-evm.bin and skern-keystone-evm.bin) from &release folder&/images to &release folder&/host-tools/loadlin. Open the scripting console and type
loadJSFile "&path of release folder&/host-tools/loadlin/loadlin-evm-uboot.js"
This will load, u-boot image to MSMC RAM at 0xc001000 and boot monitor image to MSMC RAM at address 0xc5f0000. Make sure PC is currently pointing to 0xc001000. Click Resume button on the CCS window to run u-boot.
The two stage SPI flash u-boot image consists of a first stage u-boot SPL binary with a header and a footer,
and a second stage full u-boot binary.
These two binaries can be programmed to SPI flash in two ways.
Using a combined single GPH image (u-boot-spi-&soc&-evm.gph from release) to program the SPI NOR flash.
Where &soc& is k2hk/k2e/k2l. If you build u-boot from source code, u-boot-spi.gph will be created in the root source directory and is to be used as u-boot-spi-&soc&.gph.
This is the quick and easiest way to upgrade u-boot image if you have u-boot running already on the evm. This implemented using a u-boot env script which is added to very recent version of the u-boot. To see if current u-boot on EVM support this, do
and check if get_uboot_net and burn_uboot env variables are present. Also name_uboot is set to u-boot-spi-&soc&-evm.gph. If so do following to upgrade u-boot assuming gph image is copied to root directory of tftp server
env default -f -a
setenv serverip &ip address of tftp server&
setenv tftp_root &tftp root directory&
run get_uboot_net
run burn_uboot
The EVM now boots with latest version of u-boot image.
'NOTE:' User might want to check the value of mem_reserve env variable to ensure only reserved memory is used by applications as described in
Program the two stage binaries separately, follow the steps in the below section
Follow the same procedure described in section , but use the u-boot-spl.bin image instead. The SPL U-Boot reside in SPI flash at offset 0.
First step is to load u-boot.img to MSMC SRAM address 0xc300000 through CCS or other means. Then do the following steps:-
sf erase 0x10000 &size of image in hex rounded to sector boundary of 0x10000&
for example if the size of image is hex 0x4500b, round it to 0x50000
sf write 0xcx10000 &size of image in hex&
In the single stage SPI flash boot, the image to be burnt into the SPI flash contains the u-boot.bin
with a header and a footer added.
This section assumes that u-boot is booted up and running on EVM, e.g. using CCS (see section above)
Load u-boot.bin to memory to be saved to SPI flash through CCS
* Have a copy of u-boot.bin ready in a directory on host PC running CCS
* Start and connect CCS to ARM core 0
* CCS & Run & "Suspend"
* CCS & Tools & Load Memory & browse to the copy of u-boot.bin and load it to address 0x0c300000
* CCS & Run & "Resume"
where 0x0c300000 is an example address to temporarily keep the u-boot.bin image.
Now a copy of u-boot.bin is loaded to 0x0c300000.
At the u-boot prompt:
Format the u-boot.bin image loaded in memory to SPI boot format
& fmtimg spi 0x0cx0c300000 &hex_size&
where hex_size is the size of the u-boot.bin in hex bytes,
and 0x0c001000 is the address that u-boot.bin will be loaded by RBL and starts execution.
Note down the formatted image hex size printed out at the end of the command, call this fmt_img_size.
Alternatively issue following commands to perform the formatting
& setenv fileaddr 0x0c300000
& setenv filesize &hex_size&
& fmtimg spi 0x0c001000
where command fmtimg takes the hex size of u-boot.bin from env variable "filesize",
and the address where u-boot.bin is situated is taken from env variable "fileaddr".
This is useful if u-boot.bin is loaded to memory by using tftp. In that case, filesize and fileaddr are set in the process.
Note down the formatted image hex size printed out at the end of the command, call this fmt_img_size.
Prepare SPI flash for saving formatted u-boot.bin later
& sf probe
& sf erase 0 &hex_len&
erases hex_len bytes in SPI flash starting from offset 0,
where hex_len must be at least the formatted image size shown in the fmtimg command and on flash sector boundary,
sector size of SPI flash on EVM is 0x10000
e.g. if formatted image size is 0x2FBA0, then "sf erase 0 0x30000"
Save formatted u-boot.bin image to SPI flash
& sf write 0x0c &fmt_img_size&
where fmt_img_size is the hex size of the formatted image printed out in the fmtimg command above.
* Power off EVM
* Set Boot Setting DIP Switch (SW1) on EVM to 0010 (ARM SPI boot mode)
- i.e SW1: 1(OFF) 2(OFF) 3(ON) 4(OFF)
* If any, disconnect CCS from EVM
* Power up EVM
This section assumes that u-boot is booted up and running on EVM, e.g. using
Also the EVM is connected to a network where a tftp server is available.
compile the nand u-boot image on host (refer to U-Boot Build instructions section)
place u-boot-nand.gph in tftp server
under u-boot prompt, do
& setenv serverip &tftp-server-ip-address&
& setenv bootfile '/tftp/server/path/to/u-boot-nand.gph'
& dhcp ${fileaddr}
& nand ecclayout set 1
& nand erase.part bootloader
& # For K2HK EVM
& nand write ${fileaddr} bootloader ${filesize}
& # For K2E or K2L EVM
& nand write ${fileaddr} &offset& ${filesize}
& nand ecclayout set 0
There is an errata for K2L and K2E PG 1.0 that NAND boot does not distinguish between a block that has been pre-marked as bad vs one that is declared bad due to error correction failure. When a bad block is found, the ROM bootloader moves to the next block and re-initializes the boot data processor. When the block is pre-marked as bad the boot data processor should not be reset.
The workaround to this problem is to burn a multi-block image in the NAND with contiguous good blocks. Users can check the bad block list using "nand bad" command and skip any bad blocks.
The NAND device on K2L EVM has a block size of 256KB, and u-boot-nand.gph is over 300KB which will uses 2 blocks, starting from block 0 (offset address 0). Similarly the nand device on K2E EVM has a block size of 128KB, and u-boot-nand.gph will uses 3 blocks. If any of the 2 or 3 blocks are marked bad, we should skip the bad block and use the next 2 or 3 good blocks.
E.g. block 0 is good but block 1 is bad, and block 2 - 4 are good, the &offset& should be set to 0x80000 (starting offset address of block 2) for K2L EVM, and 0x40000 for K2E EVM.
'NOTE:' User might want to check the value of mem_reserve env variable to ensure only reserved memory is used by applications as described in
To boot u-boot from NAND flash, do one of the following:
By setting boot pin:
* Power off EVM
* Set Boot Setting DIP Switch (SW1) on EVM to 0000 (ARM NAND boot mode)
- i.e SW1: 1(OFF) 2(OFF) 3(OFF) 4(OFF)
* Power up EVM
From BMC terminal on Rev2.0 EVM
BMC& bootmode #0
BMC& reboot
First step is to load u-boot (eg. u-boot-keystone-evm.bin) and boot monitor (eg. skern-keystone-evm.bin) images onto MSMC RAM and run u-boot to get the u-boot prompt. See the instructions in section .
Now follow the steps below to load and run Linux through CCS.
Copy the images from the images folder of the release directory to the loadlin folder.
Edit the loadlin-evm-kern.js file and make sure the following variables points to valid paths for the images.
PATH_LOADLIN = &path of lsp-release-folder&/host-tools/loadlin
var pathKernel
= PATH_LOADLIN + "/uImage-keystone-evm.bin";
var pathDtb
= PATH_LOADLIN + "/uImage-k2hk-evm.dtb";
var pathInitrd
= PATH_LOADLIN + "/&name of min root file system, eg. tisdk-rootfs.cpio.gz&".
If the root fs image size is greater than 9M, make sure the bootargs in u-boot is set correctly to reflect the size.
Currently it defaults to 9M.
Note For RT Preempt images, use image file names uImage-rt-keystone-evm.bin and uImage-rt-k2hk-evm.dtb for kernel and dtb files.
Save the file and exit.
Click onto the suspend button or Alt+F8
Open scripting console and run
loadJSFile "&path of loadlin from release folder&/loadlin-evm-kern.js"
The script loads Linux kernel image, DTB and file system image to DDR. Once script execution is complete, click onto the Resume button on CCS.
At u-boot prompt, update the env variable bootargs, for example:
& setenv bootargs 'console=ttyS0, rootwait=1 earlyprintk rdinit=/sbin/init rw root=/dev/ram0 initrd=0xM'
If the size of the file system image is greater than 9M, update 9M to the correct size.
Next, type the following command to install boot monitor code.
& mon_install 0x0c5f0000
Now boot Linux using the u-boot command below.
& bootm 0x - 0x
A sample SMP Linux boot log is shown below for reference
## Started boot kernel successfully
TCI6638 EVM # bootm 0x - 0x
## Booting kernel from Legacy Image at
Image Name:
Linux-3.6.6-rt17-0d-
16:17:47 UTC
Image Type:
ARM Linux Kernel Image (uncompressed)
Data Size:
3215872 Bytes = 3.1 MiB
Load Address:
Entry Point:
Verifying Checksum ... OK
## Flattened Device Tree blob at
Booting using the fdt blob at 0x
Loading Kernel Image ... OK
Loading Device Tree to 87ff8000, end 87fff2ea ... OK
Starting kernel ...
&&&& skern_poweron_cpu &&&&
Message2 from Secure Mode
&&&& skern_poweron_cpu &&&&
Message2 from Secure Mode
&&&& skern_poweron_cpu &&&&
Message2 from Secure Mode
0.000000] Booting Linux on physical CPU 0
0.000000] Linux version 3.6.6-rt17-0d-dirty (a0868495@ares-ubun
tu.am.) (gcc version 4.7.2
(prerelease) (crosstool-NG linaro
-1.13.1-20720 - Linaro GCC 2012.07) ) #1 SMP PREEMPT Mon Jan 28 11:17
:38 EST 2013
0.000000] CPU: ARMv7 Processor [412fc0f4] revision 4 (ARMv7), cr=10c5387d
0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
0.000000] Machine: KeyStone2, model: Texas Instruments Keystone 2 SoC
0.000000] cma: CMA: reserved 16 MiB at 86c00000
0.000000] Memory policy: ECC disabled, Data cache writealloc
0.000000] On node 0 totalpages: 32768
0.000000] free_area_init_node: node 0, pgdat c05ff440, node_mem_map c062b00
Normal zone: 256 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 32512 pages, LIFO batch:7
0.000000] PERCPU: Embedded 8 pages/cpu @c776 r u32768
0.000000] pcpu-alloc: s1 d1 alloc=8*4096
0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
0.000000] Built 1 zonelists in Zone order, mobility grouping on.
0.000000] Kernel command line: console=ttyS0, debug earlyprintk
init=/bin/ash rw root=/dev/ram0 initrd=0xM
0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
0.000000] Memory: 128MB = 128MB total
0.000000] Memory: 9k available, 33272k reserved, 0K highmem
0.000000] Virtual kernel memory layout:
vector  : 0xffff0000 - 0xffff1000
fixmap  : 0xfff00000 - 0xfffe0000
vmalloc : 0xc8800000 - 0xff000000
lowmem  : 0xc0000000 - 0xc8000000
 : 0xbfe00000 - 0xc0000000
modules : 0xbf000000 - 0xbfe00000
.text : 0xc0008000 - 0xc0596c08
.init : 0xc0597000 - 0xc05cbe00
.data : 0xc05cc000 - 0xc0601ea8
.bss : 0xc0601ecc - 0xc062a1cc
0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, N
0.000000] Preemptible hierarchical RCU implementation.
0.000000] NR_IRQS:16 nr_irqs:16 16
0.000000] main_pll_clk rate is , postdiv = 2, pllm = 15,plld = 0
0.000000] tci6614-timer: no matching node
0.000000] arch_timer: found timer irqs 29 30
0.000000] Architected local timer running at 166.66MHz.
0.000000] Switching to timer-based delay loop
0.000000] sched_clock: 32 bits at 166MHz, resolution 6ns, wraps every 25769
0.000000] Console: colour dummy device 80x30
0.000092] Calibrating delay loop (skipped), value calculated using timer fr
equency.. 333.33 BogoMIPS (lpj=1666666)
0.000113] pid_max: default: 4096 minimum: 301
0.000364] Mount-cache hash table entries: 512
0.008205] CPU: Testing write buffer coherency: ok
0.008399] CPU0: thread -1, cpu 0, socket 0, mpidr
0.008435] hw perfevents: enabled with ARMv7 Cortex-A15 PMU driver, 7 counte
rs available
0.008503] Setting up static identity map for 0x - 0x
0.104891] CPU1: Booted secondary processor
0.104932] CPU1: thread -1, cpu 1, socket 0, mpidr
0.154985] CPU2: Booted secondary processor
0.155031] CPU2: thread -1, cpu 2, socket 0, mpidr
0.205092] CPU3: Booted secondary processor
0.205141] CPU3: thread -1, cpu 3, socket 0, mpidr
0.205335] Brought up 4 CPUs
0.205375] SMP: Total of 4 processors activated (1333.33 BogoMIPS).
0.232209] NET: Registered protocol family 16
0.247428] DMA: preallocated 256 KiB pool for atomic coherent allocations
0.256104] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint
registers.
0.256114] hw-breakpoint: halting debug mode enabled. Assuming maximum watch
point size of 4 bytes.
0.275902] bio: create slab &bio-0& at 0
0.277188] SCSI subsystem initialized
0.278040] usbcore: registered new interface driver usbfs
0.278235] usbcore: registered new interface driver hub
0.278478] usbcore: registered new device driver usb
0.282607] Switching to clocksource arch_sys_counter
0.313194] NET: Registered protocol family 2
0.313891] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
0.314031] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
0.314165] TCP: Hash tables configured (established 4096 bind 4096)
0.314195] TCP: reno registered
0.314212] UDP hash table entries: 128 (order: 0, 4096 bytes)
0.314237] UDP-Lite hash table entries: 128 (order: 0, 4096 bytes)
0.314570] NET: Registered protocol family 1
0.314914] RPC: Registered named UNIX socket transport module.
0.314927] RPC: Registered udp transport module.
0.314938] RPC: Registered tcp transport module.
0.314949] RPC: Registered tcp NFSv4.1 backchannel transport module.
0.315232] Unpacking initramfs...
0.357371] Initramfs unpacking failed: junk in compressed archive
0.366886] Freeing initrd memory: 9216K
0.512036] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
0.512661] NTFS driver 2.1.30 [Flags: R/O].
0.513335] jffs2: version 2.2. (NAND) ?(C)
Red Hat, Inc.
0.516214] NET: Registered protocol family 38
0.516738] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 2
0.516754] io scheduler noop registered
0.516766] io scheduler deadline registered
0.517099] io scheduler cfq registered (default)
0.629016] Serial:
driver, 4 ports, IRQ sharing disabled
0.30c00.serial: ttyS0 at MMIO 0x2530c00 (irq = 309) is a 16550A
1.272067] console [ttyS0] enabled
1.282480] loop: module loaded
1.285920] at24 0- byte 24c1024 EEPROM, writable, 1 bytes/write
1.294796] Generic platform RAM MTD, (c) 2004 Simtec Electronics
1.317849] ONFI param page 0 valid
1.321286] ONFI flash detected
1.324406] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron MT29F1G
08ABBDAHC), page size: 2048, OOB size: 64
1.335350] Bad block table found at page 65472, version 0x01
1.341652] Bad block table found at page 65408, version 0x01
1. ofpart partitions found on MTD device .nand
1.353839] Creating 3 MTD partitions on ".nand":
1.x-0x : "u-boot"
1.x-0x : "params"
1.x-0x : "ubifs"
1.378210] davinci_nand .nand: controller rev. 2.5
1.385151] spi_davinci .spi: master is unqueued, this is deprecated
1.396627] m25p80 spi32766.0: unrecognized JEDEC id 20bb18
1.402144] spi_davinci .spi: Controller at 0xc8886400
1.411193] Initializing USB Mass Storage driver...
1.416251] usbcore: registered new interface driver usb-storage
1.422163] USB Mass Storage support registered.
1.427169] mousedev: PS/2 mouse device common for all mice
1.433274] i2c /dev entries driver
1.438539] usbcore: registered new interface driver usbhid
1.444048] usbhid: USB HID core driver
1.448904] oprofile: using timer interrupt.
1.453217] Netfilter messages via NETLINK v0.30.
1.457862] nf_conntrack version 0.5.0 (1928 buckets, 7712 max)
1.464255] ctnetlink v0.93: registering with nfnetlink.
1.470064] IPv4 over IPv4 tunneling driver
1.475125] gre: GRE over IPv4 demultiplexor driver
1.479929] ip_gre: GRE over IPv4 tunneling driver
1.485851] ip_tables: (C)
Netfilter Core Team
1.491305] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
1.497642] arp_tables: (C) 2002 David S. Miller
1.502261] TCP: cubic registered
1.505545] Initializing XFRM netlink socket
1.510969] NET: Registered protocol family 10
1.516455] NET: Registered protocol family 17
1.520858] NET: Registered protocol family 15
1.21q: 802.1Q VLAN Support v1.8
1.529761] sctp: Hash tables configured (established 4096 bind 4096)
1.536950] NET: Registered protocol family 40
1.541512] rpmsg_proto_init: registered rpmsg network protocol
1.547471] VFP support v0.3: not present
1.551440] Registering SWP/SWPB emulation handler
1.564498] Freeing init memory: 208K
/bin/ash: can' job control turned off
The MCSDK U-boot is based on the Universal Boot Loader (U-boot) public project. The documentation is available on The release is based on upstream v2013.01 U-boot release. This section gives information specific to the TCI6638EVM board and drivers only.
The Keystone EVM board file islocated at board/ti/ks2_evm (for MCSDK 3.0.x, it is located at board/ti/tci6638_evm directory). It has PLL, DDR3 configurations and initialization functions.
The Keystone chip specific code is located at arch/arm/cpu/armv7/keystone directory. It has the following files:
aemif.c – Asynchronous EMIF configuration.
init.c – chip configuration
clock.c – clock related functions
cmd_clock.c, cmd_mon.c, cmd_fmtimg.c – implementation of “psc”, “getclk”, “pllset”, “fmtimg” and “mon_install” shell commands.
psc.c – PSC driver.
cppi_dma.c – simple CPPI_DMA driver.
The Keystone EVM uses the following drivers:
SPI - drivers/spi/davinci_spi.c.
I2C - drivers/i2c/keystone_i2c.c.
UART - serial.c, ns16550.c and serial_ns16550.c at drivers/serial directory.
NAND - drivers/mtd/nand/davinci_nand.c
ETH - drivers/net/keystone_net.c
USB - generic xhci support from patches patchwork.ozlabs.org/patch/193476/ and patchwork.ozlabs.org/patch/193477/. Platform specific xhci support in drivers/usb/host/xhci-keystone.c
The K2HK EVM has 4 Ethernet ports (port 0 - 3) with K2HK_EMAC, K2HK_EMAC1, K2HK_EMAC2, K2HK_EMAC3 interface names. The K2L EVM has 4 Ethernet ports (port 0 - 3) with K2L_EMAC0, K2L_EMAC1, K2L_EMAC2, K2L_EMAC3 interface names.
The "ethact" environment variable selects the currently active Ethernet interface. For example:
set ethact K2HK_EMAC1
selects the port 1 to be used for following network commands.
You may change the active interface on runtime.
The ethact variable is set on start of u-boot to the name of the first registered interface. The TCI6638_EMAC is registered first and therefore ethact is always set to that name. You may want to use another environment variable to set desirable interface. You can do that extending init_${boot} variables.
MAC address of the port 0 is taken from SOC e-fuse. You may want to overwrite it setting the “ethaddr” environment variable. The SoC doesn’t have an e-fuse for second port MAC address. You have to set the “eth1addr” explicitly for that port.
NOTE: U-boot does not allow to change the "ethaddr" variable if it is already set. If you want to change it you need to use the "env default -a" command, which resets all environment variabels to default values and deletes the "ethaddr" variable as well.
The board_k2x.c file has the eth_priv_cfg array, which has the default configuration of the both interfaces.
eth_priv_t eth_priv_cfg[] = {
= &K2HK_EMAC&,
= CPSW_PORT_RX_FLOW(0),
.slave_port
.sgmii_link_type = SGMII_LINK_MAC_PHY,
= &K2HK_EMAC1&,
= CPSW_PORT_RX_FLOW(1),
.slave_port
.sgmii_link_type = SGMII_LINK_MAC_PHY,
= &K2HK_EMAC2&,
= CPSW_PORT_RX_FLOW(2),
.slave_port
.sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
= &K2HK_EMAC3&,
= CPSW_PORT_RX_FLOW(3),
.slave_port
.sgmii_link_type = SGMII_LINK_MAC_MAC_FORCED,
"phy_addr" is the phy address on mdio bus.
"slave_port" is the port number starting from "1"
"sgmii_link_type" - type of SGMII link.
The emac_def.h defines possible sgmii link types
#define SGMII_LINK_MAC_MAC_AUTONEG 0
#define SGMII_LINK_MAC_PHY
#define SGMII_LINK_MAC_MAC_FORCED 2
#define SGMII_LINK_MAC_FIBER
#define SGMII_LINK_MAC_PHY_FORCED 4
By default Ethernet driver assumes that phys are not connected to MDIO bus. Using the “has_mdio” environment variable you may override this default:
“setenv has_mdio 1” – tells the driver that PHYs are connected to MDIO.
If has_mdio=0 or there is no such environment variable the sgmii_link_type for each port is set to SGMII_LINK_MAC_PHY_FORCED. Be aware that the sgmii_link_type for each interface may be overridden by setting the sgmiiN_link_type environment variable. For example:
“setenv sgmii1_link_type 2” -
sets the SGMII_LINK_MAC_MAC_FORCED link type for port 1.
Driver doesn't perform sanity check of the settings. It is your responsibility to set correct values.
The K2 SOC has 4 SGMII port and you can add configurations for port2 and port3 to the eth_priv_cfg[]. Though driver supports four ports, as K2K EVM has only 2 ports the port2 and port3 functionality wasn’t tested.
Network driver supports Multicast tftp. To enable this feature, add following in the respective config.h file (example include/configs/k2hk_evm.h for K2HK)
#define CONFIG_MCAST_TFTP
K2HK and K2E supports 10G ethernet connections through a 3-port (1 host and 2 slaves) 10G ethernet switch.
On K2HK and K2E EVMs, the physical 10G ethernet connection is brought out to a Rear Transition Module-Break Out Card (RTM-BOC).
This implementation supports only the Rev.C RTM-BOC with Dual Retimers.
The U-boot implementation of the 10G ethernet driver can be considered as an extension of the 1G ethernet driver framework.
It adds two interfaces to the data structure eth_priv_cfg[] in the corresponding board_k2x.c files:
eth_priv_t eth_priv_cfg[] = {
= &K2HK_XMAC0&,
.slave_port
.sgmii_link_type = XGMII_LINK_MAC_MAC_FORCED,
= &K2HK_XMAC1&,
.slave_port
.sgmii_link_type = XGMII_LINK_MAC_MAC_FORCED,
with a new interface sgmii_link_type of XGMII_LINK_MAC_MAC_FORCED.
The interface names are K2HK_XMAC0 and K2HK_XMAC1 on K2HK; and K2E_XMAC0 and K2E_XMAC1 on K2E.
From the user perspective, there is no difference in configuring and using the 10G interfaces except that there is no has_mdio or sgmii_link_type setenv settings.
for more configuration details.
When U-boot boots up, it will only show the 10G interface names if the proper RTM-BOC is connected to the EVM.
If so, they are the 4th and 5th (0-based) interfaces on K2HK; and 8th and 9th on K2E.
Hence to properly configure the corresponding MAC addresses, eth4addr and eth5addr on K2HK should be used, while they are eth8addr and eth9addr on K2E .
The keystone_i2c.c driver supports multiple I2C buses. Thus K2 SoC has three buses 0, 1 and 2. Only one bus can be uses at the same time. Use the
int i2c_set_bus_num(unsigned int bus)
function to set desired bus number. You may get the current bus number by calling the
unsigned int i2c_get_bus_num(void)
In order to set/get current bus number from u-boot shell use “i2c dev” command.
TCI6638 EVM # i2c dev
Current bus is 0
TCI6638 EVM # i2c dev 1
Setting bus to 1
TCI6638 EVM #
The NAND driver used is davinci_nand.c. For K2L, NAND part is 2G vs other EVMs that has 512M part. The EVM by default create 3 partitions.
1. bootloader
2. params (env)
3. ubifs. This has boot volume to hold the images and rootfs to volume to hold the file system
UBI boot time is dependent on the ubifs partition size. So on K2L since the size is much bigger, it takes more time because the mount is done on a bigger nand parition. To reduce the boot time customer may resize the partition to a smaller to hold the file system. Additional partitions can be defined to use as data storage or other applications. Same change needs to be reflected in the DTS as well as mtdparts env variable in u-boot.
SPL stands for Secondary Program Loader. This is a framework added to unpstream U-Boot in version 2012-10. SPL is supported in U-Boot for keystone II devices. This feature is configured using the config option CONFIG_SPL. It allows creation of a small first stage boot loader (SPL) that can be loaded by ROM Boot loader (RBL) which would then load and run the second stage boot loader (full version of U-Boot) from NOR or NAND. The required config options are added to tci6638_evm.h. User may refer the README text file in the U-Boot root source directory for more details.
For keystone II, RBL loads SPL image from offset 0 of the SPI NOR flash in spi boot mode. The first 64K of the SPI NOR flash is flashed with SPL followed by u-boot.img. The initial 64K is padded with zeros.
U-Boot build uses ARM thump mode. This is configured using CONFIG_SYS_THUMB_BUILD option.
POST will perform the following functional tests:
EEPROM read test
NAND read test
External memory read/write test
By default the POST is enabled. Set "no_post" environment variable to disable it.
set no_post 1
Note: If needed to disable POST on next reboot, this variable can be saved using saveenv.
Using FDT commands, user will be able to tweak the FDT before boot to Linux. An example of this command usage to enable the PSC module and Power domain for SRIO and Hyperlink IP is discussed here. The device tree bindings for the clock node for these IPs (functional blocks) have the status property defined and set to "disabled" by default. If user wants to enabled this so that user space drivers can be used for these IPs, the status property can be updated in the DTB blob through fdt command before boot to Linux. Following env variables can be set in u-boot to achieve this:-
setenv modify_fdt 'fdt addr ${addr_fdt}; fdt set /soc/clocks/clkhyperlink0
status "enabled"; fdt set /soc/clocks/clkhyperlink1 status "enabled"; fdt
set /soc/clocks/clksrio status "enabled";'
setenv bootcmd 'run init_${boot} get_fdt_${boot} get_mon_${boot} get_kern_${boot}
modify_fdt run_mon run_kern'
User may modify the above based on which IP is to be enabled. In the above example, two hyperlink and one srio IPs are enabled (LPSC module is enabled as well the Power Domain). This command will be useful to fix up DT bindings in the DTB before booting to Linux.
U-Boot has mem_reserve env variable to reserve DDR3 memory at the end of the 32 bit address space. This will be useful for reserving memory for DSP. Based on the memory
availability on the board, the address range of this region will change. So any users of this feature need to make sure the address match with what is reserved through
this mechanism. Otherwise the user application can step into kernel memory space and
cause kernel crash during system operation. By default 512M memory is reserved at the end of the address space. To change the default size, user need to update this env variable and save the configuration using saveenv command.
Boot Monitor software provides secure privilege level execution service for Linux kernel code through SMC calls. ARM cortex A15 requires certain functions to be executed in the PL1 privilege level. Boot monitor code provides this service. A high level architecture of the boot moinitor software is shown below
Boot monitor code is built as a standalone image and is loaded into MSMC SRAM at 0xc5f0000 and occupies top 64K of the memory. The image has to be loaded to the at the above address either through CCS or through tftp or other means. It gets initialized through the u-boot command install_skern. The command takes the load address above as the argument.
In the primary ARM core, ROM boot loader (RBL) code is run on Power on reset. After completing its task, RBL load and run u-boot code in the non secure mode. Boot monitor gets install through the command mon_install(). As part of this following will happen
boot monitor primary core entry point is entered via the branch address 0xc5f0000
As part of non secure entry, boot monitor calls the RBL API (smc #0) through SMC call passing the _skern_init() as the argument. This function get called as part of the RBL code
_skern_init() assembly function copies the RBL stack to its own stack. It initialize the monitor vector and SP to point to its own values. It then calls skern_init() C function to initialize to do Core or CPU specific initialization. r0 points to where it enters from primary core or secondary core, r1 points to the Tetris PSC base address and r2 points to the ARM Arch timer clock rate. RBL enters this code in monitor mode. skern_init() does the following:-
Initialize the arch timer CNTFREQ
Set the secondary core non secure entry point address in the ARM magic address for each core
Configure GIC controller to route IPC interrupts
Finally the control returns to RBL and back to non secure primary core boot monitor entry code.
On the primary core, booting of Linux kernel happens as usual through the bootm command.
At Linux start up, primary core make smc call to power on each of the secondary core. smc call is issued with r0 pointing to the command (0 - power ON). r1 points to the CPU number and r2 to secondary core kernel entry point address. Primary core wait for secondary cores to boot up and then proceeds to rest of booting sequence.
At the secondary core, following squence happens
On power ON reset, RBL initializes. It then enters the secondary entry point address of the boot monitor core. The init code calls smc #0 to invoke _skern_init() as a privilege function and in turn sets its own stack, vectors and smc service functions. _skern_init() calls skern_init() C function to initialize per CPU variables. It initialize the arch timer CNTFREQ to desired value.
On return from _skern_init(), it jumps to the secondary kernel entry point address and start booting secondary instance of Linux kernel.
The DDR3A memory address space is 0xx9FFFFFFFF. That range is outside the first 4GB of address space. Even if Cortex-A15 supports Large Physical Address Extension (LPAE), which allows 40 bits address bus, and may access the DDR3A address space, that is possible only when ARM turns MMU on. Before that ARM has 32-bits effective address bus and can access only first 4GB of address space.
In order to give access to the DDR3A when MMU is off, MSMC maps first 2GB of DDR3A to the 0x-0x00FFFFFFFF address space. That aliased address space of the first 2GB of the DDR3A may be used not only when MMU is off, but when it is on as well. Be aware that Keystone2 doesn’t support cache coherency for the aliased address space.
The memory property in the tci6638-evm.dts file specifies the memory range available for kernel. The default sets 0x as start address and 0x as size. That corresponds to the aliased DDR3A memory range.
When u-boot boots the kernel, it can modify the start address of the “memory” in the DTB. If the “mem_lpae” environment variable is “0”, u-boot doesn’t modify the start address. If the mem_lpae=1, u-boot sets the start address to 0x, which corresponds to non-aliased start address of the DDR3A.
U-boot works without MMU enabled and its address range is limited to the first 4GB. The 2GB of that range is the DDR3A aliased address range. Therefore u-boot without MMU enabled cannot detect more than 2GB of DDR3A size. Kernel works with MMU enabled and when LPAE is enable may use up to 8GB of the DDR3A memory.
To pass the memory size information to the kernel u-boot fixes the memory node of the DTB. If the SO-DIMM size is less or equal 2GB u-boot creates memory node with one bank only:
reg = &0xxxx&;
U-boot may reserve part of the memory at the beginning or end of the first 2GB. If the "mem_reserve_head" variable is set, u-boot modifies the start address and the size of the memory bank on the mem_reserve_head. For example if the mem_reserve_mem=256M u-boot creates the following memory node:
reg = &0xxxx&;
If the mem_reserve variable is set, u-boot reserves the memory at the end of the first bank. For example if the mem_reserve=512M u-boot creates the following memory node:
reg = &0xxxx&;
If the board has SO-DIMM bigger than 2GB user has to set the ddr3a_size environment variable. The variable may be set to 4 or 8. If u-boot detects the 2GB of memory (maximum it may detect), it checks the "mem_lpae" and "ddr3a_size" variables. If the mem_lpae=1 and ddr3a_size=4 or 8, u-boot creates the memory node with two banks. The first bank represents first 2GB of memory with possible reserved memory. The second bank represent the remaining memory. That memory starts at the fixed address and size equal "ddr3a_size - 2".
For example if mem_lpae=1, mem_reserve=512M and ddr3a_size=8 u-boot creates the following memory node:
reg = &0xxxx
It is important that u-boot creates two memory banks. That allows to reserve memory at the first bank (first 2GB of memory). There are SOC masters which have only 32 bit address bus and may access the first 2GB of the DDR3A only.
It is possible to reserve memory at the second bank. A customer has to modify the u-boot ft_board_setup() function to do that.
DDR3 error detection and correction feature is enabled on K2H/K2K PG 2.0 devices and K2L/K2E devices. The DDR3 controller supports ECC on the data written or read from the SDRAM and is enabled by programming the ECC Control register. 8-bit ECC is calculated over 64-bit data quanta. The ECC is calculated for all accesses that are within the address ranges protected by ECC. 1-bit error is correctable by ECC and 2-bit error is not correctable and will be treated as unrecoverable error by sotware and trigger the reset of the device.
U-boot checks if the DDR3 controller supports ECC RMW or not. If ECC RMW is not supported (in K2H/K2K PG1.x devices), U-boot will disable the ECC by default, otherwise it always enables ECC (in K2H/K2K PG2.0 devices and K2L/K2E devices)
During the ECC initialization, U-boot fills the entire memory (up to 8GB) to zeros using an EDMA channel after ECC is enabled. For K2H/K2K/K2L device, U-boot configures the chip level interrupt controller to route the DDR3 ECC error interrupt to ARM interrupt controller. For K2E device, since DDR3 ECC error interrupt is directly routed to ARM interrupt controller, there is no need to configure the chip level interrupt controller.
A new DDR3 command is added to simulate the ECC error, the command format is:
ddr ecc_err &addr in hex& &bit_err in hex& - generate bit errors in DDR data at &addr&, the command will read a 32-bit data from &addr&, and write (data ^ bit_err) back to &addr&
ddr ecc_err 0xx1 (this will genereate a 1-bit error on bit 0 of the data in ddr address 0x)
ddr ecc_err 0xax1001 (this will genereate 2-bit error on bit 0 & 3 of the data in ddr address 0xa000_0000)
A new environment variable "ecc_test" is also introduced to test ECC. By default, ecc_test = 0, and any detection of 2-bit error will reset the device. If ecc_test = 1, U-boot will bypass the error and continues to boot Linux kernel so that Linux kernel can handle the error in interrupt service.
Linux kernel requests an IRQ handler for DDR3 ECC error interrupt, the handler checks the DDR3 controller interrupt status register, if the error is 2-bit error, Linux kernel will reboot the device. User can also use a user mode command to read the DDR3 ECC registers (e.g. 1-bit error count register, etc.), the DDR3 controller register and interrupt mapping are defined in the sysctrl node of device tree binding:
E.g. K2HK SOC device tree:
reg = &0xx0200&; /* DDR3 controller reg */
interrupts = &0 24 0xf01
/* L1L2 ECC error interrupt */
0 448 0xf01&; /* DDR3 ECC error interrupt */
The Keystone II devices runs SMP Linux and is based on upstream Linux version. The Linux port uses arch/arm/mach-keystone for the machine specific intialization code. Linux is boot up through U-boot on the primary ARM core. Linux depends on the Boot Monitor software that gets installed through U-Boot for SMP boot up. Please refer the Boot Monitor section for more details on Linux boot up sequence.
Device Tree bindings are used to define the configuration of the board to use for Linux boot up. This makes it easy for users to define bindings for their custom board so that same image provided in the release may be used to run on their board. Note that any additional peripheral drivers required on the custom board is ther responsobility of the user. User will be able to use the Device Tree bindings to configure the driver. The traditional machine setup code based device initialization support is not available for Keystone devices.
SoC specifc initialization and setup code is located under arch/arm/mach-keystone folder. Here are the basic init done for Keystone II devices.
pmc.c - Power Management Run time init code
platsmp.c - Provides smp_operations for SMP Linux operation. This is where code to Power ON secondary cores resides.
keystone.c - DT_MACHINE_START macro for Keystone I and Keystone II devices are defined in this file. This also does clock, arch timers and Device Tree specific initialization. It provides machine specific restart() function for Linux.
gic irqchip driver is re-used for the Keystone II devices. This the parent irq controller. Most of the peripheral driver bindings include phandle for this irq controller. This driver is currently located under arch/arm/common folder and is moved to drivers/irqchip folder in recent upstream kernel releases. Device bindings for the driver can be found in Linux kernel tree under Documentation/arm/gic.txt
This is the irq controller driver for receiving IPC interrupts from DSPs. It manages the IPCGRx and IPCARx registers for the Host. It uses GIC irq controller as the parent. The bindings are similar to that for GIC. However it uses "interrupts" property in the bindings to define the parent interrupt line to the GIC interrupt controller. Two cells are used to identify an interrupt line to IPC IRQ chip. Up to 28 interrupt lines (Logical) are terminated on this device and maps to bits of the above IPC registers. One user of this driver is the remote proc user driver that uses these interrupts to receive interrupts from DSPs. The bindings for rproc user driver provides "interrupts" property to identify the specific interrupts terminated on this device.
SMP Linux boot support is implemented in U-Boot, Boot Monitor and Linux. In the U-Boot, a command mon_install() is added to allow initialization of boot monitor. This command is to be included in bootcmd as part of U-Boot environment setup. This command assumes that boot monitor image is loaded in MSMC Memory prior to the invokation of the command. More details on Boot Monitor is provided elsewhere in this document. Linux platform code uses the SMC calls to inoke monitor services provided by boot monitor, for example smc call to Power ON secondary core is one such service.
In this release, all of the clock hardware nodes in the platform are represented in device tree. Here is the high level view of the clock tree
refclkmain (fixed clock)
- mainpllclk (Main PLL clock)
- mainmuxclk (Mux clock)
- chipclk1 (chip fixed factor clocks)
- clkusb (PSC clocks)
Please refer the Device data manual for the description of various clocks available on the SoC. The devices gets the Main PLL input clock from the external source. The refclkmain represents this fixed clock. Main PLL output clock is represented bu mainpllclk node. The output of this clock is fed to the mainmuxclk which can either select refclk directly (bypassing the Main PLL) or the output of the Main PLL to pass to the next stage which are divider clocks. The SYSCLKx are the divider clocks that then gets distributed to various IPs. The PSC clocks represents the LPSC (local power sleep controller) availale for individual IPs.
The driver for each of the above clock device is shown below
1. fixed clock - example refclkmain
drivers/clk/clk-fixed-rate.c
2. Main PLL clock - example mainpllclk
drivers/clk/clk-keystone-pll.c
3. (Mux clock) - example mainmuxclk
drivers/clk/clk-mux.c
4. fixed factor clocks (example chipclk1)
drivers/clk/clk-fixed-factor.c
5. Psc clocks (example - clkusb)
drivers/clk/davinci/clk-davinci-psc.c
6. Common clock init code
drivers/clk/davinci/davinci-clock.c
More details on common clock framework is part of Linux kernel documentation at Documentation/clk.txt Device clock bindings are documented at Documentation/devicetree/bindings/clock/*
The common clock code is enable through the CONFIG_COMMON_CLK KConfig option.
There are debugfs entries for each clock node to display the rates, usecounts etc. This replace the old debugfs entry to display the clock information. For example to show the main PLL clock rate, use the following command
root@tci6614-evm:~# mount -t debugfs debugfs /debug
root@tci6638-evm:~# cat /sys/kernel/debug/clk/refclk-main/mainpllclk/clk_rate
DaVinci AEMIF driver is re-used for Keystone devices. The driver is implemented in drivers/memory/davinci-aemif.c. The binding definitions are given in Documentation/devicetree/bindings/memory/davinci-aemif.txt. This driver allows configuration of the AEMIF bus connected to slave devices such as NAND. The bindings exposes the timing parameters required for the slave device.
Davinci NAND controller driver is re-used for the Keystone devices. The required bindings are defined under Documentation/devicetree/bindings/mtd/davinci-nand.txt. Driver file is drivers/mtd/nand/davinci_nand.c
DaVinci SPI controller driver is re-used for keystone devices. Driver is implemented in drivers/spi/spi-davinci.c and the bindings in Documentation/devicetree/bindings/spi/spi-davinci.txt. The SPI NOR flash driver used is m25p80.c under drivers/mtd/devices/m25p80.c. The bindings for this driver is available under Documentation/devicetree/bindings/mtd/st-m25p.txt
DaVinci I2C controller driver is re-used for Keystone devices. The driver file is drivers/i2c/chip/i2c-davinci.c and the binding is defined in Documentation/devicetree/bindings/i2c/davinci.txt. EEPROM driver is a i2c client driver and is implemented in drivers/misc/eeprom/at24.c. The binding for this is also part of the davinci i2c driver bindings.
GPIO driver is implemented in drivers/gpio/gpio-keystone.c. Each instance of the driver support 32 GPIO pins (2 Banks). Currently only 2 banks are tested on keystone devices. The driver also implements gpio irq chip driver that exposes gpio pin as irq pins and maps them to the corresponding irq pins input of GIC. This driver allow user drivers to define the GPIO pins that it uses as bindings and points to the bindings of this device. Also allows user driver to use a GPIO pin as interrupt. The irq chip driver supports upto 32 irq pins. Driver uses the pin as irq or GPIO, not both. Please refer to bindings documenation at Documentation/devicetree/gpio/gpio-keystone.txt for details of usage. Note that user driver can also use the GPIO pins using the GPIO LIB APIs. User needs to choose either defining the GPIOs through bindings or using API, and not both for a specific pin.
Keystone IPC GPIO driver exposes IRQs to DSPs (using IPCGRx register of each DSP) as GPIO pins. Software users allocates a GPIO pin using GPIO lib API or using a gpio bindings in the driver using phandle to the corresponding gpio ipc device binding. This driver allows defining one instance of the GPIO driver per DSP and allows up to 28 GPIO pins per GPIO instance. The bindings for each instance is defined in the dts file for the platform. The driver is implemented in drivers/gpio/gpio-keystone-ipc.c. Documentation/devicetree/bindings/gpio/gpio.txt has description on how to define bindings in the user driver to use a GPIO pin. The user driver uses GPIO lib API calls to write a value of 1 to the GPIO output pin that will raise IRQ to the DSP.
The Watchdog driver is implemented in drivers/watchdog/davinci_wdt.c. For an explanation on the device tree bindings required see Documentation/devicetree/bindings/watchdog/davinci-wdt.txt.
The NETCP driver code is at /drivers/net/ethernet/ti/keystone_net_core.c in the linux kernel.
On device open, we request DMA channels using standard dma engine APIs provided by the dmaengine layer. The capabilities of the DMA are appropriately set and the appropriate channels are requested by name. We invoke the dma_request_channel_by_name API to acquire dma engine channels. The netdev open also sets up the streaming switch, SGMII, Serdes, switch and mac sliver. On Open we also configure the packet accelerator module.
A standard netdev stop operation that stops the netif queue. It sets the receive state to teardown and calls dmaengine_pause APIs from the dmaengine layer to pause both the RX and TX channel. After NAPI is disabled, the operation goes onto release the dma channels by calling the dma_release_channel API. The RX state is set to invalid and the ethernet susbsystem is stopped
3) Polling
A NAPI poll function is implemented, which sets the RX state to poll and resume the dma engine. It will then go onto initialize the queues. We allocate memory for each packet and initialize the scatter list. We iterate in a loop till we run out memory for the descriptors. These dma descriptors are acquired using a dmaengine API called device_prep_slave_sg. We pass appropriate arguments to the API. At this instant we are not concerned about the Software info and PS info associated with each descriptor. netcp_rx_complete is the callback associated with the dma engine on the RX side. The callback function checks for the correct DMA and RX state and warns the user on seeing abnormal behavior. It then goes onto stahs the received packet to the tail of a linked list.
netcp_ndo_start_xmit is the standard netdev operation that is used to push an outgoing packet. Again we have a structure for each packet. This will contain an array of scatterlists and the number of scatterlist entries which at this point should be 1. We then call the device_prep_slave_sg API with appropriate parameters to acquire a descriptor for the TX operation. 'netcp_tx_complete' is the callback fucntion attached to each TX dma callback. All the network statistics are appropriately updated on a successful transfer. The callback then proceeds to free the skb with the dev_kfree_skb_any API.
5) Receive
In the napi_poll netdev operation, we call the netcp_refill_rx function which will allocate skbs and attch these skbs to a descriptor until we run out of descriptor memory. the deliver_stash routine fills the appropriate RX
The PktDMA interface is an extension of the Linux DMA Engine subsystem. It is worth reviewing the following documentation found in the kernel source tree
Documentation/dmaengine.txt
Documentation/devicetree/bindings/dma/keystone-pktdma.txt
Device Tree Requirements
Each PktDMA channel must be defined in the device tree prior to use. The device tree channel description associates the channel with one or more hardware queues that must also be described in the device tree.The PktDMA code generally identifies a device tree description by the channel label string. For example, the Keystone Ethernet driver uses two channels, named “nettx” and “netrx”, used for outbound and inbound traffic respectively. Transmit channels must define the “submit-queue” tag, while receive channels must define the “flow” tag.
DMA Channel Configuration
First, open a DMA channel by calling dma_request_channel_by_name(), passing in a mask requesting the DMA_SLAVE capability and the desired channel name. The returned pointer is used as a handle for all subsequent operations on the channel.Note that while a NULL pointer indicates an error, there are non-NULL values that
use the IS_ERR_OR_NULL() macro to test the returned value. &The next step is to configure the channel using the dma_keystone_config() function, which takes a dma_keystone_info structure. The fields that must be filled in depend on whether the channel is to be used as a transmit or receive channel. In both cases, all unused fields must be zero.
For a transmit channel, set these fields:
Set the direction field to DMA_MEM_TO_DEV.
Set the tx_queue_depth field to the the number of transmit buffers that can be outstanding at any one time.
Attempting to prepare a buffer or chain of buffers for transmission when there is insufficient depth remaining will result in an error.
For a receive channel, set these fields:
Set the direction field to DMA_DEV_TO_MEM.
Set the scatterlist_size field to the number of entries in the array of scatterlist structures that will be used for reception. If the application does not support scatter/gather, then this will be between 1 and 3.
Set the rxpool_allocator field to be a pointer to a function that the DMA engine will call to replenish the pool of free receive buffers.
Set the rxpool_destructor field to be a pointer to a function that the DMA engine will call to free the pool of free receive buffers during channel shutdown and certain error conditions.
The rxpool_param field is a pointer to a void that is passed to the rxpool allocator and destructor functions to make them easier to write. The PktDMA subsystem makes no other use of this field.
Set the rxpool_thresh_enable field to DMA_THRESH_NONE. In the future the PktDMA interface will support selection of free buffer queue by packet size, but this is not currently supported.
The rxpools array determines how the four free buffer queues are configured. If neither scatter/gather nor size thresholds are being used, fill in only the first entry in the array (rxpools[0]); this is likely to be the normal case. Each entry contains a buffer size and desired pool depth. If using packet size thresholds, the array must be filled in from smallest to largest.
Set the rxpool_count to the number of rxpo