linux for tegra (l4t) os pack quickstart guide -...

- 1 - October 2010

Linux For Tegra (L4T) OS Pack Quickstart Guide

Version 10.9.3

October 2010 - ii -

Contents

INTRODUCTION 1

INITIAL DEVKIT & HOST SETUP 3

LINUX FOR TEGRA INSTALLATION AND CONFIGURATION 5

PREPARING THE ROOT FILESYSTEM 6

FLASHING THE BOOTLOADER AND KERNEL 10

BOOTING THE DEVKIT FOR THE FIRST TIME 13

DEVKIT INTERNET ACCESS 15

RUNNING TEST APPLICATIONS 17

WORKING WITH X11 20

APPENDIX A: CROSS-COMPILING FOR TEGRA 23

APPENDIX B: BUILDING THE NVIDIA TEGRA KERNEL 24

APPENDIX C: INSTALLING ADVANCED X11 DESKTOPS 27

APPENDIX D: CUSTOM ROOT FILESYSTEMS 28

APPENDIX E: SAMPLE BOOT TRANSCRIPT 29

October 2010 - 1 -

Introduction

The NVIDIA Linux For Tegra pack (or ‘L4T’) is designed to support a wide range of Tegra

software developers. This documentation will not attempt to cover all use cases and aspects of

a Linux environment for Tegra. Instead, it will focus upon specific steps needed to enable

application-level software developers to boot Linux on their Tegra development kit hardware as

quickly as possible. It is a quick-start guide that follows one particular path in the installation

and setup process.

The L4T pack consists of:

A bootloader

A prebuilt kernel image

A sample root filesystem

Binary Tegra device drivers

Helper scripts for the setup process

The bootloader and kernel are generally ‚flashed‛ into NAND flash on the device. The root

filesystem can reside on an SD card, on a USB hard drive, in the devkit’s built-in NAND flash

itself (limited to smaller ‚minimal‛ filesystems) or on an NFS share served by the host

development PC. This documentation will focus primarily on USB- and SD-based filesystems

(owing to their relative simplicity of setup).

The basic boot and usage stages are as follows:

1) The device is powered on

2) The bootloader loads kernel image and arguments from NAND, and starts the kernel

3) The kernel loads basic drivers, including those for accessing data storage devices, and tries

to mount the root file system from the device specified in the kernel arguments (currently,

kernel arguments are specified at flash time).

4) The kernel boots the Linux root file system

5) Once booted, the user can interact with the booted devkit via a serial console, via secure

shell (ssh) over a network connection from the host PC to the devkit, or using the local

console on the device screen.

Note: The on-screen device console will be disconnected by any applications using

/dev/fb or multimedia rendering, and may not reappear until reboot.

October 2010 - 2 -

6) If configured, an X11 environment and window manager can be launched, and then the user

can interact with the devkit using USB mouse and keyboard.

Files can be transferred to the devkit using SCP/SFTP to the device, or secondary storage (such

as an SD card, when booted off of a USB drive). Additionally, advanced users can configure a

remote NFS mount to share directly between the host PC and the devkit. However, NFS shares

are outside the scope of this guide.

Described at a high level, the ‘getting started’ steps are as follows:

1) Unpack and connect the Tegra 250 devkit hardware

2) Set up the developer-provided host development PC (desktop or notebook) and ensure that

it meets the minimum set of required hardware features

3) Set up the root filesystem for booting

4) ‚Flash‛ the Linux bootloader and kernel onto the devkit

5) Boot the devkit for the first time

6) Interact with the devkit shell using the serial console, secure remote shell or local X11

environment

October 2010 - 3 -

Initial Devkit & Host Setup

Setting up the Tegra 250

Please consult the Tegra 250 devkit setup guide for information on how to assemble the devkit

and connect the USB cable between the devkit and the host PC. The guide may be found at the

Tegra developers site:

http://developer.download.nvidia.com/tegra/docs/tegra_250_hw_setup.pdf

In addition, an SD card or a USB drive is required to serve as the devkit’s root file system

storage. While a 1GB device will fit the initial root filesystem, it doesn’t allow much room for

expansion via apt-get – thus, we usually recommend storage devices of 2-4GB in size, even

larger depending on your goals.

This manual also describes several other common accessories that may be connected to the

Tegra 250 devkit. This list does not include connections between the host PC and devkit.

Recommended accesories include:

A powered USB hub

USB keyboard attached to the USB hub

USB mouse attached to the USB hub

VGA (15-pin D-Sub)- or HDMI-connected external display

Wired or Wireless ethernet connectivity from the devkit to the Internet, if you wish to

use apt-get to install further tools & software, or otherwise access Internet resources.

Setting up the Host PC

Minimum Host PC Hardware Requirements

Running Ubuntu 9.04, 9.10, or 10.04 (9.04 has had the most testing). While other Linux

distros may work, few other than Ubuntu have been tested.

A host PC connection to the Internet is required to install development tools or

networking components.

The PC must include an available 9-pin serial port. If you don’t have one built-in, you

can purchase a USB-to-serial adapter on Amazon or through most technology stores

(note you still need the null-modem cable, the adapter simply replaces a built-in port).

A null-modem 9-pin serial cable long enough to reach from the Tegra devkit’s built-in

serial port (which may be found on its expansion board) to the host PC.


October 2010 - 4 -

Ubuntu Host OS Setup

The basics of installing/setting up Ubuntu on a host PC are well outside the scope of this

document, but is a topic well-covered on the Internet.

One specific topic we’ll touch on quickly is if you are running a 64-bit Ubuntu installation on

the host PC, the L4T pack requires you have 32-bit runtime support also installed. The simple

steps for installing 32-bit support on an Ubuntu host using apt-get is to run the following from a

command-line shell:

sudo apt-get update

sudo apt-get install ia32-libs

If ia32-libs is not installed, flashing the devkit with the Linux kernel (and possibly other

steps in the process) will fail.

Connecting the Host PC and the Devkit

The steps are as follows. Note that this does not include the USB connection between the host

PC and the devkit, as that will be discussed when flashing the devkit. The connections listed in

this section are specific to the Linux boot and run sequence described earlier in this document.

1) Connect the serial port on the host PC to the serial port on the mini-satellite board of the

Tegra devkit using the null-modem cable

2) Connect the built-in Ethernet jack on the Tegra devkit to a router if you wish to have wired

internet access from the device. (Note that Wifi is available as an alternative, both wired

and wireless setup details are covered in the Devkit Internet Access section.)

Linux Pack Setup

There are a few basic steps to setting up the L4T pack on the host PC and devkit:

1) Install the L4T pack on the host PC

2) Configure the Ubuntu host PC

3) Prepare the Root Filesystem for booting

4) Flash the bootloader and kernel to the devkit

5) Final configuration and first booting of the devkit

The sections that follow will walk you through these steps.

October 2010 - 5 -

Linux For Tegra Installation and Configuration

Initial Installation

The SDK comes in a single .run archive, which is a self-extracting installer file:

linux_for_tegra_os_pack_<RELEASE_NUMBER>.run

linux_for_tegra_quickstart.pdf

Transfer these files to the directory on your Linux host PC where you wish to install the L4T

pack. To install, step through the instructions that follow

1) From a command shell, run:

bash linux_for_tegra_os_pack_<RELEASE_NUMBER>.run

2) Read and accept the license terms (typing ‚yes‛ to the question at the end of the license if

the license terms are acceptable and you wish to continue installation).

3) This creates a linux4tegra subdirectory with the contents of the L4T pack. Change into

that new linux4tegra directory:

cd linux4tegra

4) Then execute the following command:

export L4TROOT=${PWD}

Note: This sets the L4TROOT to be the absolute path to the linux4tegra directory, in

order to simplify instructions throughout the rest of this document.

Ubuntu Host PC Serial Configuration

The host PC should have a serial terminal emulator such as minicom or PuTTY with the serial

device corresponding to the serial port connecting the host PC and Tegra devkit. The settings to

be used for a terminal emulator program with the L4T pack are as follows:

baudrate 115200

bits 8

parity N

stopbits 1

flow control None

Note that there really is no flow control – if you try to push data across the wire too quickly, you

will likely lose some. This can occur if you try to ‘copy and paste’ long commands into a serial

console app – should you try to do that, watch for a character or two missing in the output.

October 2010 - 6 -

Preparing the Root Filesystem

This section will walk you through how to set up a bootable device with the enclosed sample

root filesystem. Custom filesystems and other boot media will not be covered in this section.

Selecting Boot Media

There are several options to consider when selecting standalone boot media. The most

important are performance, external power requirements and size. The following table lists

some of the considerations. Each category is ranked from 1 (best) to 3 (least preferable).

SD Card USB Thumb Drive USB Hard Drive

Read/Write

Performance

3

(depends upon card speed)

2 1

Size /

Portability

1

(internal devkit slot)

2

(w/o USB hub)

3

(hub / ext. power)

Power

Requirements

1

(internally powered)

2

(USB hub preferred)

3

(hub / ext. power)

During initial setup, we frequently use SD cards in USB adapters, as we can then opt to move

from USB boot to SD boot from the same exact card, once it is up and running properly. Thus,

most of our setup process will assume use of a USB device.

Longer-term, moving to SD boot keeps open all USB ports, and using the internal slot means

your boot media doesn’t protrude from the board. You can always work with a USB flash drive

to start with, and then copy the filesystem from the drive off to an SD card, once you have it all

working the way that you like it.

Developers requiring maximum bandwidth to/from and reliability of the root filesystem (e.g.

compiling code on the devkit itself, running large/complex applications that cause pagefile

thrash), will generally be best off placing the filesystem on a (self-powered) USB hard drive.

Unpack and Prepare Root Filesystem

Included in the L4T pack is a sample filesystem archive that should serve as a good starting

point for most users’ needs. To prepare the filesystem for use, you need to:

1) Running the unpack helper script on the sample filesystem archive, like:

./unpack_targetfs.sh

October 2010 - 7 -

The script doesn’t require any arguments, as it defaults to unpacking the built-in sample root

filesystem to $L4TROOT/linux4tegra/_out/targetfs/.

2) Next, copy the NV-specific files to the right places in the filesystem, using the helper script:

./apply_l4t.sh

Note this is its own script/step for those advanced users who may want to try to ‘apply’ the

L4T binaries to a custom filesystem.

Connect Boot Media to Ubuntu Host

The following instructions assume that the intended boot media is connected to the host PC for

setup via USB (e.g. a USB hard drive, SD card adapter, etc.). The device may auto-mount

depending on your OS. In order to be able to format and copy to the boot media, we need to

determine the Linux device name first. Two possible methods are:

1) Read through the system logs, using a command like:

tail /var/log/syslog

This results in a printout something like:

Jun 16 15:14:31 ubuntu-desktop kernel: [1522718.780171] sd 10:0:0:0: [sdc] Assuming drive cache: write through

Jun 16 15:14:31 ubuntu-desktop kernel: [1522718.780177] sdc:

Jun 16 15:14:31 ubuntu-desktop kernel: [1522718.805373] sd 10:0:0:0: [sdc] Attached SCSI removable disk

Jun 16 15:14:31 ubuntu-desktop kernel: [1522718.813673] sd 10:0:0:0: Attached scsi generic sg2 type 0

Jun 16 15:14:42 ubuntu-desktop hald: mounted /dev/sdc on behalf of uid 1000

The two red lines indicate that the USB storage device is /dev/sdc. Note that the lack of a

trailing number on the sdc device name indicates this is the raw device. Partitioned devices

will appear as sdc1, sdc2, etc. The second red line indicates the device was auto-mounted.

2) An alternative device identification method if the drive did auto-mount is:

sudo mount

Typically on Ubuntu, near the end of the printout you’ll see a line for /media/disk, like:

/dev/sdc on /media/disk type ext3 (rw,nosuid,nodev,uhelper=hal)

Again, this indicates the device name is /dev/sdc.

The remainder of this section will assume that the host machine USB device is /dev/sdc.

Substitute this with the device listed in syslog or mount as appropriate.

Prepare Boot Device and Copy Filesystem

The default bootloader is set up to boot from the first partition of a device (and NOT the whole

device). Thus, you may need to use fdisk to set up one partition (or more) on the device. If

you have a partitioned device with a primary ext3 partition, you can skip to the next section.

October 2010 - 8 -

Note: The USB drive or SD card you use should contain no preexisting data of any value. The instructions below EXPLICITLY erase all partitions on the device, and will COMPLETELY destroy all data on the device. EXERCISE EXTREME CAUTION.

Assuming you know it is safe to wipe the device, the basic steps to prepare a boot device are as

follows. Reminder to you use your device name where we reference /dev/sdc.

1) If the device did auto-mount, you must unmount it via the Ubuntu UI, or via the command:

sudo umount /dev/sdc

2) Run the fdisk program (reminder: use your device name here instead of sdc):

sudo fdisk /dev/sdc

To then create a single new partition on the device, in fdisk you should:

a. Type ‘o’ (and enter) to reset to a blank partition table.

b. Type ‘n’ (and enter) to add a new partition.

c. Type ‘p’ (and enter) to set the new partition as a primary partition, and then ‘1’

(and enter) to set it as the first partition

d. For the first and last cylinder prompts, press enter to accept the default for each.

e. Finally, type ‘w’ (and enter) to write the partition table out and exit fdisk.

3) To format the first partition on the device as an ext3 filesystem, use:

sudo mkfs.ext3 /dev/sdc1

4) Now, we need to mount (or re-mount) the boot device on the host. If you don’t already

have a known mount point, create one now using:

sudo mkdir /mnt/disk

5) To mount the partition, use:

sudo mount /dev/sdc1 /mnt/disk

6) Then, copy the target filesystem to the device (note the arguments are important as they

preserve filesystem attributes). Assuming you are following the default directions, use:

sudo cp -rfp _out/targetfs/* /mnt/disk

7) Finally, unmount the drive, and wait for it to complete (since it will block, waiting for the

previously-launched copy to finish):

sudo umount /mnt/disk

Then, unplug the boot device from host PC, and plug direct into USB slot on the devkit (as

we’re assuming a USB device). This should end up as /dev/sda1 on the Tegra devkit.

October 2010 - 9 -

Alternative Boot Device Setup

For advanced users, the L4T now includes a script that attempts to automate the previous seven

steps for you. To use it, you just need the device name, and run:

./mkfs_l4t.sh <boot_device> [part|format]

The boot_device is a simplified specifier, so for /dev/sdc just give sdc, leave off the /dev/

portion. For ‘format’, or no second argument, boot_device needs a partition index, like sdc1.

The secondary partitioning/formatting argument is optional. Specify ‘part’ to re-partition the

device and format it as well. If your device is already partitioned, you can instead just use

‘format’ to leave the partitioning as-is, but have it auto-format the partition as ext3.

Note: The script will ask you to confirm by typing „yes‟ at least once before it continues

as a safety precaution – sometimes it will prompt twice, depending on arguments.

If you don’t want to repartition or format the device, just don’t specify any second argument,

the script will simply setup the device and start to copy the root filesystem to the device.

As noted above, if you specify ‘format’, or don’t specify any optional argument, you should

give a specific partition name rather than the raw device – i.e., specify sdc2 instead of just sdc,

if you know you want to use the second partition for a particular reason.

October 2010 - 10 -

Flashing the Bootloader and Kernel

Preparing the Devkit for Flashing

Before running the flash scripts, place the devkit into recovery mode as described in the Tegra

250 Devkit Setup Guide:


Connect the USB cable as described in that document to a USB port on the Ubuntu host PC.

In addition, at this point, the desired display-out connection must be chosen. The Linux kernel

supports either VGA-out (also known as ‚CRT‛) or HDMI-out. Select the desired display

device and connect it to the devkit.

Flashing the Devkit

Assuming that the devkit is in recovery mode and connected via a USB-to-mini-USB cable to the

host PC, the steps to flash the devkit are as follows:

1) Make sure your shell has you in the root directory of the L4T pack (‚cd $L4TROOT‛).

2) Run the flash_l4t.sh script, which must include a command-line argument for the

desired boot device, and may be given an optional display adapter name (default is

CRT/VGA port). For boot devices, we’ll only focus on ‚usb‛ (flash-based USB drives or

actual hard disk drives) and ‚sdmmc‛ (SD/SDHC memory cards) at this time. Two examples

might be:

a. For CRT display, booting off USB attached drive:

./flash_l4t.sh usb crt

b. For HDMI display, booting off SD card in spring-loaded slot:

./flash_l4t.sh sdmmc hdmi

3) Following a successful flashing process, it is suggested to disconnect the USB cable between

the host PC and the devkit, as on certain systems/setups it might be seen as a network-over-

USB connection.

The resulting output should be similar to the following:

$ ./flash_l4t.sh sdmmc crt

Using root device: sdmmc

Using boot display: crt

>---<

Using default kernel: /home/dchait/ldk/linux4tegra/prebuilt/zImage

Please set KERNEL_IMAGE if you want to use another kernel.


October 2010 - 11 -

>---<

Using default bootloader: /home/dchait/ldk/linux4tegra/prebuilt/fastboot.stock.bin

Please set BOOTLOADER if you want to use another bootloader.

>---<

Using default fastboot app: /home/dchait/ldk/linux4tegra/prebuilt/fastboot

Please set FASTBOOT if you want to use another fastboot app.

>---<

Power ON the board by pressing the power button.

Then connect the board to your host PC.

Press Enter to continue.

>---<

Keep the Recovery button pressed, and then press and release the

Reset button. Then, release the Recovery button.

Press Enter to continue.

>---<

Flashing the bootloader...

Nvflash started

rcm version 0X20001

System Information:

chip name: t20

chip id: 0x20 major: 1 minor: 2

chip sku: 0x8

chip uid: 0x097c81c641a13097

macrovision: disabled

hdcp: enabled

sbk burned: false

dk burned: false

boot device: nand

operating mode: 3

device config strap: 0

device config fuse: 0

sdram config strap: 0

sending file: harmony_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct

- 4080/4080 bytes sent

harmony_a02_12Mhz_H5PS1G83EFR-S6C_333Mhz_1GB_2K8Nand_HY27UF084G2B-TP.bct sent successfully

odm data: 0x3b3d8011

downloading bootloader -- load address: 0x108000 entry point: 0x108000

sending file: fastboot.bin

| 936016/936016 bytes sent

fastboot.bin sent successfully

waiting for bootloader to initialize

bootloader downloaded successfully

setting device: 1 0

creating partition: BCT

creating partition: PT

creating partition: EBT

creating partition: UIP

creating partition: USP

creating partition: SOS

creating partition: LNX

creating partition: MBR

Formatting partition 2 BCT please wait.. done!

Formatting partition 3 PT please wait.. done!

Formatting partition 4 EBT please wait.. done!

Formatting partition 5 UIP please wait.. done!

Formatting partition 6 USP please wait.. done!

Formatting partition 7 SOS please wait.. done!

October 2010 - 12 -

Formatting partition 8 LNX please wait.. done!

Formatting partition 9 MBR please wait.. done!

done!

sending file: fastboot.bin

| 936016/936016 bytes sent

fastboot.bin sent successfully

... done.

Flashing the kernel...

creating boot image...

creating boot image - 2949120 bytes

< waiting for device >

sending 'boot' (2880 KB)... OKAY

writing 'boot'... OKAY

... done.

Flashing completed.

Make the target filesystem available to the device and reset the board to boot.

Troubleshooting the Flashing Process

The most common failure is either a devkit not properly connected, or a devkit not booted in

recovery mode.

Disconnected Devkit: “USB device not found”

In the case of a disconnected devkit, the output might look something like the following:


Nvflash started

USB device not found !!! Failed to flash bootloader.

In this case, reboot the device into recovery mode as described in the devkit guide, and re-plug

the USB cable between the host PC and the devkit.

Devkit Not in Recovery Mode: “UnKnown device found”

A related failure can occur if a board is flashed and then immediately attempted to be flashed

again without rebooting. In this case, the failure message may be slightly different as the device

is actually still connected to the host:


Nvflash started

UnKnown device found

!!! Failed to flash bootloader.

In this case, reboot the device into recovery mode as described in the devkit guide and connect

the USB cable.

Missing 32-bit Support

If you get an error that the file nvflash cannot be found, and are running a 64-bit Linux

installation, you may have missed the setup instructions earlier in the document regarding the

package ia32-libs. Please refer to those notes at this time.

October 2010 - 13 -

Booting the Devkit for the First Time

Once the root filesystem is set up and copied to chosen boot media, which is then connected to

the devkit, and the devkit has been flashed with bootloader and kernel, it should be possible to

boot the devkit by cycling the power or pressing the RESET button.

Note: Take care to ensure that the media used for the boot device is read-write! If the media is write-protected for any reason, the kernel will crash while mounting the root filesystem. The devkit SD card slots have particularly strong write-protect tab springs and can slide the tab on some well-worn SD cards to “read only”.

For the initial boot cycle in particular, it is important to have a serial connection terminal to the

devkit open to view the boot log. This can be done using minicom, or any similar serial

terminal utility. This is useful, even mandatory, for debugging initial boot issues, as well as for

logging in to a booted board without having to set up a network connection and use ssh.

Once the devkit is switched on, the boot logging should begin to scroll through the serial

terminal.

Note: On some bootloader/kernel pairs, the serial port settings will differ between the bootloader and the kernel. You may see scrambled characters during initial

powerup, but once the kernel begins booting, the logging should be legible.

The key lines to wait for in the boot log look something like:

[42949391.880000] EXT3 FS on sda1, internal journal

[42949391.890000] EXT3-fs: mounted filesystem with ordered data mode.

[42949391.890000] VFS: Mounted root (ext3 filesystem) on device 8:1.

[42949391.900000] Freeing init memory: 132K

At which point the root filesystem has been mounted (the device will differ for SD cards), and

begin its bootup process.

Eventually, you will see the login prompt:

Ubuntu 9.04 tegra-ubuntu ttyS0

tegra-ubuntu login:

At this time, you should be able to log in as user ‘ubuntu’, password ‘ubuntu’, and get full bash

shell access to the devkit.

October 2010 - 14 -

Common Issues with USB/SD Booting

The most common boot failure/issue is the kernel having the wrong boot device name supplied

to it. In the case of the flash_l4t.sh helper script, the actual device names are hidden in the

script, dependent upon a lookup based on the first argument to the script. So either the wrong

boot type selection was given to the script, or the right boot medium was selected but is

inaccessible. Either case leads to a devkit boot output log similar to the following:

[42949391.880000] VFS: Cannot open root device "sda1" or unknown-block(2,0)

[42949391.890000] Please append a correct "root=" boot option; here are the available partitions:

[42949391.900000] 1f00 5120 mtdblock0 (driver?)

[42949391.910000] 1f01 8192 mtdblock1 (driver?)

[42949391.910000] b300 3922432 mmcblk0 driver: mmcblk

[42949391.920000] b301 3920849 mmcblk0p1

[42949391.920000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

The failure here was intentional to show a common mistake. In this case, ‘usb’ was supplied to

the helper script, which translates to ‘sda1’ being sent as the boot device name. The device set

up for booting is actually an SD card in a USB reader attached to the host PC, but then rather

than using the USB adapter, was direct plugged into the devkit’s own SD slot. In the above log,

this is made clear as ‚mmcblk0p1‛ is listed as an available boot partition, which is the complex

kernel naming for the first partition on a direct-plugged SD card.

The reverse would be true as well: if you used ‘sdmmc’ for the helper script, and built your

filesystem on an SD card, but then plugged in to the devkit using a USB adapter, the boot

would crash, and log would list ‚sda1‛ as available.

Another common error would be skipping the partitioning step, and instead formatting the

‘raw’ device as ext3, without a partition. On the host, instead of say /dev/sdc1, you’d get

/dev/sdc (no ‘1’). The current bootloader requires a partitioned device.

A last potential error is that you have flashed for a USB device, but have TWO such devices

plugged into the devkit at boot. In that case, it is possible that the ‘real’ boot device is getting

/dev/sdb1 instead of /dev/sda1 – again, if you review the end of the boot log, it should be

pretty clear if that’s the case. We’d generally recommend you not boot with the second device

plugged in (as order is not necessarily static/guaranteed).

Finally, check if the boot media has somehow been switched to read-only or write-protect mode

(e.g. sliding the write-protect tab). If the root filesystem media is marked as read-only, the

kernel will crash when it tries to mount the device.

October 2010 - 15 -

Devkit Internet Access

Wired Network

For connecting the devkit to a wired LAN (assuming the LAN serves DHCP):

1) Connect a network cable from the on-board Ethernet jack to the desired LAN

2) Boot the devkit

3) Enable DHCP by issuing the following command on the devkit (via serial or ssh):

sudo dhclient

However, this only lasts for one boot. If you’d like to make the devkit automatically enable its

Ethernet connection with DHCP on every boot, you can:

1) Open the file /etc/network/interfaces with editor of your choice (vi is preinstalled on

device, you can apt-get install emacs, or you can edit it on host PC).

2) Add the following lines

auto usb0

iface usb0 inet dhcp

For clarity, the onboard Ethernet port is correctly noted as usb0 (not the more common eth0).

Wireless Network

You can also establish internet access by using the WLAN adapter:

1) Start up the WLAN kernel driver on the devkit:

sudo insmod /system/lib/hw/wlan/ar6000.ko

2) Enable the wlan interface:

sudo ifconfig wlan0 up

3) Configure wlan0 for your Wifi network using wpa_supplicant. Included in the sample

filesystem is a skeleton /etc/wpa_supplicant.conf, but for details on config setup, please

refer to documentation for wpa_supplicant on the internet. Launch using:

sudo wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -B

4) If you use DHCP instead of a static IP address, get your dynamic address via:

sudo dhclient

Note: We‟ve provided a shell script that will do all the steps for you (other than editing the wpa_supplicant.conf file). Simply run: ./start_wifi.sh

October 2010 - 16 -

Included Network Tools

Pre-installed in the sample root filesystem are SSH (for running remote terminal sessions/shells

into the Tegra devkit) and SCP (for easy, FTP-like file transfers into the running devkit

filesystem, removing the need for shifting the boot media to the host PC and back). These two

utilities should make working with the devkit much easier ‚out of the box.‛ Details on using

both utilities can be easily found on the internet.

You may also find that you need to directly download files from web sites, which is usually

done using the wget utility, not currently included in the filesystem. To install it, use:

sudo apt-get install wget

October 2010 - 17 -

Running Test Applications

Included in the root filesystem are a number of test applications that exercise different portions

of the operating system. They are installed in /home/ubuntu, which if you log in normally from

the serial prompt or over ssh should be the user home directory (‚~/‛ for quick access).

A number of OpenGL ES and OpenMAX tests are included, as well as some helper utilities, a

few of which we’ll cover in more detail here.

Multimedia Playback

The omxplayer2 application is a sample using OpenMAX to play local audio and video files,

remote streaming media, and display local JPEG files with hardware decoding. Just run like:

./omxplayer2 -i <file-or-url>

1) To watch a streaming movie trailer off the web, just specify a URL to the stream. We’ve

included a shell script that makes testing this easy, just run:

./test_streaming_video.sh

Note: See sub-section “Audio Volume Control” below to turn down the line-level audio.

2) An example command to play a streaming music station (in this case, Classical) is:

./omxplayer2 -i "http://streamb.wgbh.org:8004"

3) You can of course just use a local filename to play a movie or audio file instead of a URL.

4) To view a JPEG, provide a local filename, and add --jpegdecode to the commandline.

Basic 3D Testing

A quick test of the 3D graphics pipeline (including OpenGL ES, EGL, etc.) can be run by:

./nvtest ./gles2_gears --Tswapinterval 1 [timeout]

The timeout is an optional number of seconds to run before exiting. It defaults to 5s if not

otherwise specified, and if a negative timeout is given the app will run until it is manually

terminated. The --Tswapinterval param lets you turn vsync on, as it is off by default.

The gles2_gears test shows spinning 3D gears, and exits after the given timeout value.

October 2010 - 18 -

System Statistics

The tegrastats program reports periodic memory and dynamic frequency scaling (DFS)

statistics for the Tegra chip. To run it, use:

./tegrastats [delay]

The delay argument is optional, but if specified should be the desired number of milliseconds

between printouts – the default is 1000 (one second). An example printed line looks like:

RAM 28/629MB Carveout 8/64MB GART 0/32MB (lfb 32) IRAM 12/256kB |

DFS(%@MHz): cpu [2%,off]@200 avp 2%@100 vde 0%@24 emc 0%@166

The statistics listed are:

RAM X/Y

X is the amount of RAM in use in megabytes

Y is the total amount of RAM available for applications

Carveout X/Y

("carveout" refers to video memory, or GPU memory)

X is the amount of carveout memory in use, in megabytes

Y is the total amount available

GART X/Y (lfb Z)

("GART" refers to system memory that has been mapped to be visible to the GPU. It is

typically allocated when carveout allocations fail.)

X is the amount of GART memory in use, in megabytes


Z is the size of the largest free block

IRAM X

("IRAM" refers to dedicated memory attached to the AVP processor.)

X is the amount of IRAM memory in use, in kilobytes


cpu [X%,Y%]@Z

X is the percent of CPU1 being used relative to the current running frequency Z.

Y is the percent of CPU2 being used (or 'off' if second core is turned off)

Z is the CPU frequency in MHz (the frequency will dynamically go up or down

depending on what workload the CPU is seeing)

avp X%@Y

("avp" is the audio/video processor, which is not visible to either the OS or

applications. However, some forms of video decode/encode make heavy use of it.)

X is the percent of the AVP that is being used (aka CPU load), relative to the current

running frequency Y.

Y is the AVP frequency in MHz (the frequency will dynamically go up or down

depending on what workload the AVP is seeing)

vde X%@Y

("vde" is the video decode engine.)

X is the percent of the VDE that is being used (aka CPU load), relative to the current

running frequency Y.

Y is the VDE frequency in MHz

emc X%@Y

("emc" is the external memory controller, which all sysmem/carveout/GART memory

accesses go through)

X is the percent of the EMC memory bandwidth that is being used, relative to the

current running frequency Y.

Y is the EMC frequency in MHz

October 2010 - 19 -

DFS Clock Control

You can also use tegrastats for basic DFS clock control. To run all clocks at maximum use:

./tegrastats –max

To restore all clocks to normal dynamic operation, use:

./tegrastats –default

For clock control, the app will set DFS according to the argument given, then exit immediately.

Audio System Control

To change the master audio volume, you can use the ALSA amixer utility, like:

amixer set Master 300

That sets the master volume to 300 (range of 0-1024, so approx ‘30%’ level), and you should see

output like:

Simple mixer control 'Master',0

Capabilities: pvolume

Playback channels: Front Left - Front Right

Limits: Playback 0 - 1024

Mono:

Front Left: Playback 300 [29%]

Front Right: Playback 300 [29%]

To see all the controls available, use

amixer controls

You might get output like:

numid=1,iface=MIXER,name='Master Playback Volume'

numid=2,iface=MIXER,name='SPDIF Playback Switch'

If you are plugged into HDMI, but want audio to route to headphones instead, use:

amixer cset numid=2 0

To turn on HDMI audio when currently routing through headphones, use:

amixer cset numid=2 1

Note that Master volume control only applies to headphones, as HDMI presumes your

TV/display is controlling the volume (and sends ‘line level’ output).

October 2010 - 20 -

Working With X11

For all of the examples that follow, we assume you have set up the environment for X11 with:

export DISPLAY=:0

Also, prior to doing ‘apt-get’ steps, you’ll want to ensure the databases are up to date via:

sudo apt-get update

Launching X11

Your average, basic X11 is already installed in the sample filesystem, and can be launched via:

X &

This will start up the X11 system, at which point you can launch X-based applications that you

have downloaded or built. Note however that this launch method uses whatever default

display is decided by the X server, generally the ‘internal’ display connector. To bring up X on

a specific external display, you need to specify the layout to use, changing the X launch line to:

X –layout HDMI &

or

xinit -- -layout HDMI &

Replace ‘HDMI’ with ‘CRT’ to use the CRT/VGA display instead. Note that ‘X …’ launches only

the X server, while starting via ‘xinit …’ will process some init scripts, by default starts an

xterm session, and when you exit that xterm it will automatically close down the X session.

Control the X11 Screen

You can use the xrandr utility to rotate the X11 screen to match display orientation. First, you

must install the xserver utility package, using a command line like:

sudo apt-get install x11-xserver-utils

To rotate the display 90-degrees to the left, run:

xrandr -o left

To invert display top-bottom, run:

xrandr -o inverted

To restore normal display orientation, run:

xrandr -o normal

For other options, use xrandr -help, or look for docs/examples on the internet.

October 2010 - 21 -

Installing a Window Manager

For a more ‘user friendly’ X11 environment, you’ll want to install one of the various X11

window managers – to do so, you’ll need your devkit connected to the internet, and use the apt-

get package management tool.

Basic WM: Blackbox

To install the small/lightweight window manager Blackbox, use:

sudo apt-get install blackbox

It should take under a minute, as it only needs to download and install two packages, and may

be more than sufficient for many users’ needs. To launch Blackbox on HDMI, you’d use:

X –layout HDMI &

exec blackbox &

Full WM: Metacity

The full-fledged window manager Metacity, made popular by Ubuntu, may be installed using:

sudo apt-get install metacity

Note that the download/install process can easily take 30-60 minutes on an average broadband

connection, and will use at least an additional 450MB of space on the root filesystem device.

This may be too large for 1GB USB drives or SD cards, thus we’d recommend larger storage.

Starting up Metacity is slightly different from the basic X11. So to start on CRT, you would use:

X –layout CRT &

gnome-session &

Note that xterm is not installed in the Metacity menus by default.

Running Test Applications on X11

You can run the nvtest application under X11 by adding ‚—Twinsys x11‛ to the launch

command noted earlier. For example:

./nvtest ./gles2_gears --Twinsys x11 -1

Note the double-dash before the ‘T’ is required, and not accidental in the above example. For

more options for the controlling how samples run within the window system, add --Thelp to

the command line.

It is interesting to point out if you are running a window manager, the gles2_gears sample

will come up in a window that you can drag around the screen while it is live- rendering 3D.

October 2010 - 22 -

Installing Firefox

Once you have Blackbox or Metacity installed, Firefox is a great next application to add given

its functionality. However, getting it installed properly needs a few extra steps:

1) Edit /etc/apt/sources.list and add the following line:

deb http://ports.ubuntu.com/ubuntu-ports jaunty-updates main universe

2) With the revised sources, make sure to update the apt-get databases:

sudo apt-get update

3) Then, special apt-get commands are used to retrieve Firefox 3.5.x (whatever is the latest

Firefox packaged release):

sudo apt-get -y --force-yes install --no-install-recommends firefox-3.5

The download should take only a minute or two on a fast connection, the install takes

another minute or two.

4) Launch X11, then your window manager, and finally start Firefox simply using:

firefox-3.5 [url]

You can optionally specify a URL to launch directly.

The target filesystem includes a Tegra plugin for Firefox for accelerating some audio and video

formats via omxplayer2 – so you can visit certain sites on the internet and play multimedia (for

example, movie trailers at http://trailers.apple.com).

Note: The Tegra multimedia plugin is only a technology demonstration.

http://trailers.apple.com/

October 2010 - 23 -

Appendix A: Cross-Compiling for Tegra

While detailed discussion of developing on L4T are outside the scope of this document, there

are two helper scripts included in the pack for advanced users who want to try to get a jump on

development. The scripts are:

install_3rdparty.sh

install_x11.sh

The former downloads and installs a CodeSourcery ARM build (gcc and other tools), while the

latter downloads and compiles X11 related cross-binaries and headers. Both scripts install their

results in subdirectories underneath:

$L4TROOT/linux4tegra/_out/3rdparty

Note that the X11 script is auto-run by the 3rdparty script unless NO_X11 is an export variable

explicitly set in the shell (or on the command line when launching install_3rdparty.sh).

When constructing makefiles, note that the prefix string for the arm toolchain that you’d want

to use would be something like:

$L4TROOT/_out/3rdparty/arm-2009q1/bin/arm-none-linux-gnueabi-

That string, prefixed onto standard command names (i.e. ‘gcc’), will result in the proper binaries

being launched.

Of course, the compile/link tools are but one piece of the equation. Additionally, key Khronos

headers and libraries (OpenGL ES 2.0, OpenMAX IL, EGL, etc.) have been included in the L4T

pack in the directories used as part of the apply_l4t.sh script. You’ll find them under:

$L4TROOT/linux4tegra/prebuilt/targetfs_overlay/usr/include

$L4TROOT/linux4tegra/prebuilt/targetfs_overlay/usr/lib

Note that after running apply_l4t.sh, these files can be found in the sample filesystem in:

$L4TROOT/linux4tegra/_out/targetfs/usr/include

$L4TROOT/linux4tegra/_out/targetfs/usr/lib

On the Tegra devkit itself, those obviously become just /usr/include and /usr/lib.

Further details on building applications for L4T will be covered in an upcoming SDK document.

October 2010 - 24 -

Appendix B: Building the NVIDIA Tegra Kernel

While the majority of the Linux Kernel build process is outside the scope of this document,

we’ve included here a brief overview for advanced users wishing to build from the public Tegra

kernel sources. Please refer to various internet discussions for more details on the tools and

steps involved.

To download the NVIDIA Tegra Kernel, you’ll need to connect to the NVIDIA Git server:

nv-tegra.nvidia.com

This section describes both how to clone the NVIDIA Tegra Kernel tree for the first time and

how to download to an existing Git repository.

Prerequisites for Building the Kernel

1) You must have Git installed and configured properly on your host PC.

2) Your system must have the default Git port 9418 open for outbound connections in order to

properly connect to the nv-tegra server.

3) You must have already installed appropriate ARM cross-compile tools. The build

instructions below will assume you have already set up a shell export variable

‚CROSS_COMPILE‛ defined as the prefix applied to form the path to the toolchain for cross

compilation, e.g. the prefix to the particular variant of gcc.

For the CodeSourcery tool chain which is installed via the install_3rdparty.sh helper

script, a command line properly defining CROSS_COMPILE would look something like the

following:

export CROSS_COMPILE=$L4TROOT/_out/3rdparty/arm-2009q1/bin/arm-none-linux-gnueabi-

Cloning the Kernel

If you are cloning the NVIDIA Tegra Kernel tree for the first time, execute the following

commands:

cd <myworkspace>

git clone git://nv-tegra.nvidia.com/linux-2.6.git kernel

cd kernel

git checkout -b <mybranch> tegra-<release_num>

In the above example commands, the custom arguments are:

1) <myworkspace>

A ‘workspace’ directory in which to synchronize kernel sources.

October 2010 - 25 -

2) <mybranch>

A name of your choosing for the working ‘branch’ you will be developing/compiling.

3) tegra-<release_num>

This is a Git tag on the NVIDIA server. To see a list of available tags, use

git tag -l ‘tegra*’.

The <release-num> value is a short version number for the NVIDIA release you want.

When this document was written, the version was ‚10.9.3‛, thus the entire version tag

would be ‚tegra-10.9.3‛.

If you instead have an existing kernel Git repository, execute the following commands:

cd <myworkspace>

git remote add tegra git://nv-tegra.nvidia.com/linux-2.6.git

git fetch tegra

git checkout -b <mybranch> tegra-<release_num>

Note: You will skip the ‚git remote add tegra…‛command if you have previously pulled

code down from the NVIDIA Git repository.

In the above example, the custom arguments are:

1) <myworkspace>

The ‘workspace’ directory containing your existing kernel tree.

2) <mybranch>

A name of your choosing for the working ‘branch’ you will be developing/compiling.

3) tegra-<release_num>

This is a Git tag on the NVIDIA server. Seen matching argument in the ‘first time’

example above.

Building the Kernel

Once you have cloned the appropriate tagged kernel code to your host PC, execute the

following commands:

cd <myworkspace>/kernel

export TEGRA_KERNEL_OUT=${PWD}/_out

mkdir $TEGRA_KERNEL_OUT

make ARCH=arm O=$TEGRA_KERNEL_OUT tegra_harmony_gnu_linux_defconfig

make ARCH=arm O=$TEGRA_KERNEL_OUT

October 2010 - 26 -

The KERNEL_OUT directory can be anywhere you like, it is defined as an export above for

cleaner instructions here and in the next section. If you have a development board other than

the Tegra 200 Series devkit, you may need to replace ‚harmony‛ with another board name.

Once you have a custom kernel built, you can run the flash_l4t.sh script with no arguments

to see help for what export variables can be set to override which kernel (or other files) is used.

Building the WLAN Driver

Once you have built the NVIDIA Tegra Kernel, you can also easily rebuild the included WLAN

drivers from sources by following the procedure below to download the source code from Git,

copy to a staging directory, and build the kernel module.

cd <myworkspace>

git clone git://nv-tegra.nvidia.com/3rdparty/atheros.git atheros

cd atheros

export ATH_LINUXPATH=$TEGRA_KERNEL_OUT

export ATH_CROSS_COMPILE_TYPE=$CROSS_COMPILE

make -C ./ar6k_sdk

The output binaries will be located in:

<myworkspace>/atheros/ar6k_sdk/host/os/linux

October 2010 - 27 -

Appendix C: Installing Advanced X11 Desktops

Internal testing of installing more advanced desktops on top of the sample root filesystem has

met with varied results. The on-the-fly installs we’ve tried (individually, i.e., restarting from

the clean/default root filesystem) include:

sudo apt-get install ubuntu-desktop

sudo apt-get install kubuntu-desktop

sudo apt-get install gnome

Each requires 1.3-1.7GB of additional root filesystem space. Thus, the root filesystem must

reside on a storage device with at least a 4GB capacity. In each case, there were similar

issues/caveats:

There has not been active development or testing against these kinds of full desktop

installations, and as such you will likely find many applications, tools, use-cases, etc.,

that simply do not work properly with the L4T pack.

During install, the installers may note that the kernel is not built for IP multicast,

requiring that the user accept (‚OK‛) to continue a few times. This also unfortunately

means that the install cannot be left completely unattended, as it requires input.

In some cases, auto-launch of the desktop on boot will result in a ‚login loop‛ or login

lockup: logging in as ubuntu/ubuntu will not proceed to the desktop. In these cases,

killing X11 and running a proper ‚startx‛ or ‚xinit‛ from an already-logged in

command prompt will often load to the desired desktop. This issue is being tracked,

and may simply be a configuration issue of upgrading from the existing X11 to the full

desktop, rather than starting with a rootstock desktop build. However, it seems that the

basic gnome install does not have this issue.

Note that gstreamer, ffmpeg, and other such native Linux multimedia packages are not

currently specifically accelerated on Tegra, and will simply run as ARM CPU code

except in areas where other core acceleration is provided (i.e., ALSA). We are tracking

efforts to add in Tegra acceleration of certain applications and libraries.

It is also possible that over-installing such desktops on the sample filesystem will

accidentally overwrite or disable one or more of the libraries that are accelerated.

These large, full desktop experiences have higher memory and storage access

requirements. We would recommend the use of a USB-based physical HDD rather than

a USB flash-drive or SD/MMC card when installing these class of desktop packages.

The kernel does not have swapfile support enabled by default, which may help

performance running desktop window managers and desktop-class applications.

October 2010 - 28 -

Appendix D: Custom Root Filesystems

If you want to use your own root filesystem, you will want to study the files in

$L4TROOT/linux4tegra/prebuilt/targetfs_base/. The key file that you will want to

review is create_rootfs_package.sh, the basic script used to create and package the sample

target filesystem included in the L4T pack. The other two two support files in that folder

include a TTY script for serial shell support and the init script for launching the main NVIDIA

daemon process.

For advanced users, reading through the main creation script should give you all the

information you need to create other custom rootstock filesystems, or otherwise modify custom

filesystems to properly start up the serial shell and NVIDIA daemon.

Note that in addition to seeing the simple construction of the sample filesystem, you’ll also

want to review the apply_l4t.sh script used in the example setup of the sample filesystem

earlier in this document. That script is fairly simple, copying a folder hierarchy meant to

overlay a normal ubuntu filesystem layout with additional system libraries, scripts, etc. You

may be able to run the same script on a different, but still ubuntu-based, filesystem with

‘normal’ results – but with more customized filesystems or alternate distributions, you may

need to develop a more customized script to copy the right source files to the correct

destinations in your specific target filesystem.

October 2010 - 29 -

Appendix E: Sample Boot Transcript

**********Aos DebugSemiHosting Initialized*******

---------------------------------------------

------

ADJUSTED CLOCKS:

MC clock is set to 333000 KHz

EMC clock is set to 666000 KHz (DDR clock is at

333000 KHz)

PLLX0 clock is set to 1000000 KHz

PLLC0 clock is set to 600000 KHz

CPU clock is set to 1000000 KHz

System and AVP clock is set to 240000 KHz

GraphicsHost clock is set to 108000 KHz

3D clock is set to 111000 KHz

2D clock is set to 111000

KHz

Epp clock is set to 111000 KHz

Mpe clock is set to 111000 KHz

Vde clock is set

to 240000 KHz

Global Nand Interleave count = 1

I2C Slave is *New*OS will cold

boot in 10 seconds if no input is detected

Press <Enter> to select, Arrow key

(Left, Right) for selection move

Cold-booting Linux

mmcblk1p1

[ 0.000000]

Initializing cgroup subsys cpu

[ 0.000000] Linux version 2.6.32.9-00002-ga12c04e (qabuilder@qabuilder-linux9) (gcc version

4.4.0 (GCC) ) #1 SMP PREEMPT Sun Oct 3 00:17:44 IST 2010

[ 0.000000] CPU: ARMv7 Processor [411fc090] revision 0 (ARMv7), cr=10c53c7f

[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

[ 0.000000] Machine: NVIDIA Harmony Development System

[ 0.000000] Framebuffer tag with 65536 handle

[ 0.000000] Shmoo tag with 65537 handle

[ 0.000000] Found a warmboot tag!

[ 0.000000] Memory policy: ECC disabled, Data cache writealloc

[ 0.000000] PERCPU: Embedded 8 pages/cpu @c0e58000 s10560 r8192 d14016 u65536

[ 0.000000] pcpu-alloc: s10560 r8192 d14016 u65536 alloc=16*4096

[ 0.000000] pcpu-alloc: [0] 0 [0] 1

[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 227328

[ 0.000000] Kernel command line: mem=384M@0M nvmem=128M@384M mem=512M@512M vmalloc=256M

video=tegrafb console=ttyS0,115200n8 usbcore.old_scheme_first=1 root=/dev/mmcblk1p1 rw

rootdelay=15 tegraboot=nand

mtdparts=tegra_nand:5120K@14080K(recovery),8192K@19712K(boot),6144K@7424K(staging)

[ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)

[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)

[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)

[ 0.000000] Memory: 384MB 224MB 288MB = 896MB total

October 2010 - 30 -

[ 0.000000] Memory: 902344KB available (5448K code, 751K data, 176K init, 294912K highmem)

[ 0.000000] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1

[ 0.000000] Hierarchical RCU implementation.

[ 0.000000] NR_IRQS:416

[ 0.000000] Console: colour dummy device 80x30

[ 11.628157] Calibrating delay loop... 1998.84 BogoMIPS (lpj=9994240)

[ 11.898157] Mount-cache hash table entries: 512

[ 11.898554] Initializing cgroup subsys cpuacct

[ 11.898575] Initializing cgroup subsys devices

[ 11.898585] Initializing cgroup subsys freezer

[ 11.898610] CPU: Testing write buffer coherency: ok

[ 11.898793] Calibrating local timer... 1.19MHz.

[ 12.008215] CPU1: Booted secondary processor

[ 12.278005] Brought up 2 CPUs

[ 12.278020] SMP: Total of 2 processors activated (3991.14 BogoMIPS).

[ 12.300574] regulator: core version 0.5

[ 12.300940] NET: Registered protocol family 16

[ 12.305390] Chip Id: 0x20 (Handheld SOC) Major: 0x1 Minor: 0x2 SKU: 0x8

[ 12.306033] NVRM Got shmoo boot argument (at 0xee834004)

[ 12.306043] NVRM corner (0, 0)

[ 12.427984] NVRM CLOCKS: PLLX0: 1000000 Khz

[ 12.427996] NVRM CLOCKS: PLLM0: 666000 Khz

[ 12.428003] NVRM CLOCKS: PLLC0: 542000 Khz

[ 12.428009] NVRM CLOCKS: PLLP0: 216000 Khz

[ 12.428015] NVRM CLOCKS: PLLA0: 11289 Khz

[ 12.428020] NVRM CLOCKS: CPU: 1000000 Khz

[ 12.428027] NVRM CLOCKS: AVP: 216800 Khz

[ 12.428033] NVRM CLOCKS: System Bus: 216800 Khz

[ 12.428042] NVRM CLOCKS: Memory Controller: 333000

[ 12.428051] NVRM CLOCKS: External Memory Controller: 666000

[ 12.678107] regulator: pex_clk: 3300 mV

[ 12.678376] regulator: soc_main: 0 mV

[ 12.678639] regulator: vddio bb: 1700 <--> 2000 mV

[ 12.678920] regulator: vddio lcd: 1700 <--> 2000 mV

[ 12.679197] regulator: vddio vi: 1250 <--> 3350 mV

[ 12.679473] regulator: vddio uart: 1700 <--> 2000 mV

[ 12.679726] regulator: vddio ddr: 1700 <--> 2000 mV

[ 12.679980] regulator: vddio nand: 1250 <--> 3350 mV

[ 12.680236] regulator: vddio sys: 1700 <--> 2000 mV

[ 12.680499] regulator: vddio audio: 1700 <--> 2000 mV

[ 12.680782] regulator: vddio sd: 1250 <--> 3350 mV

[ 12.681054] regulator: lbee9qmb_vdd: 1700 <--> 2000 mV

[ 12.687455] ADJUSTED CLOCKS:

[ 12.687470] MC clock is set to 333000 KHz

[ 12.687480] EMC clock is set to 666000 KHz (DDR clock is at 333000 KHz)

[ 12.687487] PLLX0 clock is set to 1000000 KHz

[ 12.687493] PLLC0 clock is set to 542000 KHz

[ 12.687499] CPU clock is set to 1000000 KHz

[ 12.687505] System and AVP clock is set to 222000 KHz

[ 12.687513] GraphicsHost clock is set to 111000 KHz

[ 12.687520] 3D clock is set to 111000 KHz

[ 12.687528] 2D clock is set to 111000 KHz

[ 12.687534] Epp clock is set to 111000 KHz

[ 12.687541] Mpe clock is set to 111000 KHz

[ 12.687548] Vde clock is set to 222000 KHz

[ 12.708160] Local timer scaling factor 2097, shift 24

[ 12.708195] PL310/L2C-310 cache controller enabled

[ 12.710449] tegra_setup_i2c: skipping tegra_i2c.2 (SMBUS)

[ 12.720961] bio: create slab <bio-0> at 0

[ 12.738592] vgaarb: loaded

October 2010 - 31 -

[ 12.738984] SCSI subsystem initialized

[ 12.739253] usbcore: registered new interface driver usbfs

[ 12.739361] usbcore: registered new interface driver hub

[ 12.739502] usbcore: registered new device driver usb

[ 12.740593] Bluetooth: Core ver 2.15


[ 12.740741] Bluetooth: HCI device and connection manager initialized

[ 12.740751] Bluetooth: HCI socket layer initialized

[ 12.740969] Switching to clocksource timer_us


[ 12.761975] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)

[ 12.762208] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)

[ 12.763716] TCP bind hash table entries: 65536 (order: 7, 786432 bytes)

[ 12.764545] TCP: Hash tables configured (established 131072 bind 65536)

[ 12.764555] TCP reno registered


[ 12.777848] RPC: Registered udp transport module.

[ 12.777857] RPC: Registered tcp transport module.

[ 12.777864] RPC: Registered tcp NFSv4.1 backchannel transport module.

[ 12.778743] tegra_iovmm_register: added iovmm-gart

[ 12.780122] nvrm_init called

[ 12.780163] nvrm probe

[ 12.781055]

[ 12.781058] I2C Slave is *New*highmem bounce pool size: 64 pages

[ 12.797304] ashmem: initialized

[ 12.820105] Installing knfsd (copyright (C) 1996 [email protected]).

[ 12.820323] yaffs Oct 3 2010 00:12:49 Installing.

[ 12.820350] msgmni has been set to 1187

[ 12.838993] alg: No test for stdrng (krng)

[ 12.839037] io scheduler noop registered

[ 12.839045] io scheduler anticipatory registered

[ 12.839053] io scheduler deadline registered

[ 12.839119] io scheduler cfq registered (default)

[ 12.841088] tegra_grhost tegra_grhost: initialized

[ 12.841577] nvtegrafb: base address: ef000000 physical: 18012000

[ 12.865524] Console: switching to colour frame buffer device 160x64

[ 12.898032] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled

[ 12.898535] serial8250.0: ttyS0 at MMIO 0x70006300 (irq = 122) is a XScale

[ 13.492347] console [ttyS0] enabled

[ 13.496272] tegra_uart.0: ttyHS0 at I/O 0x0 (irq = 68) is a unknown

[ 13.502765] Registered UART port ttyHS0





[ 13.527370] Initialized tegra uart driver

[ 13.533457] tegra_nand tegra_nand: tegra_nand_probe: probing (c0597f50)

[ 13.540891] tegra_nand tegra_nand: tegra_nand_scan: found NAND chip (Vendor = 0xad, DevId =

0xdc)

[ 14.125741] 3 cmdlinepart partitions found on MTD device tegra_nand

[ 14.132008] Creating 3 MTD partitions on "tegra_nand":

[ 14.137139] 0x000000dc0000-0x0000012c0000 : "recovery"

[ 14.143017] 0x000001340000-0x000001b40000 : "boot"

[ 14.148368] 0x000000740000-0x000000d40000 : "staging"

[ 14.154095] NvRmSpiOpen() Opening channel Inst 0 and IsMaster 1

[ 14.161532] usbcore: registered new interface driver cdc_ether

[ 14.167457] usbcore: registered new interface driver smsc9500

[ 14.173318] usbcore: registered new interface driver cdc_subset

[ 14.179654] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

[ 14.219051] tegra-ehci tegra-ehci.1: Tegra Ehci host controller

October 2010 - 32 -

[ 14.225158] tegra-ehci tegra-ehci.1: new USB bus registered, assigned bus number 1

[ 14.257796] tegra-ehci tegra-ehci.1: irq 53, io base 0xc5004000

[ 14.277789] tegra-ehci tegra-ehci.1: USB 2.0 started, EHCI 1.00

[ 14.283752] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002

[ 14.290548] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1

[ 14.297769] usb usb1: Product: Tegra Ehci host controller

[ 14.303158] usb usb1: Manufacturer: Linux 2.6.32.9-00002-ga12c04e ehci_hcd

[ 14.310028] usb usb1: SerialNumber: tegra-ehci.1

[ 14.314896] usb usb1: configuration #1 chosen from 1 choice

[ 14.320643] hub 1-0:1.0: USB hub found

[ 14.324409] hub 1-0:1.0: 1 port detected

[ 14.328447] tegra-ehci tegra-ehci.1: dmabounce: registered device

[ 14.337696] tegra-ehci tegra-ehci.2: Tegra Ehci host controller

[ 14.343805] tegra-ehci tegra-ehci.2: new USB bus registered, assigned bus number 2

[ 14.377796] tegra-ehci tegra-ehci.2: irq 129, io base 0xc5008000

[ 14.397787] tegra-ehci tegra-ehci.2: USB 2.0 started, EHCI 1.00

[ 14.403736] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002

[ 14.410523] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1

[ 14.417733] usb usb2: Product: Tegra Ehci host controller

[ 14.423135] usb usb2: Manufacturer: Linux 2.6.32.9-00002-ga12c04e ehci_hcd

[ 14.430007] usb usb2: SerialNumber: tegra-ehci.2

[ 14.434889] usb usb2: configuration #1 chosen from 1 choice

[ 14.440632] hub 2-0:1.0: USB hub found

[ 14.444397] hub 2-0:1.0: 1 port detected

[ 14.448423] tegra-ehci tegra-ehci.2: dmabounce: registered device

[ 14.454850] usbcore: registered new interface driver cdc_acm

[ 14.460514] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN

adapters

[ 14.469138] usbcore: registered new interface driver cdc_wdm

[ 14.474791] Initializing USB Mass Storage driver...

[ 14.479808] usbcore: registered new interface driver usb-storage

[ 14.485807] USB Mass Storage support registered.

[ 14.490433] Tegra High-Speed USB SOC Device Controller driver (Apr 20, 2007)

[ 14.503228] tegra-udc tegra-udc.0: vbus_draw regulator error -19; charging disabled

[ 14.510982] android init

[ 14.513541] android_probe pdata: c0598ad0

[ 14.517641] android_bind

[ 14.520187] Gadget Android: controller 'tegra-udc' not recognized

[ 14.526271] android_usb gadget: android_usb ready

[ 14.530972] tegra-udc: bind to driver android_usb

[ 14.538311] f_adb init

[ 14.540665] android_register_function adb

[ 14.544670] adb_bind_config

[ 14.548245] mice: PS/2 mouse device common for all mice

[ 14.573916] input: nvec keyboard as /devices/virtual/input/input0

[ 14.757793] usb 2-1: new high speed USB device using tegra-ehci and address 2

[ 14.847845] usb 2-1: New USB device found, idVendor=0424, idProduct=9514

[ 14.854537] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

[ 14.861907] usb 2-1: configuration #1 chosen from 1 choice

[ 14.867614] hub 2-1:1.0: USB hub found

[ 14.880339] hub 2-1:1.0: 5 ports detected

[ 15.237791]

[ 15.237795] ***NVEC:Received Spurious Response from EC.

[ 15.244471] NvOdmMouseDeviceOpen failed

[ 15.248633] usbcore: registered new interface driver usbtouchscreen

[ 15.298089] using rtc device, tegra_rtc, for alarms

[ 15.302807] tegra_rtc tegra_rtc: rtc core: registered tegra_rtc as rtc0

[ 15.309616] tegra_rtc tegra_rtc: Tegra internal Real Time Clock

[ 15.316530] tegra_rtc_odm tegra_rtc_odm: rtc core: registered tegra_rtc_odm as rtc1

[ 15.331172] Bluetooth: HCI UART driver ver 2.2

October 2010 - 33 -

[ 15.335619] Bluetooth: HCI H4 protocol initialized

[ 15.340463] Bluetooth: HCI BCSP protocol initialized

[ 15.345430] Bluetooth: HCILL protocol initialized

[ 15.350505] usb 2-1.1: new high speed USB device using tegra-ehci and address 3

[ 15.357829] cpuidle: using governor ladder

[ 15.362595] cpuidle: using governor menu

[ 15.366609] sdhci: Secure Digital Host Controller Interface driver

[ 15.372812] sdhci: Copyright(c) Pierre Ossman

[ 15.380481] tegra-sdhci tegra-sdhci.0: no max_clk specified, default to 52MHz

[ 15.387628] mmc0: Invalid maximum block size, assuming 512 bytes

[ 15.393905] mmc0: SDHCI controller on tegra-sdhci.0 [tegra-sdhci.0] using ADMA

[ 15.401163] tegra-sdhci tegra-sdhci.0: probe complete

[ 15.406712] usb 2-1.1: New USB device found, idVendor=0424, idProduct=ec00



[ 15.427800] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 15.435134] usb 2-1.1: Product: LAN9514







[ 15.436849] usbcore: registered new interface driver usbhid

[ 15.436860] usbhid: v2.6:USB HID core driver

[ 15.437009] Advanced Linux Sound Architecture Driver Version 1.0.21.

[ 15.437367] No device for DAI tegra-i2s-rpc

[ 15.437549] No device for DAI tegra-codec-rpc

[ 15.437681] asoc: tegra-codec-rpc <-> tegra-i2s-rpc mapping ok

[ 15.438443] ALSA device list:

[ 15.438449] #0: tegra (tegra-generic-codec)

[ 15.438788] TCP cubic registered


[ 15.438824] Bluetooth: L2CAP ver 2.14

[ 15.438829] Bluetooth: L2CAP socket layer initialized

[ 15.438838] Bluetooth: SCO (Voice Link) ver 0.6

[ 15.438842] Bluetooth: SCO socket layer initialized

[ 15.438926] Bluetooth: RFCOMM TTY layer initialized

[ 15.438936] Bluetooth: RFCOMM socket layer initialized

[ 15.438942] Bluetooth: RFCOMM ver 1.11

[ 15.438947] Bluetooth: BNEP (Ethernet Emulation) ver 1.3

[ 15.438954] Bluetooth: HIDP (Human Interface Emulation) ver 1.2

[ 15.565982] usb 2-1.1: Manufacturer: SMSC

[ 15.569990] usb 2-1.1: SerialNumber: 12345678

[ 15.570325] usb 2-1.1: configuration #1 chosen from 1 choice

[ 15.580363] Driver smscusbnet.ko verison 101.06.04, built on 00:14:24, Oct 3 2010

[ 15.587987] SMSC_9500: ---------->in smsc9500_bind

[ 15.587992]

[ 15.594305] SMSC_9500: Driver smsc9500.ko verison 101.06.04, built on 00:14:22, Oct 3 2010

[ 15.622957] SMSC_9500: EEPROM size: 256 bytes

[ 15.627304] SMSC_9500: ---------->smsc9500_reset

[ 15.627308]

[ 15.657254] mmc0: new SDIO card at address 0001

[ 15.929334] SMSC_9500: dev->net->dev_addr 02:04:4b:00:cf:40

[ 15.929339]

[ 15.940334] SMSC_9500: Read Value from HW_CFG : 0x00000000

[ 15.940339]

[ 15.947959] SMSC_9500: Read Value from HW_CFG after writing HW_CFG_BIR_: 0x00001000

[ 15.947965]

[ 15.957094] SMSC_9500: rx_urb_size= 18944

October 2010 - 34 -

[ 15.957097]

[ 15.969083] SMSC_9500: Read Value from BURST_CAP after writing: 0x00000025

[ 15.969088]

[ 15.977957] SMSC_9500: Read Value from BULK_IN_DLY after writing: 0x00002000

[ 15.977963]

[ 15.986582] SMSC_9500: Read Value from HW_CFG: 0x00001000

[ 15.986586]

[ 16.009083] SMSC_9500: Read Value from HW_CFG after writing: 0x00001022

[ 16.009089]

[ 16.017457] SMSC_9500: ID_REV = 0xec000001

[ 16.017461]

[ 16.029084] SMSC_9500: FPGA_REV = 0x00000000

[ 16.029088]

[ 16.078833] SMSC_9500: -->Phy_Initialize

[ 16.082835] SMSC_9500: using internal PHY

[ 16.095870] mmc1: new high speed SDHC card at address 0007

[ 16.101689] mmcblk1: mmc1:0007 SD4GB 3.81 GiB

[ 16.106146] SMSC_9500: dwPhyId==0x00C0001C,bPhyModel==0x0C,bPhyRev==0x03

[ 16.106253] mmcblk1: p1

[ 16.257842] SMSC_9500: PHY reset!!!

[ 16.261323] SMSC_9500_WARNING: Phy_SetAutoMdix: LAN9500 Auto MDIX feature controlled by

hardware strap

[ 16.265594]

[ 16.457835] SMSC_9500: <--Phy_Initialize, result=TRUE

[ 16.457840]

[ 16.464360] SMSC_9500: <--------out of smsc9500_reset, return 0

[ 16.464365]

[ 16.471763] SMSC_9500_WARNING: smsc9500_bind: Autosuspend should be enabled by shell cmd

"echo auto > /sys/bus/usb/devices/X-XX/power/level"

[ 16.484430] SMSC_9500: <--------out of bind, return 0

[ 16.484434]

[ 16.491312] usb0: register 'smsc9500' at usb-tegra-ehci.2-1.1, smsc9500 USB 2.0 Ethernet,

02:04:4b:00:cf:40

[ 16.557797] pci_tegra_check_rp: RP 0 LINK is not up...retrying...

[ 16.630403] usb 2-1.3: new high speed USB device using tegra-ehci and address 4

[ 16.808219] usb 2-1.3: New USB device found, idVendor=090c, idProduct=6000


[ 16.822393] usb 2-1.3: Product: USB2.0 Card Reader

[ 16.827348] usb 2-1.3: Manufacturer: Generic , .

[ 16.832794] usb 2-1.3: SerialNumber: 12345678901234567890

[ 16.838484] usb 2-1.3: configuration #1 chosen from 1 choice

[ 16.844697] scsi0 : SCSI emulation for USB Mass Storage devices

[ 16.946090] usb 2-1.5: new full speed USB device using tegra-ehci and address 5

[ 17.148090] usb 2-1.5: New USB device found, idVendor=047d, idProduct=1019


[ 17.162281] usb 2-1.5: Product: Kensington USB Trackball

[ 17.167584] usb 2-1.5: Manufacturer: Kensington

[ 17.172412] usb 2-1.5: configuration #1 chosen from 2 choices

[ 17.189639] input: Kensington Kensington USB Trackball as /devices/platform/tegra-

ehci.2/usb2/2-1/2-1.5/2-1.5:1.0/input/input1

[ 17.201489] generic-usb 0003:047D:1019.0001: input,hidraw0: USB HID v1.00 Mouse [Kensington

Kensington USB Trackball] on usb-tegra-ehci.2-1.5/input0


[ 17.673876] pci_tegra_check_rp: RP 0 Failed



[ 19.793863] pci_tegra_check_rp: RP 1 Failed

[ 19.798048] pci_tegra_setup: no PCIE devices attached

[ 19.803088] pci_tegra_setup exiting: FAILURE

[ 19.809625] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 1

October 2010 - 35 -

[ 19.817971] regulator_init_complete: incomplete constraints, leaving vddio sd on

[ 19.825358] regulator_init_complete: incomplete constraints, leaving vddio sys on

[ 19.832843] regulator_init_complete: incomplete constraints, leaving vddio ddr on

[ 19.840325] regulator_init_complete: incomplete constraints, leaving vddio bb on

[ 19.847710] regulator_init_complete: incomplete constraints, leaving soc_main on

[ 19.855101] regulator_init_complete: incomplete constraints, leaving pex_clk on

[ 19.862454] tegra_rtc tegra_rtc: setting system clock to 1970-01-01 00:00:19 UTC (19)

[ 19.870314] Waiting 15sec before mounting root device...

[ 21.958892] scsi 0:0:0:0: Direct-Access Generic 6000 PQ: 0 ANSI: 0

CCS

[ 21.968114] sd 0:0:0:0: Attached scsi generic sg0 type 0

[ 21.978645] sd 0:0:0:0: [sda] 7844864 512-byte logical blocks: (4.01 GB/3.74 GiB)

[ 21.987036] sd 0:0:0:0: [sda] Write Protect is off

[ 21.991859] sd 0:0:0:0: [sda] Assuming drive cache: write through


[ 22.014568] sda: sda1


[ 22.034443] sd 0:0:0:0: [sda] Attached SCSI removable disk

[ 34.882909] kjournald starting. Commit interval 5 seconds

[ 34.937668] EXT3 FS on mmcblk1p1, internal journal

[ 34.942486] EXT3-fs: mounted filesystem with writeback data mode.

[ 34.948600] VFS: Mounted root (ext3 filesystem) on device 179:9.

[ 34.954629] Freeing init memory: 176K

* Filesystem type 'fusectl' is not supported. Skipping mount.

* Setting preliminary keymap... [ OK ]

* Starting kernel event manager... [ OK ]

* Loading hardware drivers... [ OK ]

* Loading kernel modules... * Loading

manual drivers... [ OK ]

* Setting kernel variables (/etc/sysctl.conf)... [ OK ]

* Setting kernel variables (/etc/sysctl.d/10-console-messages.conf)... [ OK ]

* Setting kernel variables (/etc/sysctl.d/10-network-security.conf)... error:

"net.ipv4.tcp_syncookies" is an unknown key

[fail]

* Activating swap... [ OK ]

* Checking file systems... fsck 1.41.4

(27-Jan-2009)

[ OK ]

* Mounting local filesystems... [ OK ]

* Activating swapfile swap... [ OK ]

* Configuring network interfaces... [ OK ]

* Setting up console font and keymap... [ OK ]

* Starting system log daemon... [ OK ]

* Starting

kernel log daemon... [ OK ]

* Starting

system message bus dbus

[ OK ]

Ubuntu 9.04

tegra-ubuntu ttyS0

tegra-ubuntu login: * Starting OpenBSD Secure Shell server sshd [ OK ]

* Starting

Hardware abstraction layer hald [ OK ]

NVIDIA Corporation

2701 San Tomas Expressway

Santa Clara, CA 95050

www.nvidia.com

Notice

ALL NVIDIA DESIGN SPECIFICATIONS, REFERENCE BOARDS, FILES, DRAWINGS, DIAGNOSTICS, LISTS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, “MATERIALS”) ARE BEING PROVIDED “AS IS.” NVIDIA MAKES NO WARRANTIES, EXPRESSED, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND EXPRESSLY DISCLAIMS ALL IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY, AND FITNESS FOR A PARTICULAR PURPOSE.

Information furnished is believed to be accurate and reliable. However, NVIDIA Corporation assumes no responsibility for the consequences of use of such information or for any infringement of patents or other rights of third parties that may result from its use. No license is granted by implication or otherwise under any patent or patent rights of NVIDIA Corporation. Specifications mentioned in this publication are subject to change without notice. This publication supersedes and replaces all information previously supplied. NVIDIA Corporation products are not authorized for use as critical components in life support devices or systems without express written approval of NVIDIA Corporation.

Trademarks

NVIDIA, the NVIDIA logo, Tegra, GeForce, NVIDIA Quadro, and NVIDIA CUDA are trademarks or registered trademarks of NVIDIA Corporation in the United States and other countries. Other company and product names may be trademarks of the respective companies with which they are associated.

Copyright

© 2008-2010 NVIDIA Corporation. All rights reserved.

linux for tegra (l4t) os pack quickstart guide -...

Documents