%poky; ] > This chapter describes the standard SDK and how to use it. Information covers the pieces of the SDK, how to install it, and presents several task-based procedures common for developing with a standard SDK. The tasks you can perform using a standard SDK are also applicable when you are using an extensible SDK. For information on the differences when using an extensible SDK as compared to an extensible SDK, see the "Using the Extensible SDK" chapter.

The Standard SDK provides a cross-development toolchain and libraries tailored to the contents of a specific image. You would use the Standard SDK if you want a more traditional toolchain experience. The installed Standard SDK consists of several files and directories. Basically, it contains an SDK environment setup script, some configuration files, and host and target root filesystems to support usage. You can see the directory structure in the "Installed Standard SDK Directory Structure" section.

The first thing you need to do is install the SDK on your host development machine by running the .sh installation script. You can download a tarball installer, which includes the pre-built toolchain, the runqemu script, and support files from the appropriate directory under . Toolchains are available for 32-bit and 64-bit x86 development systems from the i686 and x86_64 directories, respectively. The toolchains the Yocto Project provides are based off the core-image-sato image and contain libraries appropriate for developing against that image. Each type of development system supports five or more target architectures. The names of the tarball installer scripts are such that a string representing the host system appears first in the filename and then is immediately followed by a string representing the target architecture. poky-glibc-host_system-image_type-arch-toolchain-release_version.sh Where: host_system is a string representing your development system: i686 or x86_64. image_type is the image for which the SDK was built. arch is a string representing the tuned target architecture: i586, x86_64, powerpc, mips, armv7a or armv5te release_version is a string representing the release number of the Yocto Project: &DISTRO;, &DISTRO;+snapshot For example, the following toolchain installer is for a 64-bit development host system and a i586-tuned target architecture based off the SDK for core-image-sato and using the current &DISTRO; snapshot: poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh The SDK and toolchains are self-contained and by default are installed into /opt/poky. However, when you run the SDK installer, you can choose an installation directory. You must change the permissions on the toolchain installer script so that it is executable: $ chmod +x poky-glibc-x86_64-core-image-sato-i586-toolchain-2.1.sh The following command shows how to run the installer given a toolchain tarball for a 64-bit x86 development host system and a 32-bit x86 target architecture. The example assumes the toolchain installer is located in ~/Downloads/. If you do not have write permissions for the directory into which you are installing the SDK, the installer notifies you and exits. Be sure you have write permissions in the directory and run the installer again. $ ./poky-glibc-x86_64-core-image-sato-i586-toolchain-2.1.sh Poky (Yocto Project Reference Distro) SDK installer version 2.0 =============================================================== Enter target directory for SDK (default: /opt/poky/2.1): You are about to install the SDK to "/opt/poky/2.1". Proceed[Y/n]? Y Extracting SDK.......................................................................done Setting it up...done SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /opt/poky/2.1/environment-setup-i586-poky-linux Again, reference the "Installed Standard SDK Directory Structure" section for more details on the resulting directory structure of the installed SDK.

Once you have the SDK installed, you must run the SDK environment setup script before you can actually use it. This setup script resides in the directory you chose when you installed the SDK. For information on where this setup script can reside, see the "Obtaining the SDK" Appendix. Before running the script, be sure it is the one that matches the architecture for which you are developing. Environment setup scripts begin with the string "environment-setup" and include as part of their name the tuned target architecture. For example, the command to source a setup script for an IA-based target machine using i586 tuning and located in the default SDK installation directory is as follows: $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux When you run the setup script, many environment variables are defined: SDKTARGETSYSROOT - The path to the sysroot used for cross-compilation PKG_CONFIG_PATH - The path to the target pkg-config files CONFIG_SITE - A GNU autoconf site file preconfigured for the target CC - The minimal command and arguments to run the C compiler CXX - The minimal command and arguments to run the C++ compiler CPP - The minimal command and arguments to run the C preprocessor AS - The minimal command and arguments to run the assembler LD - The minimal command and arguments to run the linker GDB - The minimal command and arguments to run the GNU Debugger STRIP - The minimal command and arguments to run 'strip', which strips symbols RANLIB - The minimal command and arguments to run 'ranlib' OBJCOPY - The minimal command and arguments to run 'objcopy' OBJDUMP - The minimal command and arguments to run 'objdump' AR - The minimal command and arguments to run 'ar' NM - The minimal command and arguments to run 'nm' TARGET_PREFIX - The toolchain binary prefix for the target tools CROSS_COMPILE - The toolchain binary prefix for the target tools CONFIGURE_FLAGS - The minimal arguments for GNU configure CFLAGS - Suggested C flags CXXFLAGS - Suggested C++ flags LDFLAGS - Suggested linker flags when you use CC to link CPPFLAGS - Suggested preprocessor flags

Once you have a suitable cross-toolchain installed, it is very easy to develop a project outside of the OpenEmbedded build system. This section presents a simple "Helloworld" example that shows how to set up, compile, and run the project.

Follow these steps to create a simple Autotools-based project: Create your directory: Create a clean directory for your project and then make that directory your working location: $ mkdir $HOME/helloworld $ cd $HOME/helloworld Populate the directory: Create hello.c, Makefile.am, and configure.in files as follows: For hello.c, include these lines: #include <stdio.h> main() { printf("Hello World!\n"); } For Makefile.am, include these lines: bin_PROGRAMS = hello hello_SOURCES = hello.c For configure.in, include these lines: AC_INIT(hello.c) AM_INIT_AUTOMAKE(hello,0.1) AC_PROG_CC AC_PROG_INSTALL AC_OUTPUT(Makefile) Source the cross-toolchain environment setup file: Installation of the cross-toolchain creates a cross-toolchain environment setup script in the directory that the SDK was installed. Before you can use the tools to develop your project, you must source this setup script. The script begins with the string "environment-setup" and contains the machine architecture, which is followed by the string "poky-linux". Here is an example that sources a script from the default SDK installation directory that uses the 32-bit Intel x86 Architecture and the &DISTRO_NAME; Yocto Project release: $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux Generate the local aclocal.m4 files and create the configure script: The following GNU Autotools generate the local aclocal.m4 files and create the configure script: $ aclocal $ autoconf Generate files needed by GNU coding standards: GNU coding standards require certain files in order for the project to be compliant. This command creates those files: $ touch NEWS README AUTHORS ChangeLog Generate the configure file: This command generates the configure: $ automake -a Cross-compile the project: This command compiles the project using the cross-compiler. The CONFIGURE_FLAGS environment variable provides the minimal arguments for GNU configure: $ ./configure ${CONFIGURE_FLAGS} Make and install the project: These two commands generate and install the project into the destination directory: $ make $ make install DESTDIR=./tmp Verify the installation: This command is a simple way to verify the installation of your project. Running the command prints the architecture on which the binary file can run. This architecture should be the same architecture that the installed cross-toolchain supports. $ file ./tmp/usr/local/bin/hello Execute your project: To execute the project in the shell, simply enter the name. You could also copy the binary to the actual target hardware and run the project there as well: $ ./hello As expected, the project displays the "Hello World!" message.

For an Autotools-based project, you can use the cross-toolchain by just passing the appropriate host option to configure.sh. The host option you use is derived from the name of the environment setup script found in the directory in which you installed the cross-toolchain. For example, the host option for an ARM-based target that uses the GNU EABI is armv5te-poky-linux-gnueabi. You will notice that the name of the script is environment-setup-armv5te-poky-linux-gnueabi. Thus, the following command works to update your project and rebuild it using the appropriate cross-toolchain tools: $ ./configure --host=armv5te-poky-linux-gnueabi \ --with-libtool-sysroot=sysroot_dir If the configure script results in problems recognizing the --with-libtool-sysroot=sysroot-dir option, regenerate the script to enable the support by doing the following and then run the script again: $ libtoolize --automake $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \ [-I dir_containing_your_project-specific_m4_macros] $ autoconf $ autoheader $ automake -a

For Makefile-based projects, the cross-toolchain environment variables established by running the cross-toolchain environment setup script are subject to general make rules. To illustrate this, consider the following four cross-toolchain environment variables: CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux LD=i586-poky-linux-ld --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux CFLAGS=-O2 -pipe -g -feliminate-unused-debug-types CXXFLAGS=-O2 -pipe -g -feliminate-unused-debug-types Now, consider the following three cases: Case 1 - No Variables Set in the Makefile: Because these variables are not specifically set in the Makefile, the variables retain their values based on the environment. Case 2 - Variables Set in the Makefile: Specifically setting variables in the Makefile during the build results in the environment settings of the variables being overwritten. Case 3 - Variables Set when the Makefile is Executed from the Command Line: Executing the Makefile from the command line results in the variables being overwritten with command-line content regardless of what is being set in the Makefile. In this case, environment variables are not considered unless you use the "-e" flag during the build: $ make -e file If you use this flag, then the environment values of the variables override any variables specifically set in the Makefile. For the list of variables set up by the cross-toolchain environment setup script, see the "Running the SDK Environment Setup Script" section.

If you are familiar with the popular Eclipse IDE, you can use an Eclipse Yocto Plug-in to allow you to develop, deploy, and test your application all from within Eclipse. This section describes general workflow using the SDK and Eclipse and how to configure and set up Eclipse.

The following figure and supporting list summarize the application development general workflow that employs both the SDK Eclipse. Prepare the host system for the Yocto Project: See "Supported Linux Distributions" and "Required Packages for the Host Development System" sections both in the Yocto Project Reference Manual for requirements. In particular, be sure your host system has the xterm package installed. Secure the Yocto Project kernel target image: You must have a target kernel image that has been built using the OpenEmbedded build system. Depending on whether the Yocto Project has a pre-built image that matches your target architecture and where you are going to run the image while you develop your application (QEMU or real hardware), the area from which you get the image differs. Download the image from machines if your target architecture is supported and you are going to develop and test your application on actual hardware. Download the image from machines/qemu if your target architecture is supported and you are going to develop and test your application using the QEMU emulator. Build your image if you cannot find a pre-built image that matches your target architecture. If your target architecture is similar to a supported architecture, you can modify the kernel image before you build it. See the "Patching the Kernel" section in the Yocto Project Development manual for an example. For information on pre-built kernel image naming schemes for images that can run on the QEMU emulator, see the Yocto Project Software Development Kit (SDK) Developer's Guide. Install the SDK: The SDK provides a target-specific cross-development toolchain, the root filesystem, the QEMU emulator, and other tools that can help you develop your application. For information on how to install the SDK, see the "Installing the SDK" section. Secure the target root filesystem and the Cross-development toolchain: You need to find and download the appropriate root filesystem and the cross-development toolchain. You can find the tarballs for the root filesystem in the same area used for the kernel image. Depending on the type of image you are running, the root filesystem you need differs. For example, if you are developing an application that runs on an image that supports Sato, you need to get a root filesystem that supports Sato. You can find the cross-development toolchains at toolchains. Be sure to get the correct toolchain for your development host and your target architecture. See the "Locating Pre-Built SDK Installers" section for information and the "Installing the SDK" section for installation information. Create and build your application: At this point, you need to have source files for your application. Once you have the files, you can use the Eclipse IDE to import them and build the project. If you are not using Eclipse, you need to use the cross-development tools you have installed to create the image. Deploy the image with the application: If you are using the Eclipse IDE, you can deploy your image to the hardware or to QEMU through the project's preferences. If you are not using the Eclipse IDE, then you need to deploy the application to the hardware using other methods. Or, if you are using QEMU, you need to use that tool and load your image in for testing. See the "Using the Quick EMUlator (QEMU)" chapter in the Yocto Project Development Manual for information on using QEMU. Test and debug the application: Once your application is deployed, you need to test it. Within the Eclipse IDE, you can use the debugging environment along with the set of installed user-space tools to debug your application. Of course, the same user-space tools are available separately if you choose not to use the Eclipse IDE.

The Eclipse IDE is a popular development environment and it fully supports development using the Yocto Project. This release of the Yocto Project supports both the Luna and Kepler versions of the Eclipse IDE. Thus, the following information provides setup information for both versions. When you install and configure the Eclipse Yocto Project Plug-in into the Eclipse IDE, you maximize your Yocto Project experience. Installing and configuring the Plug-in results in an environment that has extensions specifically designed to let you more easily develop software. These extensions allow for cross-compilation, deployment, and execution of your output into a QEMU emulation session as well as actual target hardware. You can also perform cross-debugging and profiling. The environment also supports a suite of tools that allows you to perform remote profiling, tracing, collection of power data, collection of latency data, and collection of performance data. This section describes how to install and configure the Eclipse IDE Yocto Plug-in and how to use it to develop your application.

To develop within the Eclipse IDE, you need to do the following: Install the optimal version of the Eclipse IDE. Configure the Eclipse IDE. Install the Eclipse Yocto Plug-in. Configure the Eclipse Yocto Plug-in. Do not install Eclipse from your distribution's package repository. Be sure to install Eclipse from the official Eclipse download site as directed in the next section.

It is recommended that you have the Luna SR2 (4.4.2) version of the Eclipse IDE installed on your development system. However, if you currently have the Kepler 4.3.2 version installed and you do not want to upgrade the IDE, you can configure Kepler to work with the Yocto Project. If you do not have the Luna SR2 (4.4.2) Eclipse IDE installed, you can find the tarball at . From that site, choose the appropriate download from the "Eclipse IDE for C/C++ Developers". This version contains the Eclipse Platform, the Java Development Tools (JDT), and the Plug-in Development Environment. Once you have downloaded the tarball, extract it into a clean directory. For example, the following commands unpack and install the downloaded Eclipse IDE tarball into a clean directory using the default name eclipse: $ cd ~ $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz

This section presents the steps needed to configure the Eclipse IDE. Before installing and configuring the Eclipse Yocto Plug-in, you need to configure the Eclipse IDE. Follow these general steps: Start the Eclipse IDE. Make sure you are in your Workbench and select "Install New Software" from the "Help" pull-down menu. Select Luna - &ECLIPSE_LUNA_URL; from the "Work with:" pull-down menu. For Kepler, select Kepler - &ECLIPSE_KEPLER_URL; Expand the box next to "Linux Tools" and select the Linux Tools LTTng Tracer Control, Linux Tools LTTng Userspace Analysis, and LTTng Kernel Analysis boxes. If these selections do not appear in the list, that means the items are already installed. For Kepler, select LTTng - Linux Tracing Toolkit box. Expand the box next to "Mobile and Device Development" and select the following boxes. Again, if any of the following items are not available for selection, that means the items are already installed: C/C++ Remote Launch (Requires RSE Remote System Explorer) Remote System Explorer End-user Runtime Remote System Explorer User Actions Target Management Terminal (Core SDK) TCF Remote System Explorer add-in TCF Target Explorer Expand the box next to "Programming Languages" and select the C/C++ Autotools Support and C/C++ Development Tools boxes. For Luna, these items do not appear on the list as they are already installed. Complete the installation and restart the Eclipse IDE.

You can install the Eclipse Yocto Plug-in into the Eclipse IDE one of two ways: use the Yocto Project's Eclipse Update site to install the pre-built plug-in or build and install the plug-in from the latest source code.

To install the Eclipse Yocto Plug-in from the update site, follow these steps: Start up the Eclipse IDE. In Eclipse, select "Install New Software" from the "Help" menu. Click "Add..." in the "Work with:" area. Enter &ECLIPSE_DL_PLUGIN_URL;/luna in the URL field and provide a meaningful name in the "Name" field. If you are using Kepler, use &ECLIPSE_DL_PLUGIN_URL;/kepler in the URL field. Click "OK" to have the entry added to the "Work with:" drop-down list. Select the entry for the plug-in from the "Work with:" drop-down list. Check the boxes next to Yocto Project ADT Plug-in, Yocto Project Bitbake Commander Plug-in, and Yocto Project Documentation plug-in. Complete the remaining software installation steps and then restart the Eclipse IDE to finish the installation of the plug-in. You can click "OK" when prompted about installing software that contains unsigned content.

To install the Eclipse Yocto Plug-in from the latest source code, follow these steps: Be sure your development system is not using OpenJDK to build the plug-in by doing the following: Use the Oracle JDK. If you don't have that, go to and download the latest appropriate Java SE Development Kit tarball for your development system and extract it into your home directory. In the shell you are going to do your work, export the location of the Oracle Java. The previous step creates a new folder for the extracted software. You need to use the following export command and provide the specific location: export PATH=~/extracted_jdk_location/bin:$PATH In the same shell, create a Git repository with: $ cd ~ $ git clone git://git.yoctoproject.org/eclipse-poky Be sure to checkout the correct tag. For example, if you are using Luna, do the following: $ git checkout luna/yocto-&DISTRO; This puts you in a detached HEAD state, which is fine since you are only going to be building and not developing. If you are building kepler, checkout the kepler/yocto-&DISTRO; branch. Change to the scripts directory within the Git repository: $ cd scripts Set up the local build environment by running the setup script: $ ./setup.sh When the script finishes execution, it prompts you with instructions on how to run the build.sh script, which is also in the scripts directory of the Git repository created earlier. Run the build.sh script as directed. Be sure to provide the tag name, documentation branch, and a release name. Here is an example that uses the luna/yocto-&DISTRO; tag, the master documentation branch, and &DISTRO_NAME; for the release name: $ ECLIPSE_HOME=/home/scottrif/eclipse-poky/scripts/eclipse ./build.sh luna/yocto-&DISTRO; master &DISTRO_NAME; 2>&1 | tee -a build.log After running the script, the file org.yocto.sdk-release-date-archive.zip is in the current directory. If necessary, start the Eclipse IDE and be sure you are in the Workbench. Select "Install New Software" from the "Help" pull-down menu. Click "Add". Provide anything you want in the "Name" field. Click "Archive" and browse to the ZIP file you built in step eight. This ZIP file should not be "unzipped", and must be the *archive.zip file created by running the build.sh script. Click the "OK" button. Check the boxes that appear in the installation window to install the Yocto Project ADT Plug-in, Yocto Project Bitbake Commander Plug-in, and the Yocto Project Documentation plug-in. Finish the installation by clicking through the appropriate buttons. You can click "OK" when prompted about installing software that contains unsigned content. Restart the Eclipse IDE if necessary. At this point you should be able to configure the Eclipse Yocto Plug-in as described in the "Configuring the Eclipse Yocto Plug-in" section.

Configuring the Eclipse Yocto Plug-in involves setting the Cross Compiler options and the Target options. The configurations you choose become the default settings for all projects. You do have opportunities to change them later when you configure the project (see the following section). To start, you need to do the following from within the Eclipse IDE: Choose "Preferences" from the "Window" menu to display the Preferences Dialog. Click "Yocto Project ADT" to display the configuration screen.

To configure the Cross Compiler Options, you must select the type of toolchain, point to the toolchain, specify the sysroot location, and select the target architecture. Selecting the Toolchain Type: Choose between Standalone pre-built toolchain and Build system derived toolchain for Cross Compiler Options. Standalone Pre-built Toolchain: Select this mode when you are using a stand-alone cross-toolchain. For example, suppose you are an application developer and do not need to build a target image. Instead, you just want to use an architecture-specific toolchain on an existing kernel and target root filesystem. Build System Derived Toolchain: Select this mode if the cross-toolchain has been installed and built as part of the Build Directory. When you select Build system derived toolchain, you are using the toolchain bundled inside the Build Directory. Point to the Toolchain: If you are using a stand-alone pre-built toolchain, you should be pointing to where it is installed. See the "Installing the SDK" section for information about how the SDK is installed. If you are using a system-derived toolchain, the path you provide for the Toolchain Root Location field is the Build Directory. See the "Building an SDK Installer" section. Specify the Sysroot Location: This location is where the root filesystem for the target hardware resides. The location of the sysroot filesystem depends on where you separately extracted and installed the filesystem. For information on how to install the toolchain and on how to extract and install the sysroot filesystem, see the "Building an SDK Installer" section. Select the Target Architecture: The target architecture is the type of hardware you are going to use or emulate. Use the pull-down Target Architecture menu to make your selection. The pull-down menu should have the supported architectures. If the architecture you need is not listed in the menu, you will need to build the image. See the "Building Images" section of the Yocto Project Quick Start for more information.

You can choose to emulate hardware using the QEMU emulator, or you can choose to run your image on actual hardware. QEMU: Select this option if you will be using the QEMU emulator. If you are using the emulator, you also need to locate the kernel and specify any custom options. If you selected Build system derived toolchain, the target kernel you built will be located in the Build Directory in tmp/deploy/images/machine directory. If you selected Standalone pre-built toolchain, the pre-built image you downloaded is located in the directory you specified when you downloaded the image. Most custom options are for advanced QEMU users to further customize their QEMU instance. These options are specified between paired angled brackets. Some options must be specified outside the brackets. In particular, the options serial, nographic, and kvm must all be outside the brackets. Use the man qemu command to get help on all the options and their use. The following is an example: serial ‘<-m 256 -full-screen>’ Regardless of the mode, Sysroot is already defined as part of the Cross-Compiler Options configuration in the Sysroot Location: field. External HW: Select this option if you will be using actual hardware. Click the "OK" to save your plug-in configurations.

You can create two types of projects: Autotools-based, or Makefile-based. This section describes how to create Autotools-based projects from within the Eclipse IDE. For information on creating Makefile-based projects in a terminal window, see the "Makefile-Based Projects" section. Do not use special characters in project names (e.g. spaces, underscores, etc.). Doing so can cause configuration to fail. To create a project based on a Yocto template and then display the source code, follow these steps: Select "Project" from the "File -> New" menu. Double click CC++. Double click C Project to create the project. Expand Yocto Project ADT Autotools Project. Select Hello World ANSI C Autotools Project. This is an Autotools-based project based on a Yocto template. Put a name in the Project name: field. Do not use hyphens as part of the name. Click "Next". Add information in the Author and Copyright notice fields. Be sure the License field is correct. Click "Finish". If the "open perspective" prompt appears, click "Yes" so that you in the C/C++ perspective. The left-hand navigation pane shows your project. You can display your source by double clicking the project's source file.

The earlier section, "Configuring the Eclipse Yocto Plug-in", sets up the default project configurations. You can override these settings for a given project by following these steps: Select "Change Yocto Project Settings" from the "Project" menu. This selection brings up the Yocto Project Settings Dialog and allows you to make changes specific to an individual project. By default, the Cross Compiler Options and Target Options for a project are inherited from settings you provided using the Preferences Dialog as described earlier in the "Configuring the Eclipse Yocto Plug-in" section. The Yocto Project Settings Dialog allows you to override those default settings for a given project. Make your configurations for the project and click "OK". Right-click in the navigation pane and select "Reconfigure Project" from the pop-up menu. This selection reconfigures the project by running autogen.sh in the workspace for your project. The script also runs libtoolize, aclocal, autoconf, autoheader, automake --a, and ./configure. Click on the "Console" tab beneath your source code to see the results of reconfiguring your project.

To build the project select "Build Project" from the "Project" menu. The console should update and you can note the cross-compiler you are using. When building "Yocto Project ADT Autotools" projects, the Eclipse IDE might display error messages for Functions/Symbols/Types that cannot be "resolved", even when the related include file is listed at the project navigator and when the project is able to build. For these cases only, it is recommended to add a new linked folder to the appropriate sysroot. Use these steps to add the linked folder: Select the project. Select "Folder" from the File > New menu. In the "New Folder" Dialog, select "Link to alternate location (linked folder)". Click "Browse" to navigate to the include folder inside the same sysroot location selected in the Yocto Project configuration preferences. Click "OK". Click "Finish" to save the linked folder.

To start the QEMU emulator from within Eclipse, follow these steps: See the "Using the Quick EMUlator (QEMU)" chapter in the Yocto Project Development Manual for more information on using QEMU. Expose and select "External Tools" from the "Run" menu. Your image should appear as a selectable menu item. Select your image from the menu to launch the emulator in a new window. If needed, enter your host root password in the shell window at the prompt. This sets up a Tap 0 connection needed for running in user-space NFS mode. Wait for QEMU to launch. Once QEMU launches, you can begin operating within that environment. One useful task at this point would be to determine the IP Address for the user-space NFS by using the ifconfig command.

Once the QEMU emulator is running the image, you can deploy your application using the Eclipse IDE and then use the emulator to perform debugging. Follow these steps to deploy the application. Select "Debug Configurations..." from the "Run" menu. In the left area, expand C/C++Remote Application. Locate your project and select it to bring up a new tabbed view in the Debug Configurations Dialog. Enter the absolute path into which you want to deploy the application. Use the "Remote Absolute File Path for C/C++Application:" field. For example, enter /usr/bin/programname. Click on the "Debugger" tab to see the cross-tool debugger you are using. Click on the "Main" tab. Create a new connection to the QEMU instance by clicking on "new". Select TCF, which means Target Communication Framework. Click "Next". Clear out the "host name" field and enter the IP Address determined earlier. Click "Finish" to close the New Connections Dialog. Use the drop-down menu now in the "Connection" field and pick the IP Address you entered. Click "Debug" to bring up a login screen and login. Accept the debug perspective.

As mentioned earlier in the manual, several tools exist that enhance your development experience. These tools are aids in developing and debugging applications and images. You can run these user-space tools from within the Eclipse IDE through the "YoctoProjectTools" menu. Once you pick a tool, you need to configure it for the remote target. Every tool needs to have the connection configured. You must select an existing TCF-based RSE connection to the remote target. If one does not exist, click "New" to create one. Here are some specifics about the remote tools: OProfile: Selecting this tool causes the oprofile-server on the remote target to launch on the local host machine. The oprofile-viewer must be installed on the local host machine and the oprofile-server must be installed on the remote target, respectively, in order to use. You must compile and install the oprofile-viewer from the source code on your local host machine. Furthermore, in order to convert the target's sample format data into a form that the host can use, you must have OProfile version 0.9.4 or greater installed on the host. You can locate both the viewer and server from . You can also find more information on setting up and using this tool in the "oprofile" section of the Yocto Project Profiling and Tracing Manual. The oprofile-server is installed by default on the core-image-sato-sdk image. Lttng2.0 trace import: Selecting this tool transfers the remote target's Lttng tracing data back to the local host machine and uses the Lttng Eclipse plug-in to graphically display the output. For information on how to use Lttng to trace an application, see and the "LTTng (Linux Trace Toolkit, next generation)" section, which is in the Yocto Project Profiling and Tracing Manual. Do not use Lttng-user space (legacy) tool. This tool no longer has any upstream support. Before you use the Lttng2.0 trace import tool, you need to setup the Lttng Eclipse plug-in and create a Tracing project. Do the following: Select "Open Perspective" from the "Window" menu and then select "Other..." to bring up a menu of other perspectives. Choose "Tracing". Click "OK" to change the Eclipse perspective into the Tracing perspective. Create a new Tracing project by selecting "Project" from the "File -> New" menu. Choose "Tracing Project" from the "Tracing" menu and click "Next". Provide a name for your tracing project and click "Finish". Generate your tracing data on the remote target. Select "Lttng2.0 trace import" from the "Yocto Project Tools" menu to start the data import process. Specify your remote connection name. For the Ust directory path, specify the location of your remote tracing data. Make sure the location ends with ust (e.g. /usr/mysession/ust). Click "OK" to complete the import process. The data is now in the local tracing project you created. Right click on the data and then use the menu to Select "Generic CTF Trace" from the "Trace Type... -> Common Trace Format" menu to map the tracing type. Right click the mouse and select "Open" to bring up the Eclipse Lttng Trace Viewer so you view the tracing data. PowerTOP: Selecting this tool runs PowerTOP on the remote target machine and displays the results in a new view called PowerTOP. The "Time to gather data(sec):" field is the time passed in seconds before data is gathered from the remote target for analysis. The "show pids in wakeups list:" field corresponds to the -p argument passed to PowerTOP. LatencyTOP and Perf: LatencyTOP identifies system latency, while Perf monitors the system's performance counter registers. Selecting either of these tools causes an RSE terminal view to appear from which you can run the tools. Both tools refresh the entire screen to display results while they run. For more information on setting up and using perf, see the "perf" section in the Yocto Project Profiling and Tracing Manual. SystemTap: Systemtap is a tool that lets you create and reuse scripts to examine the activities of a live Linux system. You can easily extract, filter, and summarize data that helps you diagnose complex performance or functional problems. For more information on setting up and using SystemTap, see the SystemTap Documentation. yocto-bsp: The yocto-bsp tool lets you quickly set up a Board Support Package (BSP) layer. The tool requires a Metadata location, build location, BSP name, BSP output location, and a kernel architecture. For more information on the yocto-bsp tool outside of Eclipse, see the "Creating a new BSP Layer Using the yocto-bsp Script" section in the Yocto Project Board Support Package (BSP) Developer's Guide.

Describe the specific task you are going to accomplish with the SDK. Provide a diagram showing the rough flow of the task. Provide specific steps using a real example that works through the task.

Describe the specific task you are going to accomplish with the SDK. Provide a diagram showing the rough flow of the task. Provide specific steps using a real example that works through the task.

Describe the specific task you are going to accomplish with the SDK. Provide a diagram showing the rough flow of the task. Provide specific steps using a real example that works through the task.