oe_manual

Introduction to Beagleboard programming using

OpenEmbedded Tools

Alexander Granizo

June 28, 2011

Contents

1 Introduction 3

1.1 BeagleBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Why Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 OpenEmbedded Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Poky Platform Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Used Hardware and Software Versions . . . . . . . . . . . . . . . . . . . . . . . . 51.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6.1 Suggestions for Additional Reading . . . . . . . . . . . . . . . . . . . . . . 6

2 The basics 7

2.1 Required Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Required Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Testing the BeagleBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 SD card partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18


3 Toolchain and Cross-Compiling 19

3.1 Compiling a toolchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Installing a toolchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Cross-compiling a test program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


4 Setting up a development workstation 20

4.1 Local vs. Remote Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Setting up some network cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 What is Remote Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 TFTP server on Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.5 DHCP server on Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.6 NFS server on Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.7 Using a remote kernel image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.8 Using a remote �lesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.9 Con�guring an OPKG Repository on Host . . . . . . . . . . . . . . . . . . . . . . 234.10 Single workstation vs. Network setup . . . . . . . . . . . . . . . . . . . . . . . . . 244.11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


1

CONTENTS 2

5 Working with Eclipse 25

5.1 Getting and Installing Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Installing Eclipse CDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.3 Installing the plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.4 Con�guring to work with a cross-toolchain . . . . . . . . . . . . . . . . . . . . . . 255.5 Cross compiling with Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.6 Remote Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.7 Remote File Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.8 Poky Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25


6 Emulation on the host 26

6.1 Getting QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 Compiling an Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


Chapter 1

Introduction

1.1 BeagleBoard

Beagleboard is a low-power, low-cost single-board computer. The BeagleBoard was designedwith open source development in mind, and as a way of demonstrating the Texas Instrument'sOMAP system-on-a-chip solutions. The board was developed by a team of TI engineers as aneducational board that could be used in colleges around the world to teach open source hardwareand open source software capabilities. The BeagleBoard has a large community following thatcan be found at beagleboard.org.[?]

The board used during the writing this test is the BeagleBoard-xM model, which has thefollowing speci�cations:

• 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 dualindependent 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

3

CHAPTER 1. INTRODUCTION 4

◦ 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 Linuxdistributions, and the Windows CE operating system.

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

1.2 Why Linux

Linux is a modular, open source operative system, that derives much of it's design principles fromUnix. 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 andsupercomputers[?]. As it's a open-source operative system, the source code of the OS, as wellthe user applications running on it, can be reviewed, modi�ed, implemented on a project. If themodi�cation is bene�cial, the changes can be merged in an existing project and thus shared withother 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. Thispossibility accelerates the debugging and customizing of an Embedded System and alliviatesprocedures 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 outdatedand/or incomplete. For this cases, the debugging of a problem requires not only a glanceinto the manual, but a thorough searching and reading of the forums, mail lists, and eventhe source code itself.

The main objective of this work is to introduce the reader to the exciting word of EmbeddedSystems and to ease the �rst steps with the setup and con�guration of a development workstation.The text will provide the means to quick start the development, and to concentrate on theembedded application, instead of con�guration troubleshooting.

1.3 OpenEmbedded Project

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

• Highly con�gurable to support various hardware platforms, Linux distributions, and pro-cessor architectures.

www.openembedded.org


• 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 anIDE such as Eclipse.

1.4 Poky Platform Builder

Poky (http://www.pokylinux.org/) is a open source build tool. It aids the design, devel-opment, building, debugging, simulation and testing of complete modern software stacks usingLinux, the X Window System and GNOME Mobile based application frameworks. It is basedon OpenEmbedded but has been customized with a particular focus.[?] The main characteristicsof Poky which di�erences it from plain OpenEmbedded are:

• Based on focused, stable, subset of OpenEmbedded that can be easily and reliably builtand developed upon.

• Includes a pre-con�gured QEMU device emulator, which provides a virtual target for de-velopment and debugging.

• Provides Yocto SDK Plug-in, which eases the setup of a toolchain, emulator and debuggingutilities within Eclipse.

During the development of this work, both OpenEmbedded and Poky were tested. As bothprojects are Open-Source, and they're both based on Bitbake compiler, it is possible to port theexisting Recipes from one platform to another. However, it was discovered, that OpenEmbeddedresulted to be more �exible than Poky, and most of the required software recipes (OpenCV withinothers) were already supported in OpenEmbedded. For all of these reasons, the OpenEmbeddedplatform was chosen.

1.5 Used Hardware and Software Versions

During the development of this text was used the following hardware:

Development Workstation (Host)

Processor Intel Core i7 @ 3,07 GHz

Memory 6 GB

Hard drive 500 GB

OS Ubuntu Linux x64 10.10 (maverick)

Linux Kernel 2.6.35-28-generic

Embedded System (Target)

Type Beagleboard-xM

Revision B

Assembly 00

Processor DM3730

Memory 512 MB

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

http://www.pokylinux.org/


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 acces-sories 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 Mini-com is necessary. During the test phase it's not necessary to use Linux at the host machine, butit's advisable, as the following software development will be done in Linux. To install Minicomon Ubuntu, simply open the Synaptic Package Manager and search for �minicom� or type:

$ sudo apt-get install minicom

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

printed form[?, ?].

7

CHAPTER 2. THE BASICS 8

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 USBadapter is used, the name of the port that it uses can be found listing the last devicemessages.

$ 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 thehost machine

• Con�gure 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 con�guration.

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

Texas Instruments X-Loader 1.4.4ss (Aug 19 2010 - 02:49:27)Beagle xM Rev AReading boot sectorLoading u-boot.bin from mmcU-Boot 2010.03-dirty (Aug 20 2010 - 20:50:46)OMAP3630/3730-GP ES2.0, CPU-OPP2, L3-165MHz,OMAP3 Beagle board + LPDDR/NANDI2C: readyDRAM: 512 MBNAND: 0 MiB....Starting Dropbear SSH server: dropbear.Starting syslogd/klogd: done

.-------.| | .-.| | |-----.-----.-----.| | .----..-----.-----.| | | __ | ---’| ’--.| .-’| | || | | | | |--- || --’| | | ’ | | | |’---’---’--’--’--. |-----’’----’’--’ ’-----’-’-’-’

-’ |’---’


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 canlog in into the system as a root user. The initial root password is not set.

beagleboard login: rootroot@beagleboard:~#

2.4 Our own Linux on Beagleboard

Linux is a complete operative system that provides a common base to user programs and applica-tions and allows them to run on a determinate machine. Linux basically consists of a Kernel, actsas a compatibility base to run on a variety of hardware platforms. The kernel provides a standardinterface, 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, con�g-uration 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 con�gures 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 itlooks 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 255heads 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 thedeveloping and testing phase, the �lesystem will be located on a EXT3 partition of the samecard. 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 andeven a package manager to install software from a repository. It is optimized for low-power micro-controllers like the one in BB and intends to be small and basic system to modify on your needs.


X-Loader (MLO)

U-Boot (u-boot.bin)

U-Boot script (boot.scr)

Linux kernel (uImage)

Linux filesystem

FAT32 Partition (BOOT)

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-compilingand deploying packages easy for embedded platforms. There are other Linux distribuitions avail-able, however, this manual will bases itself on ngstrm. Once that the Beagleboard is checkedand 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


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 sakeof example, $OEBASE will be /home/<user>/oe.

The base directory of your OpenEmbedded environment ($OEBASE) is the location wheresources will be checked out (or unpacked). You must choose a location with no symbolic linksabove it.

As next step the OE metadata (information, recipes, tools, etc) will be downloaded fromtheir 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

Con�gure OpenEmbedded

When you have downloaded all metadata �les, you need to set up OE indicating your targetboard, directory of OE recipes, and other �les. To do this, inside of $OEBASE create a newdirectory tree.

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

We will copy an existing con�guration �le into the newly created /conf directory, and edit itaccording to the con�guration of our machine.

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

$ gedit build/conf/local.conf

Edit the con�guration and read all the comments of the �le. Please note, that there are somelines on the end of this �le that need to be deleted when the con�guration is done. For now, wewill con�gure 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"


The value of the last two variables should be set in accordance to the number of processors onthe host machine. For the sake of example, the Intel Core i7 processor used in the developmenton this work, has 4 physical processors which support Hyper Threading, so a total of 8 processorswill be available to the OS. In this case in particular, the values of BB_NUMBER_THREADS andPARALLEL_MAKE were set equal to the number of processor. In case when no user interactionwill occur during the compilation, the value could be even higher than the number of processors.

As a last step of the con�guration, we create a �le named �config_oe.sh� in the OE rootfolder. 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 Pathsexport OEBASE=/home/agranizo/oeexport BBPATH=${OEBASE}/build:${OEBASE}/openembeddedexport PATH=${OEBASE}/bitbake/bin:$PATH

# Make shell look better..if [ "$BASH" ]; thenexport PS1="\[\033[01;32m\]BB:\[\033[00m\] ${PS1}"fi

Testing the con�guration with a single package

Once OpenEmbedded is con�gured, it is possible to compile Linux packages and complete distri-butions. The main interface to the build system is the bitbake command. For more informationabout refer to.

In order to test our OpenEmbedded installation, it's possible to compile a single package suchas nano. To do this, as a �rst step, the compilation environment is set up. As a next step weinvoke the Bitbake compiler, and pass the name of the recipe to be compiled (in this case thenano text editor). The process should take long time the �rst times, but as the packages arecreated 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 dependenciesNOTE: Preparing runqueueNOTE: 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)


NOTE: Tasks Summary: Attempted 669 tasks of which 637 didn’tneed to be rerun and 0 failed.

If the compilation ended successfully, the output should show 0 failed tasks. If the compilationended 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 toinstall additional packages using ipkg.

• console-image: Build an image without the X11, but including some extra tools (e.g.networking)

• x11-image: 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 buildthem. The resulting �les will be contained in two archives: one containing the Linux kerneland 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: StartedNOTE: package x11-image-1.0-r0: task do_build: SucceededNOTE: Tasks Summary: Attempted 5899 tasks of which 0 didn’t

need to be rerun and 0 failed.

At the end, all the �les used on the compilation, as well as results of the compilation willbe contained in the ${OEBASE}/build/tmp directory. The individual software packages willbe located in the ${OEBASE}/build/tmp/deploy/glibc/ipk and the complete Linux im-ages will be available in ${OEBASE}/build/tmp/deploy/glibc/images/beagleboard.For more information about the OE directory structure, please refer to the OpenEmbedded UserManual [?]. The �les which represent interest for us are:

• MLO-beagleboard - The �rst stage bootloader.

• u-boot-beagleboard.bin - The U-Boot bootloader for the Beagleboard.

• uImage-beagleboard.bin - A compressed Linux kernel.

• x11-image-beagleboard.tar.bz2 - A complete compressed Linux �lesystem.


• modules-beagleboard.tgz - Archive with the corresponding kernel modules.

In order to use these �les on the target board, a speci�cally partitioned micro SD card will beneeded.

2.5 SD card formatting

The Beagleboard-xM has any kind of on-board programmable �ash memory. Instead of on-boardmemory, it uses the micro SD both for the bootloader and OS �les. This approach has a veryuseful advantage, as now the board is almost foolproof. It is not necessary a JTAG or a serialport to reprogram a miscon�gured board. All that is needed is to insert a fresh reformattedmicro 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 itbootable with OMAP3 processors.[?]

Determine which device the SD Card Reader is on your system Plug the SD Cardinto the SD Card Reader and then plug the SD Card Reader into your system. After doing that,do the following to determine which device it is on your system.

$ dmesg | tail...[...] sd 19:0:0:0: [sdb] Mode Sense: 03 00 00 00[...] sd 19:0:0:0: [sdb] Assuming drive cache: write through[...] sd 19:0:0:0: [sdb] Assuming drive cache: write through[...] sdb: sdb1[...] sd 19:0:0:0: [sdb] Assuming drive cache: write through[...] sd 19:0:0:0: [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 Note there may bemore than one partition (only one shown in the example below). Note the "Mounted on" �eldin the above and use that name in the umount commands below. If the card is mounted, we willneed to unmount them.

$ df -hFilesystem Size Used Avail Use% Mounted on.../dev/sdb1 70M 2.6M 67M 4% /media/boot/dev/sdb2 3.6G 240M 3.2G 7% /media/ROOTFS$ umount /media/boot$ umount /media/ROOTFS

Start fdisk Be sure to choose the whole device (/dev/sdb), not a single partition (/de-v/sdb1).

$ sudo fdisk /dev/sdb


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

Command (m for help): p

Disk /dev/sdb: 3951 MB, 3951034368 bytes122 heads, 62 sectors/track, 1020 cylindersUnits = cylinders of 7564 * 512 = 3872768 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk 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 LinuxPartition 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): dPartition number (1-4): 1

Command (m for help): dSelected partition 2



Device Boot Start End Blocks Id System


Set the Geometry of the SD Card If the print out above does not show 255 heads, 63sectors/track, then do the following expert mode steps to redo the SD Card.

Go into expert mode.

Command (m for help): x

Set the number of heads to 255.

Expert command (m for help): hNumber of heads (1-256, default 122): 255

Set the number of sectors to 63.

Expert command (m for help): sNumber of sectors (1-63, default 62): 63Warning: setting sector offset for DOS compatiblity

Now calculate the number of Cylinders for your SD Card.

#cyl = floor(

#BytesOnCard255·63·512

)For this example #cyl = 3951034368/(255 ∗ 63 ∗ 512) = 480.35 We will use 480 (i.e. truncate,don't round).

Set the number of cylinders to the number calculated.

Expert command (m for help): cNumber 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



Device Boot Start End Blocks Id System


Create the FAT32 partition for booting and transferring �les from Windows

Command (m for help): nCommand action

e extendedp primary partition (1-4)

pPartition number (1-4): 1First cylinder (1-480, default 1): <enter>Using default value 1Last cylinder, +cylinders or +size{K,M,G} (1-480, default 480): +50

Command (m for help): tSelected partition 1Hex code (type L to list codes): cChanged system type of partition 1 to c (W95 FAT32 (LBA))

Mark it as bootable

Command (m for help): aPartition number (1-4): 1

Create the Linux partition for the root �le system

Command (m for help): nCommand action

e extendedp primary partition (1-4)

pPartition number (1-4): 2First cylinder (52-480, default 52): <enter>Using default value 52Last cylinder, +cylinders or +size{K,M,G} (52-480, default 480): <enter>Using default value 480

Print the partition table to Check Your Work




Device Boot Start End Blocks Id System/dev/sdb1 * 1 51 409626 c W95 FAT32 (LBA)/dev/sdb2 52 480 3445942+ 83 Linux

Save the new partition records on the SD Card All the work up to now has beentemporary. At this step the new partition table will be written on the card.

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

Calling ioctl() to re-read partition table.

Format the partitions The two partitions are given the volume names boot and rootfs

by these commands. You can substitute your own volume labels. If the card was previouslypartitioned, it should be unmounted.

$ sudo mkfs.msdos -F 32 /dev/sdb1 -n bootmkfs.msdos 3.0.9 (31 Jan 2010)

$ sudo mkfs.ext3 -L rootfs /dev/sdb2mke2fs 1.41.12 (17-May-2010)Filesystem label=ROOTFSOS type: LinuxBlock size=4096 (log=2)Fragment size=4096 (log=2)Stride=0 blocks, Stripe width=0 blocks215568 inodes, 861485 blocks43074 blocks (5.00%) reserved for the super userFirst data block=0Maximum filesystem blocks=88499814427 block groups32768 blocks per group, 32768 fragments per group7984 inodes per groupSuperblock backups stored on blocks:

32768, 98304, 163840, 229376, 294912, 819200

Writing inode tables: doneCreating journal (16384 blocks): doneWriting superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or180 days, whichever comes first. Use tune2fs -c or -i to override.


2.6 Linux Installation

Once the SD card is correctly partitioned and formatted, we can proceed with the installationof 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, itshould mount the card automatically. As next we will proceed to copy the compiled �les on itscorresponding partitions. Please note, that the �rst �le on the FAT32 partition should be theMLO X-Load �le.

$ df -hFilesystem Size Used Avail Use% Mounted on.../dev/sdb1 400M 3.3M 396M 1% /media/boot/dev/sdb2 3.3G 165M 3.0G 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 inorder to correctly set up the kernel and �lesystem options. The default boot script to be executedis the �le booot.scr, but when the User button is pressed, U-Boot will execute the user.scr script.The con�gurable 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, resolutionand 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 initsetenv dvimode ’1280x1024MR-16@60’run loaduimagerun mmcboot


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 theBeagleBoard. Proceed with the proceedure decribed in the Section 2.3 in order to boot up andtest the new Linux installation.

2.8 Con�guring the network

2.8.1 Con�guring Host's IP Address

2.8.2 Con�guring Host DHCP server

The objective is to minimize the con�guration of the Beagleboard and to make the most of thecon�guration on the host. The target will be given a IP addrtess according to the host's DHCPsetup. 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 con�guration �les

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

Edit the con�guration �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;}


In �le /etc/default/dhcp3-server will be de�ned which physical interface is the DHCPserver allowed to run on.

Listing 2.4: File dhcp3-servers (section)

# On what interfaces should the DHCP server (dhcpd) serveDHCP requests?

# Separate multiple interfaces with spaces, e.g. "eth0eth1".

INTERFACES="eth2"

Con�gure the startup settings of the dhcp3-server daemon. A group change of dhcp.conf �le willbe needed.

Listing 2.5: Auto-start con�guration of dhcp3-server

$ sudo update-rc.d -f dhcp3-server removesudo password for agranizo:Removing any system startup links for /etc/init.d/dhcp3-

server .../etc/rc1.d/K40dhcp3-server/etc/rc2.d/S40dhcp3-server

...

$ sudo update-rc.d dhcp3-server defaultsupdate-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 con�guration, the daemon will be added to the /etc/rc.local startup �le.This way, th daemon starts along with every user session. Please remember that the �le shouldend with ’exit 0’ line.

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

...ifup eth2service dhcp3-server startexit 0

2.8.3 Testing the con�guration

In order to test the con�guration on the on the host, please restart the PC and proceed asfollowing.


Listing 2.7: Test of dhcp3-server status

$ sudo service dhcp3-server statusStatus of DHCP server: dhcpd3 is running.$ netstat -au | grep bootpudp 0 0 *:bootps *:*$ tail /var/log/messages

To test the dhcp client on the target, please reboot and wait until the board obtains the con�guredIP address (192.168.0.2). The network interface on Beagleboard is usb0, as the network ismanaged 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:06inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1RX packets:7 errors:0 dropped:0 overruns:0 frame:0TX packets:25 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:1330 (1.2 KiB) TX bytes:3544 (3.4 KiB)...

2.8.4 Con�guring the SSH Server on Target

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

Listing 2.9: Generation of SSH encription keys on target

root@beagleboard:~# cd /etc/dropbearroot@beagleboard:/etc/dropbear# lsdropbear_rsa_host_keyroot@beagleboard:/etc/dropbear# rm -rf dropbear_rsa_host_key

#Generate a new keyroot@beagleboard:/etc/dropbear# dropbearkey -t rsa -f

dropbear_rsa_host_keyWill 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


# View the generated keyroot@beagleboard:/etc/dropbear# dropbearkey -y -f

dropbear_rsa_host_keyPublic key portion is:ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgwC4KEUi9HU1SAPoL+0lTD...

root@beagleboardFingerprint: md5 a1:8e:90:77:b7:91:f7:33:db:98:7f:01:35:8c:f0

:45

2.8.5 Con�guring a SSH Client on Host

The serial connection is used to access the linux console on Beagleboard. Another way to accessthe console is to con�gure a SSH access on it.

Listing 2.10: SSH client con�guration on host

$ cd ~/.sshagranizo@EMB-158:~/.ssh$ lltotal 12drwx------ 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 rootThe authenticity of host ’192.168.0.2 (192.168.0.2)’ can’t 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)? yPlease type ’yes’ or ’no’: yesWarning: Permanently added ’192.168.0.2’ (RSA) to the list of

known [email protected]’s 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 theoriginal OpenEmbedded �les from the newly developed one. To do this, there is a possibilityto con�gure layers. The concept of layers is basically that the user developed recipes will beseparated from the original OpenEmbedded recipes in a completely another directory. Thebene�ts of this approach are:

• A logical distinction between the user and the original �les.


• Possibility to reinstall OE without loosing the the development progress.

• Ease in the organization of the OE recipes and �les.

• Con�guration of the recipe priorities during the compilation.

The con�guration of the layer structure may be made in two �les:The �le ${OEBASE}/build/conf/bblayers.conf de�nes 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 incompatiblyLCONF_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 de�nes the name and the priority of the individuallayer, 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 higherpriority 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 toprefer our versions

BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILESBBFILES := "${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 easyto test modi�ed recipes but to keep the original �les. The precedence is set with BBFILE_PRIORITY_oevariable.

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

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


BBPATH .= ":${LAYERDIR}"

# We have a recipes directory, add to BBFILESBBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \

${LAYERDIR}/recipes/*/*.bbappend"

BBFILE_COLLECTIONS += "oe"BBFILE_PRIORITY_oe = "0"BBFILE_PATTERN_oe = "^${LAYERDIR}/"

2.9 Summary


Chapter 3

Toolchain and Cross-Compiling

3.1 Compiling a toolchain

OpenEmbedded has already a recipe for building an installable cross-compile toolchain. Thetoolchain recipe is located in ${OEBASE}/openembedded/recipes/meta and is called meta-toolchain.bb.The target architecture for cross-compiling is the already con�gured in �le ${OEBASE}/build/conf/local.confat the de�nition of the the variable MACHINE. In our case the cross compiler will be deestinedfor 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 ${OEBASE}/build/tmp/deploy/glibc/sdk direc-tory.

Listing 3.2: Toolchain Package installation

~/oe/build$ cd tmp/deploy/glibc/sdk/~/oe/build/tmp/deploy/glibc/sdk$ lsangstrom-2010.7-test-20110617-x86_64-linux-armv7a-linux-

gnueabi-toolchain-extras.tar.bz2angstrom-2010.7-test-20110617-x86_64-linux-armv7a-linux-

gnueabi-toolchain.tar.bz2~/oe/build/tmp/deploy/glibc/sdk$ sudo tar -C / -xjf ./

angstrom-2010.7-test-20110617-x86_64-linux-armv7a-linux-gnueabi-toolchain.tar.bz2

~/oe/build/tmp/deploy/glibc/sdk$ sudo tar -C / -xjvf ./angstrom-2010.7-test-20110617-x86_64-linux-armv7a-linux-gnueabi-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


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 �leshould 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 proto port100003 2 tcp 2049 nfs100003 3 tcp 2049 nfs100003 4 tcp 2049 nfs100227 2 tcp 2049100227 3 tcp 2049100003 2 udp 2049 nfs100003 3 udp 2049 nfs100003 4 udp 2049 nfs100227 2 udp 2049100227 3 udp 2049

Test the NFS Server:

$ 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. Eachline of the �le contains a single entry listing a service and a set of machines. When the servergets 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 itdoes, then the machine is allowed access.

• If the machine does not match an entry in hosts.allow, the server then checks hosts.denyto 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

http://tldp.org/HOWTO/NFS-HOWTO/server.html


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 = dgramprotocol = udpwait = yesport = 69user = nobodyserver = /usr/sbin/in.tftpdserver_args = -s /tftpbootdisable = noper_source = 11cps = 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

$ sudo /etc/init.d/xinetd start

5. Testing. Transferring �le hda.txt from 192.168.1.100 (Client using tftp) to 192.168.1.100(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.100tftp> put hda.txtSent 722 bytes in 0.0 secondstftp> quit$ ls -l /tftpboot/total 4-rwxrwxrwx 1 davids davids 707 2006-03-27 23:07 hda.txt


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 Con�guring an OPKG Repository on Host

4.10 Single workstation vs. Network setup

4.11 Summary


Chapter 5

Working with Eclipse

5.1 Getting and Installing Eclipse

5.2 Installing Eclipse CDT

5.3 Installing the plugins

5.4 Con�guring 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


32

Chapter 6

Emulation on the host

6.1 Getting QEMU

6.2 Compiling an Image

6.3 Summary


33

oe_manual

Documents

Transcript of oe_manual