Introduction to Beagleboard programming using OpenEmbedded Tools

Alexander Granizo

June 28, 2011

Contents

1 Introduction
1.1 1.2 1.3 1.4 1.5 1.6 BeagleBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OpenEmbedded Project

3
3 4 5 5 5 6 6

Poky Platform Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Used Hardware and Software Versions Summary 1.6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Suggestions for Additional Reading . . . . . . . . . . . . . . . . . . . . . .

2 The basics
2.1 2.2 2.3 2.4 2.5 Required Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Required Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing the BeagleBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SD card partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary 2.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suggestions for Additional Reading . . . . . . . . . . . . . . . . . . . . . .

7
7 7 8 9 18 18

3 Toolchain and Cross-Compiling

3.1 3.2 3.3 3.4 Compiling a toolchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing a toolchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-compiling a test program . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary 3.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suggestions for Additional Reading . . . . . . . . . . . . . . . . . . . . . .

19
19 19 19 19 19

4 Setting up a development workstation

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Local vs. Remote Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up some network cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . What is Remote Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TFTP server on Host DHCP server on Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20
20 20 20 20 21 21 23 23 23 24 24 24

NFS server on Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a remote kernel image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using a remote lesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conguring an OPKG Repository on Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.10 Single workstation vs. Network setup . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Summary 4.11.1 Suggestions for Additional Reading . . . . . . . . . . . . . . . . . . . . . .

CONTENTS

5 Working with Eclipse

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 Getting and Installing Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing Eclipse CDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installing the plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conguring to work with a cross-toolchain . . . . . . . . . . . . . . . . . . . . . . Cross compiling with Eclipse Remote File Browse Poky Linux Summary 5.9.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25
25 25 25 25 25 25 25 25 25 25

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Suggestions for Additional Reading . . . . . . . . . . . . . . . . . . . . . .

6 Emulation on the host

6.1 6.2 6.3 Getting QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Compiling an Image Summary 6.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26
26 26 26 26

Suggestions for Additional Reading . . . . . . . . . . . . . . . . . . . . . .

Chapter 1
Introduction

1.1 BeagleBoard
Beagleboard is a low-power, low-cost single-board computer. The BeagleBoard was designed with open source development in mind, and as a way of demonstrating the Texas Instrument's OMAP system-on-a-chip solutions. The board was developed by a team of TI engineers as an educational board that could be used in colleges around the world to teach open source hardware and open source software capabilities. The BeagleBoard has a large community following that can be found at beagleboard.org.[ ] The board used during the writing this test is the BeagleBoard-xM model, which has the following specications:

Package on Package POP CPU/Memory chip.

Processor TI DM3730 Processor - 1 GHz ARM Cortex-A8 core 'HD capable' TMS320C64x+ core (800 MHz up to 720p @30 fps) Imagination Technologies PowerVR SGX 2D/3D graphics processor supporting dual independent displays 512 MB LPDDR RAM memory 4 GB microSD card is supplied with the BeagleBoard-xM loaded with Angstrom.

Peripheral connections

DVI-D (HDMI connector chosen for size - maximum resolution is 1280x1024) S-Video USB OTG (mini AB) 4 USB ports Ethernet Port MicroSD/MMC card slot Stereo in and out jacks RS232 port JTAG connector

CHAPTER 1.

INTRODUCTION

Power socket (5 V barrel connector type) Camera Port Expansion port

Other characteristics

Boot code stored on the uSD card Boot from uSD/MMC only Alternative Boot source button. Able to run Android, Angstrom Linux, Fedora, Ubuntu, Gentoo and Maemo Linux distributions, and the Windows CE operating system.

For further information about the Beagleboard and its components, please refer to the System Reference Manual.[ ]

1.2 Why Linux

Linux is a modular, open source operative system, that derives much of it's design principles from Unix. According to Wikipedia, Linux can be installed on a wide variety of computer hardware, ranging from mobile phones, tablet computers and video game consoles, to mainframes and supercomputers[ ]. As it's a open-source operative system, the source code of the OS, as well the user applications running on it, can be reviewed, modied, implemented on a project. If the modication is benecial, the changes can be merged in an existing project and thus shared with other Linux developers and users. The main advantages of Linux applied to Embedded Systems learning are:

Open Source

The sourcecode of a program can be checked and edited when necessary. This

possibility accelerates the debugging and customizing of an Embedded System and alliviates procedures regarding to licensing and NDAs. However, there are some not to say disadvantages but inconveniences originated from Linux use:

Documentation

The documentation of some open-source projects could be sometimes outdated

and/or incomplete. For this cases, the debugging of a problem requires not only a glance into the manual, but a thorough searching and reading of the forums, mail lists, and even the source code itself. The main objective of this work is to introduce the reader to the exciting word of Embedded Systems and to ease the rst steps with the setup and conguration of a development workstation. The text will provide the means to quick start the development, and to concentrate on the embedded application, instead of conguration troubleshooting.

1.3 OpenEmbedded Project

OpenEmbedded (www.openembedded.org) is a software framework to cross-compile, package and install software packages for embedded devices.[ ] OpenEmbedded can handle various Linux Distributions, including ngstrm among others. The main characteristics are:

Highly congurable to support various hardware platforms, Linux distributions, and processor architectures.

CHAPTER 1.

INTRODUCTION

Handle package inter-dependencies. Handle kernel and user-space software cross-compilation. Is able to create package suitable for a chosen Linux distribution. (tar, rpm, deb, ipk) Is able to create complete Linux images from packages. Is able to create cross-compiler toolchain- and SDK- packages able to be used within a an IDE such as Eclipse.

1.4 Poky Platform Builder

Poky (http://www.pokylinux.org/) is a open source build tool. It aids the design, development, building, debugging, simulation and testing of complete modern software stacks using Linux, the X Window System and GNOME Mobile based application frameworks. It is based on OpenEmbedded but has been customized with a particular focus.[ ] The main characteristics of Poky which dierences it from plain OpenEmbedded are:

Based on focused, stable, subset of OpenEmbedded that can be easily and reliably built and developed upon. Includes a pre-congured QEMU device emulator, which provides a virtual target for development and debugging. Provides Yocto SDK Plug-in, which eases the setup of a toolchain, emulator and debugging utilities within Eclipse.

During the development of this work, both OpenEmbedded and Poky were tested.

As both

projects are Open-Source, and they're both based on Bitbake compiler, it is possible to port the existing Recipes from one platform to another. However, it was discovered, that OpenEmbedded resulted to be more exible than Poky, and most of the required software recipes (OpenCV within others) were already supported in OpenEmbedded. For all of these reasons, the OpenEmbedded platform was chosen.

1.5 Used Hardware and Software Versions

During the development of this text was used the following hardware: Development Workstation (Host) Processor Memory Hard drive OS Linux Kernel Intel Core i7 @ 3,07 GHz 6 GB 500 GB Ubuntu Linux x64 10.10 (maverick) 2.6.35-28-generic Embedded System (Target) Type Revision Assembly Processor Memory Beagleboard-xM B 00 DM3730 512 MB

The build framework used in the developments was OpenEmbedded (Release 2011.03) with some recipes ported from Poky platform builder (version Laverne-4.0). The kernel version used on the Beagleboard was linux-omap-psp version 2.6.32. The chosen Linux distribution was ngstrm

CHAPTER 1.

INTRODUCTION

1.6 Summary
1.6.1 Suggestions for Additional Reading

Chapter 2
The basics

2.1 Required Hardware

The BeagleBoard-xM package comes with the following components:

The Beagleboard-xM itself 4GB Micro SDHC memory card

To start the developing with the board, we need to following additional hardware accessories:

A RS-232 (Serial) port on the development computer or a USB-Serial adapter A MicroSD card reader capable to read SDHC cards A 5V DC power source

To ease the development and to have a direct input to the Beagleboard, some additional accessories are suggested:

Monitor with HDMI or DVI-D connection HDMI video cable (with an optional HDMI to DVI-D adapter) USB keyboard USB Mouse

2.2 Required Software

To test the Beagleboard, a Serial terminal program such as TeraTerm, HyperTerminal, or Minicom is necessary. During the test phase it's not necessary to use Linux at the host machine, but it's advisable, as the following software development will be done in Linux. To install Minicom on Ubuntu, simply open the Synaptic Package Manager and search for minicom or type:

$ sudo apt-get install minicom

in a terminal window. printed form[ , For some introduction to Linux / UNIX, there are some useful manuals on Net [ ] and in

? ?].

CHAPTER 2.

THE BASICS

2.3 Testing the BeagleBoard

The following procedure could be used:

Make sure that the BeagleBoard is powered o Connect a serial cable to a serial port of Window/Linux/Mac machine. In case an USB adapter is used, the name of the port that it uses can be found listing the last device messages.

$ dmesg | tail ... [ ...] usb 5-1: FTDI USB Serial Device converter now attached to ttyUSB0 ...
Have a terminal program, such as TeraTerm, HyperTerminal, or Minicom, running on the host machine Congure the terminal program for BAUD RATE - 115200, DATA - 8 bit, PARITY- none, STOP - 1bit, FLOW CONTROL - none. In case of Minicom, once the program is running, press Ctrl+A, Z for help, and then O for conguration.

Insert the provided originally MMC/SD card into MMC/SD slot on Beagle Board. Connect it to the power and press the reset button on the board. The following output should appear on the terminal:

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27) Beagle xM Rev A Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.03-dirty (Aug 20 2010 - 20:50:46) OMAP3630/3730-GP ES2.0, CPU-OPP2, L3-165MHz, OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MB NAND: 0 MiB .... Starting Dropbear SSH server: dropbear. Starting syslogd/klogd: done .-------. | | .-. | | |-----.-----.-----.| | .----..-----.-----. | | | __ | ---| --.| .-| | | | | | | | |--- || --| | | | | | | ------------. |----------- -------- - | ---

CHAPTER 2.

THE BASICS

The Angstrom Distribution beagleboard ttyS2 Angstrom 2010.7-test-20100820 beagleboard ttyS2 beagleboard login:
If you see these messages, it means that the BeagleBoard is alive and running. You can log in into the system as a root user. The initial root password is not set.

beagleboard login: root root@beagleboard:~#

2.4 Our own Linux on Beagleboard

Linux is a complete operative system that provides a common base to user programs and applications and allows them to run on a determinate machine. Linux basically consists of a Kernel, acts as a compatibility base to run on a variety of hardware platforms. The kernel provides a standard interface, used by the user applications and system services (daemons). The applications and les are organized on a tree-like structure and form together the Linux lesystem.

2.4.1 Linux booting on BeagleBoard

As the Beagleboard-xM doesn't has on-board programmable ROM memory, all the les, conguration and bootloaders should be allocated on the micro SD card. The booting sequence has ve phases: 1. The internal ROM loads the X-Load ( MLO on the card) 2. X-Load congures the external RAM, looks for u-boot.bin and loads it 3. U-Boot reads commands from a boot script (boot.scr ). If the User key is pressed, then it looks for user.scr le. 4. U-Boot loads the kernel, according the script commands. 5. Kernel reads root lesystem based on the provided bootargs in the script. To ensure this boot sequence, the card should met some requirements. The card should have 255 heads an 63 sectors/track. The rst partition should be FAT32 type and marked as bootable. It should have the MLO le as the rst le on it. To ease the access to the les during the developing and testing phase, the lesystem will be located on a EXT3 partition of the same card. There are more possibilities to for the lesystem location, either as a local compressed le (JFFS2, ramdisk) or as a remote NFS share.

2.4.2 ngstrm Distribuition and OpenEmbedded

ngstrm is complete Linux distribution: includes the kernel, a base le system, basic tools and even a package manager to install software from a repository. It is optimized for low-power microcontrollers like the one in BB and intends to be small and basic system to modify on your needs.

CHAPTER 2.

THE BASICS

10

X-Loader (MLO) U-Boot (u-boot.bin) U-Boot script (boot.scr) Linux kernel (uImage)

FAT32 Partition (BOOT)

Linux lesystem

EXT3 Partition (ROOTFS)

Figure 2.4.1: BeagleBoard micro SD Card internal organization

It uses the OpenEmbedded (OE from now on) platform, a toolchain that makes cross-compiling and deploying packages easy for embedded platforms. There are other Linux distribuitions available, however, this manual will bases itself on ngstrm. Once that the Beagleboard is checked and running, we will install OpenEmbedded and compile a new Linux lesystem for it.

2.4.3 Installing OpenEmbedded

We will install OE from its GIT repository.

Install the required dependencies

First there are some packages OE depends on. To install them run the following commands:

$ sudo apt-get install python3-all-dev patch m4 perl diff $ sudo apt-get install wget curl ftp cvs subversion git-core $ sudo apt-get install tar bzip2 gzip unzip $ sudo apt-get install jade docbook docbook-dsssl \ docbook-utils sgmltools-lite texinfo texi2html $ sudo apt-get install bison libsdl1.2-dev $ sudo apt-get install sed coreutils gawk python-pysqlite2 \ diffstat help2man make gcc build-essential g++ \ desktop-file-utils chrpath

CHAPTER 2.

THE BASICS

11

Create the OpenEmbedded Directory and get its metadata

The rst step is to decide where on your system you wish to work. This document will use the

$OEBASE variable to denote the base directory of the OpenEmbedded environment. For the sake of example, $OEBASE will be /home/<user>/oe. The base directory of your OpenEmbedded environment ($OEBASE) is the location where
sources will be checked out (or unpacked). You must choose a location with no symbolic links above it. As next step the OE metadata (information, recipes, tools, etc) will be downloaded from their GIT repository. The used version of OE will be the 2011.03 release.

$ export OEBASE="/home/<user>/oe" $ mkdir -p ${OEBASE} && cd ${OEBASE} $ git clone git://git.openembedded.org/openembedded.git openembedded $ cd openembedded $ git checkout -b release-2011.03 origin/release-2011.03 $ cd ${OEBASE}/openembedded $ git pull

Congure OpenEmbedded
When you have downloaded all metadata les, you need to set up OE indicating your target board, directory of OE recipes, and other les. directory tree. To do this, inside of

$OEBASE

create a new

$ cd ${OEBASE} $ mkdir -p build/conf

We will copy an existing conguration le into the newly created according to the conguration of our machine.

/conf

directory, and edit it

$ cp openembedded/conf/local.conf.sample build/conf/local. conf $ gedit build/conf/local.conf

Edit the conguration and read all the comments of the le. Please note, that there are some lines on the end of this le that need to be deleted when the conguration is done. For now, we will congure only some variables, these are:

BBFILES ?= "/home/<user>/oe/openembedded/recipes/*/*.bb" DISTRO = "angstrom-2008.1" MACHINE = "beagleboard" IMAGE_FSTYPES = "tar" INHERIT += "rm_work" GLIBC_GENERATE_LOCALES = "en_US.UTF-8 en_GB.UTF-8 de_DE.UTF -8" PARALLEL_MAKE = "-j 8" BB_NUMBER_THREADS = "8"

CHAPTER 2.

THE BASICS

12

The value of the last two variables should be set in accordance to the number of processors on the host machine. For the sake of example, the Intel Core i7 processor used in the development on this work, has 4 physical processors which support Hyper Threading, so a total of 8 processors will be available to the OS. In this case in particular, the values of

BB_NUMBER_THREADS

and

PARALLEL_MAKE

were set equal to the number of processor. In case when no user interaction

will occur during the compilation, the value could be even higher than the number of processors. As a last step of the conguration, we create a le named  config_oe.sh in the OE root folder. The le is responsible to set-up all the environment variables in order to run Bitbake. The le will look like this:

# !/bin/bash # openembedded configure script # Configure Paths export OEBASE=/home/agranizo/oe export BBPATH=${OEBASE}/build:${OEBASE}/openembedded export PATH=${OEBASE}/bitbake/bin:$PATH # Make shell look better.. if [ "$BASH" ]; then export PS1="\[\033[01;32m\]BB:\[\033[00m\] ${PS1}" fi

Testing the conguration with a single package

Once OpenEmbedded is congured, it is possible to compile Linux packages and complete distributions. The main interface to the build system is the bitbake command. For more information about refer to. In order to test our OpenEmbedded installation, it's possible to compile a single package such as nano. To do this, as a rst step, the compilation environment is set up. As a next step we invoke the Bitbake compiler, and pass the name of the recipe to be compiled (in this case the

nano text editor). The process should take long time the rst times, but as the packages are
created and saved on each consecutive build, the process will be faster each time.

~/oe$ source config_oe.sh ~/oe$ cd build/ ~/oe/build$ bitbake nano NOTE: Handling BitBake files: | (6779/6779) 100 % NOTE: Parsing finished. 6491 cached, 0 parsed, 288 skipped, 0 masked. NOTE: Cache is clean, not saving. NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing runqueue ... NOTE: Running task 669 of 669 (ID: 0, /home/agranizo/oe/ openembedded/recipes/nano/nano_2.0.7.bb, do_rm_work_all)

CHAPTER 2.

THE BASICS

13

NOTE: Tasks Summary: Attempted 669 tasks of which 637 didnt need to be rerun and 0 failed.
If the compilation ended successfully, the output should show 0 failed tasks. If the compilation ended unexpectedly, the compilation could be started once again, with the same bitbake command (the intermediate resuts are stored although).

Compiling a new Linux image

Now that the the OpenEmbedded installation is tested, a complete Linux OS can be created. Some of the available recipes are:

base-image:

The smallest possible image which allows for ssh access and the ability to

install additional packages using ipkg.

console-image:
networking)

Build an image without the X11, but including some extra tools (e.g.

x11-image:
them.

Builds an image with X11 window system.

Build process takes a lot of time, as it need to download many packages from the net an build The resulting les will be contained in two archives: one containing the Linux kernel and its modules and the other with the complete lesystem structure compressed. To compile, proceed as following:

~/oe$ source config_oe.sh ~/oe$ cd build/ ~/oe/build$ bitbake x11-image ... NOTE: Running task 5899 of 5899 (ID: 9, /home/agranizo/oe/ openembedded/recipes/images/x11-image.bb, do_build) NOTE: package x11-image-1.0-r0: task do_build: Started NOTE: package x11-image-1.0-r0: task do_build: Succeeded NOTE: Tasks Summary: Attempted 5899 tasks of which 0 didnt need to be rerun and 0 failed.
At the end, all the les used on the compilation, as well as results of the compilation will be contained in the be located in the

${OEBASE}/build/tmp directory. The individual software packages will ${OEBASE}/build/tmp/deploy/glibc/ipk and the complete Linux images will be available in ${OEBASE}/build/tmp/deploy/glibc/images/beagleboard.
For more information about the OE directory structure, please refer to the OpenEmbedded User Manual [ ].

The les which represent interest for us are: - The rst stage bootloader. - The U-Boot bootloader for the Beagleboard. - A compressed Linux kernel. - A complete compressed Linux lesystem.

MLO-beagleboard

u-boot-beagleboard.bin uImage-beagleboard.bin

x11-image-beagleboard.tar.bz2

CHAPTER 2.

THE BASICS

14

modules-beagleboard.tgz
needed.

- Archive with the corresponding kernel modules.

In order to use these les on the target board, a specically partitioned micro SD card will be

2.5 SD card formatting

The Beagleboard-xM has any kind of on-board programmable ash memory. Instead of on-board memory, it uses the micro SD both for the bootloader and OS les. This approach has a very useful advantage, as now the board is almost foolproof. It is not necessary a JTAG or a serial port to reprogram a miscongured board. All that is needed is to insert a fresh reformatted micro SD card and the board should boot awlessly from it. The following instructions describe how to partition a new SD card in order to make it bootable with OMAP3 processors.[ ]

Determine which device the SD Card Reader is on your system

do the following to determine which device it is on your system.

Plug the SD Card

into the SD Card Reader and then plug the SD Card Reader into your system. After doing that,

$ dmesg | tail ... [...] sd 19:0:0:0: [...] sd 19:0:0:0: [...] sd 19:0:0:0: [...] sdb: sdb1 [...] sd 19:0:0:0: [...] sd 19:0:0:0: ...

[sdb] Mode Sense: 03 00 00 00 [sdb] Assuming drive cache: write through [sdb] Assuming drive cache: write through [sdb] Assuming drive cache: write through [sdb] Attached SCSI removable disk

In this case, it shows up as /dev/sdb (note sdb inside the square brackets above).

Check to see if the automounter has mounted the SD Card

need to unmount them.

Note there may be

more than one partition (only one shown in the example below). Note the "Mounted on" eld in the above and use that name in the umount commands below. If the card is mounted, we will

$ df -h Filesystem Size ... /dev/sdb1 70M /dev/sdb2 3.6G $ umount /media/boot $ umount /media/ROOTFS

Used Avail Use% Mounted on 2.6M 240M 67M 3.2G 4% /media/boot 7% /media/ROOTFS

Start fdisk
v/sdb1).

Be sure to choose the whole device (/dev/sdb), not a single partition (/de-

$ sudo fdisk /dev/sdb

CHAPTER 2.

THE BASICS

15

Print the partition record This will be the starting point for the partitioning proMake sure to write down the number of bytes on the card (in this example, 3951034368).
cess.

Command (m for help): p Disk /dev/sdb: 3951 MB, 3951034368 bytes 122 heads, 62 sectors/track, 1020 cylinders Units = cylinders of 7564 * 512 = 3872768 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000eb984 Device Boot Start End Blocks Id System /dev/sdb1 1 20 72261 c W95 FAT32 (LBA) * Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 1, 1) logical=(0, 1, 2) Partition 1 has different physical/logical endings: phys=(8, 254, 63) logical=(19, 14, 1) Partition 1 does not end on cylinder boundary. /dev/sdb2 20 1021 3786139+ 83 Linux Partition 2 has different physical/logical beginnings (non-Linux?): phys=(9, 0, 1) logical=(19, 14, 2) Partition 2 has different physical/logical endings: phys=(480, 89, 57) logical=(1020, 25, 34) Partition 2 does not end on cylinder boundary.

Delete any partitions that are there already

Command (m for help): d Partition number (1-4): 1 Command (m for help): d Selected partition 2 Command (m for help): p Disk /dev/sdb: 3951 MB, 3951034368 bytes 122 heads, 62 sectors/track, 1020 cylinders Units = cylinders of 7564 * 512 = 3872768 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000eb984 Device Boot Start End Blocks Id System

CHAPTER 2.

THE BASICS

16

Set the Geometry of the SD Card

Go into expert mode.

If the print out above does not show 255 heads, 63

sectors/track, then do the following expert mode steps to redo the SD Card.

Command (m for help): x

Set the number of heads to 255.

Expert command (m for help): h Number of heads (1-256, default 122): 255
Set the number of sectors to 63.

Expert command (m for help): s Number of sectors (1-63, default 62): 63 Warning: setting sector offset for DOS compatiblity
Now calculate the number of Cylinders for your SD Card.

#cyl = f loor
For this example don't round).

#BytesOnCard 25563512
We will use 480 (i.e. truncate,

#cyl = 3951034368/(255 63 512) = 480.35

Set the number of cylinders to the number calculated.

Expert command (m for help): c Number of cylinders (1-1048576, default 1020): 480
Return to Normal mode.

Expert command (m for help): r

Print the partition record to check your work

Command (m for help): p Disk /dev/sdb: 3951 MB, 3951034368 bytes 255 heads, 63 sectors/track, 480 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000eb984 Device Boot Start End Blocks Id System

CHAPTER 2.

THE BASICS

17

Create the FAT32 partition for booting and transferring les from Windows
Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-480, default 1): <enter> Using default value 1 Last cylinder, +cylinders or +size{K,M,G} (1-480, default 480): +50 Command (m for help): t Selected partition 1 Hex code (type L to list codes): c Changed system type of partition 1 to c (W95 FAT32 (LBA))

Mark it as bootable
Command (m for help): a Partition number (1-4): 1

Create the Linux partition for the root le system

Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 2 First cylinder (52-480, default 52): <enter> Using default value 52 Last cylinder, +cylinders or +size{K,M,G} (52-480, default 480): <enter> Using default value 480

Print the partition table to Check Your Work

Command (m for help): p Disk /dev/sdb: 3951 MB, 3951034368 bytes 255 heads, 63 sectors/track, 480 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000eb984

CHAPTER 2.

THE BASICS

18

Device Boot /dev/sdb1 * /dev/sdb2

Start 1 52

End 51 480

Blocks 409626 3445942+

Id c 83

System W95 FAT32 (LBA) Linux

Save the new partition records on the SD Card

Command (m for help): w The partition table has been altered!

All the work up to now has been

temporary. At this step the new partition table will be written on the card.

Calling ioctl() to re-read partition table.

Format the partitions

by these commands.

The two partitions are given the volume names boot and rootfs If the card was previously

You can substitute your own volume labels.

partitioned, it should be unmounted.

$ sudo mkfs.msdos -F 32 /dev/sdb1 -n boot mkfs.msdos 3.0.9 (31 Jan 2010) $ sudo mkfs.ext3 -L rootfs /dev/sdb2 mke2fs 1.41.12 (17-May-2010) Filesystem label=ROOTFS OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 215568 inodes, 861485 blocks 43074 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=884998144 27 block groups 32768 blocks per group, 32768 fragments per group 7984 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200 Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 33 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.

CHAPTER 2.

THE BASICS

19

2.6 Linux Installation

Once the SD card is correctly partitioned and formatted, we can proceed with the installation of Linux on it. To do this, it is necessary to copy the uBoot and the Linux kernel on the rst (FAT32) partition of the card. The linux lesystem will be installed on the second (ext3) partition. to do this, proceed as following: Extract and insert again the formatted SD card. If an automounter is present on the host, it should mount the card automatically. As next we will proceed to copy the compiled les on its corresponding partitions. Please note, that the rst le on the FAT32 partition should be the

MLO X-Load le.

$ df -h Filesystem ... /dev/sdb1 /dev/sdb2 $ $ $ $ $ $ $ $

Size 400M 3.3G

Used Avail Use% Mounted on 3.3M 165M 396M 3.0G 1% /media/boot 6% /media/rootfs

cd oe/build/tmp/deploy/glibc/images/beagleboard/ ls cp MLO-beagleboard /media/boot/MLO cp u-boot-beagleboard.bin /media/boot/u-boot.bin cp uImage-beagleboard.bin /media/boot/uImage sudo tar xvfj x11-image-beagleboard.tar.bz2 -C /media/rootfs/ sudo tar xvfz modules-beagleboard.tgz -C /media/rootfs/ sync

2.7 Creating U-Boot script

U-Boot has some built-in environment variables in order to set-up the boot process. The variable 'bootcmd ' stores the commands to be executed. U-Boot is instructed look for a boot script in order to correctly set up the kernel and lesystem options. The default boot script to be executed is the le booot.scr, but when the User button is pressed, U-Boot will execute the user.scr script. The congurable boot options are:

Location of the kernel le. Location and mounting instructions for the root lesystem. Video options such as: video driver name, used video memory, default display, resolution and color depth.

In order to use the available screen the available video resolution will be changed.

Listing 2.1: Plain text boot script (boot.cmd)

mmc init setenv dvimode 1280x1024MR-16@60 run loaduimage run mmcboot

CHAPTER 2.

THE BASICS

20

This script will need to be compiled in order to be readable by U-Boot.

The package uboot-

mkimage will be needed. To compile the script use the following command:
Listing 2.2: Plain text boot script (boot.cmd)

$ $

sudo apt-get install uboot-mkimage mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n " BeagleBoard-xM Boot script" -d boot.cmd boot.scr

Now just copy the newly created boot.scr le on your SD card, and insert the card into the BeagleBoard. Proceed with the proceedure decribed in the Section 2.3 in order to boot up and test the new Linux installation.

2.8 Conguring the network

2.8.1 Conguring Host's IP Address 2.8.2 Conguring Host DHCP server
The objective is to minimize the conguration of the Beagleboard and to make the most of the conguration on the host. The target will be given a IP addrtess according to the host's DHCP setup. To accomplish this, following steps will be needed: Check the dhcpd package.

$ whereis dhcpd
If it is not available on the system install it and the related packages.

$ sudo apt-get install dhcp3-server

Make a backup of the conguration les

$ cd /etc/dhcp3/ /etc/dhcp3$ sudo cp dhcpd.conf dhcpd.conf.old

Edit the conguration le

/etc/dhcp3/dhcpd.conf

Listing 2.3: File dhcpd.conf

#authoritative; # Warning: this overrides other DHCP servers ddns-update-style none; option domain-name-servers 141.19.69.34, 141.19.1.75; default-lease-time 3600; max-lease-time 360000; subnet 192.168.0.0 netmask 255.255.255.0 { range 192.168.0.2 192.168.0.2; option subnet-mask 255.255.255.0; option broadcast-address 192.168.0.255; option routers 192.168.0.1; }

CHAPTER 2.

THE BASICS

21

In le

/etc/default/dhcp3-server

will be dened which physical interface is the DHCP

server allowed to run on.

Listing 2.4: File dhcp3-servers (section)

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests? # Separate multiple interfaces with spaces, e.g. "eth0 eth1". INTERFACES="eth2"
Congure the startup settings of the dhcp3-server daemon. A group change of dhcp.conf le will be needed.

Listing 2.5: Auto-start conguration of dhcp3-server

$ sudo update-rc.d -f dhcp3-server remove sudo password for agranizo: Removing any system startup links for /etc/init.d/dhcp3server ... /etc/rc1.d/K40dhcp3-server /etc/rc2.d/S40dhcp3-server ... $ sudo update-rc.d dhcp3-server defaults update-rc.d: warning: dhcp3-server stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (1) Adding system startup for /etc/init.d/dhcp3-server ... /etc/rc0.d/K20dhcp3-server -> ../init.d/dhcp3-server /etc/rc1.d/K20dhcp3-server -> ../init.d/dhcp3-server ... $ sudo chgrp dhcpd /etc/dhcp3/dhcpd.conf
As last step of the conguration, the daemon will be added to the end with

/etc/rc.local startup le.

This way, th daemon starts along with every user session. Please remember that the le should

exit 0

line.

Listing 2.6: File /etc/rc.local (section)

... ifup eth2 service dhcp3-server start exit 0

2.8.3 Testing the conguration

In order to test the conguration on the on the host, please restart the PC and proceed as following.

CHAPTER 2.

THE BASICS

22

Listing 2.7: Test of dhcp3-server status

$ sudo service dhcp3-server status Status of DHCP server: dhcpd3 is running. $ netstat -au | grep bootp udp 0 0 *:bootps *:* $ tail /var/log/messages
To test the dhcp client on the target, please reboot and wait until the board obtains the congured IP address (192.168.0.2). The network interface on Beagleboard is usb0, as the network is managed by a USB-OTG chip.

Listing 2.8: Test of IP address adquisition on target

beagleboard:~$ ifconfig ... usb0 Link encap:Ethernet HWaddr E2:86:55:40:EC:06 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 RX packets:7 errors:0 dropped:0 overruns:0 frame:0 TX packets:25 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1330 (1.2 KiB) TX bytes:3544 (3.4 KiB) ...

2.8.4 Conguring the SSH Server on Target

The Angstrom Linux distribuition has a small SSH application called dropbear which is provided by default in the x11-image package. generated rst. To use this SSH server, an encryption key should be

Listing 2.9: Generation of SSH encription keys on target

root@beagleboard:~# cd /etc/dropbear root@beagleboard:/etc/dropbear# ls dropbear_rsa_host_key root@beagleboard:/etc/dropbear# rm -rf dropbear_rsa_host_key #Generate a new key root@beagleboard:/etc/dropbear# dropbearkey -t rsa -f dropbear_rsa_host_key Will output 1024 bit rsa secret key to dropbear_rsa_host_key Generating key, this may take a while... Public key portion is: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwC4KEUi9HU1SAPoL+0lTDgi7 ... Fingerprint: md5 a1:8e:90:77:b7:91:f7:33:db:98:7f:01:35:8c:f0 :45

CHAPTER 2.

THE BASICS

23

# View the generated key root@beagleboard:/etc/dropbear# dropbearkey -y -f dropbear_rsa_host_key Public key portion is: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwC4KEUi9HU1SAPoL+0lTD... root@beagleboard Fingerprint: md5 a1:8e:90:77:b7:91:f7:33:db:98:7f:01:35:8c:f0 :45

2.8.5 Conguring a SSH Client on Host

The serial connection is used to access the linux console on Beagleboard. Another way to access the console is to congure a SSH access on it.

Listing 2.10: SSH client conguration on host

$ cd ~/.ssh agranizo@EMB-158:~/.ssh$ ll total 12 drwx------ 2 agranizo agranizo 4096 2010-12-16 16:52 ./ drwxr-xr-x 91 agranizo agranizo 4096 2011-06-20 23:31 ../ -rw-r--r-- 1 agranizo agranizo 499 2011-03-03 19:50 known_host # Add the SSH key according to the SSH server ~/.ssh$ gedit known_hosts $ ssh 192.168.0.2 -l root The authenticity of host 192.168.0.2 (192.168.0.2) cant be established. RSA key fingerprint is 56:c3:65:e8:14:79:5d:bc:21:aa:2a:d3 :63:43:b4:45. Are you sure you want to continue connecting (yes/no)? y Please type yes or no: yes Warning: Permanently added 192.168.0.2 (RSA) to the list of known hosts. root@192.168.0.2s password: root@beagleboard:~#

2.8.6 Setting up Layers in OpenEmbedded

To ease the development of user packages in OpenEmbedded it is necessary to distinguish the original OpenEmbedded les from the newly developed one. To do this, there is a possibility to congure layers. The concept of layers is basically that the user developed recipes will be The separated from the original OpenEmbedded recipes in a completely another directory. benets of this approach are:

A logical distinction between the user and the original les.

CHAPTER 2.

THE BASICS

24

Possibility to reinstall OE without loosing the the development progress. Ease in the organization of the OE recipes and les. Conguration of the recipe priorities during the compilation.

The conguration of the layer structure may be made in two les: The le

${OEBASE}/build/conf/bblayers.conf

denes the top directory and the in-

dividual directories correspondent to each layer.

Listing 2.11: File bblayers.conf

# LAYER_CONF_VERSION is increased each time build/conf/ bblayers.conf # changes incompatibly LCONF_VERSION = "3" BBFILES = "" TOPDIR = "${@os.path.dirname(os.path.dirname(os.path.dirname( d.getVar(FILE, True))))}" BBLAYERS = "${TOPDIR}/openembedded ${TOPDIR}/meta-custom"
The le

<layer_dir>/conf/layer.conf denes the name and the priority of the individual

layer, as well as the location of the layer's recipe les. In this example we will create a new layer directory called meta-custom, assign a higher priority to it, copy a new recipe to it and compile it.

Listing 2.12: File /meta-custom/conf/layer.conf

# We have a conf and classes directory, prepend to BBPATH to prefer our versions BBPATH .= ":${LAYERDIR}" # We have a recipes directory, add to BBFILES BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend" BBFILE_COLLECTIONS += "custom" BBFILE_PRIORITY_custom = "1" BBFILE_PATTERN_custom = "^${LAYERDIR}/"
The /openembedded directory, thath contains the original les should have now its own layer.conf le. The meta-custom directory will have precedence over the original les, so it's relatively easy to test modied recipes but to keep the original les. The precedence is set with variable.

BBFILE_PRIORITY_oe

Listing 2.13: File /openembedded/conf/layer.conf

# We have a conf and classes directory, prepend to BBPATH to prefer our versions

CHAPTER 2.

THE BASICS

25

BBPATH .= ":${LAYERDIR}" # We have a recipes directory, add to BBFILES BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend" BBFILE_COLLECTIONS += "oe" BBFILE_PRIORITY_oe = "0" BBFILE_PATTERN_oe = "^${LAYERDIR}/"

2.9 Summary
2.9.1 Suggestions for Additional Reading

Chapter 3
Toolchain and Cross-Compiling

3.1 Compiling a toolchain

OpenEmbedded has already a recipe for building an installable cross-compile toolchain. toolchain recipe is located in The

${OEBASE}/openembedded/recipes/meta and is called meta-toolchain.bb. The target architecture for cross-compiling is the already congured in le ${OEBASE}/build/conf/local.conf at the denition of the the variable MACHINE. In our case the cross compiler will be deestined

for ARM binaries.

Listing 3.1: Simple Toolchain compilation commands

~/oe$ source config_oe.sh ~/oe/build$ cd build/ ~/oe/build$ bitbake meta-toolchain

3.2 Installing a toolchain

The compiled toolchain is located in tory.

${OEBASE}/build/tmp/deploy/glibc/sdk

direc-

Listing 3.2: Toolchain Package installation

~/oe/build$ cd tmp/deploy/glibc/sdk/ ~/oe/build/tmp/deploy/glibc/sdk$ ls angstrom-2010.7-test-20110617-x86_64-linux-armv7a-linuxgnueabi-toolchain-extras.tar.bz2 angstrom-2010.7-test-20110617-x86_64-linux-armv7a-linuxgnueabi-toolchain.tar.bz2 ~/oe/build/tmp/deploy/glibc/sdk$ sudo tar -C / -xjf ./ angstrom-2010.7-test-20110617-x86_64-linux-armv7a-linuxgnueabi-toolchain.tar.bz2 ~/oe/build/tmp/deploy/glibc/sdk$ sudo tar -C / -xjvf ./ angstrom-2010.7-test-20110617-x86_64-linux-armv7a-linuxgnueabi-toolchain-extras.tar.bz2

26

CHAPTER 3.

TOOLCHAIN AND CROSS-COMPILING

27

3.3 Cross-compiling a test program 3.4 Add libraries to the toolchain 3.5 Summary
3.5.1 Suggestions for Additional Reading

Chapter 4
Setting up a development workstation

4.1 NFS server on Host

At a terminal prompt enter the following command to install the NFS Server:

sudo apt-get install nfs-kernel-server

Edit the /etc/exports le to include the directories which will be visible in the network. The le should contain these lines (please check the location of the lesystem directory):

/home/agranizo/images/fs_initial *(rw,sync,no_root_squash, no_all_squash,no_subtree_check) /home/agranizo/images/fs_beagleboard *(rw,sync,no_root_squash ,no_all_squash,no_subtree_check) /home/agranizo/poky-laverne-4.0/build/tmp/deploy/ipk *(rw, sync,no_root_squash,no_all_squash,no_subtree_check)

To start the NFS server, you can run the following command at a terminal prompt:

$ $

sudo ifup eth2 sudo /etc/init.d/nfs-kernel-server start

Test the NFS Service on the server:

$ rpcinfo -p 127.0.0.1
The rpcinfo utility should show the following ports and services:

28

CHAPTER 4.

SETTING UP A DEVELOPMENT WORKSTATION

29

program vers 100003 2 tcp 100003 3 tcp 100003 4 tcp 100227 2 tcp 100227 3 tcp 100003 2 udp 100003 3 udp 100003 4 udp 100227 2 udp 100227 3 udp
Test the NFS Server:

proto port 2049 nfs 2049 nfs 2049 nfs 2049 2049 2049 nfs 2049 nfs 2049 nfs 2049 2049

$ sudo mkdir /mnt/remote $ sudo chmod -R 774 /mnt/remote/ $ sudo mount -t nfs localhost:/home/agranizo/images/ fs_initial /mnt/remote $ exportfs -a http://tldp.org/HOWTO/NFS-HOWTO/server.html /etc/hosts.allow and /etc/hosts.deny
These two les specify which computers on the network can use services on your machine. Each line of the le contains a single entry listing a service and a set of machines. When the server gets a request from a machine, it does the following:

It rst checks hosts.allow to see if the machine matches a description listed in there. If it does, then the machine is allowed access. If the machine does not match an entry in hosts.allow, the server then checks hosts.deny to see if the client matches a listing in there. If it does then the machine is denied access. If the client matches no listings in either le, then it is allowed access.

4.2 Local vs. Remote Booting 4.3 Setting up some network cables 4.4 What is Remote Booting 4.5 TFTP server on Host
Check the tftp package.

$ whereis tftp

CHAPTER 4.

SETTING UP A DEVELOPMENT WORKSTATION

30

1. Install tftpd and related packages.

$ sudo apt-get install xinetd tftpd tftp

2. Create /etc/xinetd.d/tftp and put this entry:

service tftp { socket_type = dgram protocol = udp wait = yes port = 69 user = nobody server = /usr/sbin/in.tftpd server_args = -s /tftpboot disable = no per_source = 11 cps = 100 2 }
3. Make /tftpboot directory

$ $ $ $ $ $

sudo mkdir /tftpboot mkdir debug_beagleboard_kernel sudo chmod -R 777 /tftpboot sudo chmod -R 777 debug_beagleboard_kernel/ sudo chown -R nobody /tftpboot sudo chown -R nobody debug_beagleboard_kernel/

4. Start tftpd through xinetd

$
5.

sudo /etc/init.d/xinetd start

Transferring le hda.txt from 192.168.1.100 (Client using tftp) to 192.168.1.100

Testing.

(Server 192.168.1.100). Get an example le to transfer (e.g. hda.txt)

$ touch /tftpboot/hda.txt $ chmod 777 /tftpboot/hda.txt $ ls -l /tftpboot/ total 0 -rwxrwxrwx 1 davids davids 0 2006-03-27 23:04 hda.txt $ tftp 192.168.1.100 tftp> put hda.txt Sent 722 bytes in 0.0 seconds tftp> quit $ ls -l /tftpboot/ total 4 -rwxrwxrwx 1 davids davids 707 2006-03-27 23:07 hda.txt

CHAPTER 4.

SETTING UP A DEVELOPMENT WORKSTATION

31

Testing on a Beagleboard: On the Beagleboard type: To put a local le on a server:

tftp -p -l test.txt 192.168.0.1

To get a remote le:

tftp -g -r test2.txt 192.168.0.1

4.6 DHCP server on Host 4.7 Using a remote kernel image 4.8 Using a remote lesystem 4.9 Conguring an OPKG Repository on Host 4.10 Single workstation vs. Network setup 4.11 Summary
4.11.1 Suggestions for Additional Reading

Chapter 5
Working with Eclipse

5.1 Getting and Installing Eclipse 5.2 Installing Eclipse CDT 5.3 Installing the plugins 5.4 Conguring to work with a cross-toolchain 5.5 Cross compiling with Eclipse 5.6 Remote Debugging 5.7 Remote File Browse 5.8 Poky Linux 5.9 Summary
5.9.1 Suggestions for Additional Reading

32

Chapter 6
Emulation on the host

6.1 Getting QEMU 6.2 Compiling an Image 6.3 Summary

6.3.1 Suggestions for Additional Reading

33