From cdacd8764b26b945253c7a94941806ce34a44da6 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 10 Jan 2013 18:55:01 -0600 Subject: profile-manual: Copied in raw "Examples" chapter. I put the raw text is for chapter 4. No editing. (From yocto-docs rev: e4a017624595394f86f469e15c1c8ad13e82206d) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../profile-manual/profile-manual-examples.xml | 1906 +------------------- 1 file changed, 15 insertions(+), 1891 deletions(-) (limited to 'documentation/profile-manual') diff --git a/documentation/profile-manual/profile-manual-examples.xml b/documentation/profile-manual/profile-manual-examples.xml index 442cab3036..e4363ca632 100644 --- a/documentation/profile-manual/profile-manual-examples.xml +++ b/documentation/profile-manual/profile-manual-examples.xml @@ -2,1911 +2,35 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ %poky; ] > - + -Common Development Models +Real-World Examples - Many development models exist for which you can use the Yocto Project. - This chapter overviews simple methods that use tools provided by the - Yocto Project: - - System Development: - System Development covers Board Support Package (BSP) development and kernel - modification or configuration. - For an example on how to create a BSP, see the - "Creating a New BSP Layer Using the yocto-bsp Script" - section in the Yocto Project Board Support Package (BSP) Developer's Guide. - - User Application Development: - User Application Development covers development of applications that you intend - to run on some target hardware. - For information on how to set up your host development system for user-space - application development, see the - Yocto Project Application Developer's Guide. - For a simple example of user-space application development using the - Eclipse IDE, see the - "Application - Development Workflow" section. - - Temporary Source Code Modification: - Direct modification of temporary source code is a convenient development model - to quickly iterate and develop towards a solution. - Once the solution has been implemented, you should of course take steps to - get the changes upstream and applied in the affected recipes. - Image Development using Hob: - You can use the Hob to build - custom operating system images within the build environment. - Hob provides an efficient interface to the OpenEmbedded build system. - Using a Development Shell: - You can use a devshell to efficiently debug commands or simply - edit packages. - Working inside a development shell is a quick way to set up the OpenEmbedded build - environment to work on parts of a project. - + This chapter contains real-world examples. -
- System Development Workflow +
+ Slow Write Speed on Line Images - System development involves modification or creation of an image that you want to run on - a specific hardware target. - Usually, when you want to create an image that runs on embedded hardware, the image does - not require the same number of features that a full-fledged Linux distribution provides. - Thus, you can create a much smaller image that is designed to use only the - features for your particular hardware. + In one of our previous releases (denzil), users noticed that booting + off of a live image and writing to disk was noticeably slower. + This included the boot itself, especially the first one, since first + boots tend to do a significant amount of writing due to certain + post-install scripts. - To help you understand how system development works in the Yocto Project, this section - covers two types of image development: BSP creation and kernel modification or - configuration. + The problem (and solution) was discovered by using the Yocto tracing + tools, in this case 'perf stat', 'perf script', 'perf record' + and 'perf report'. -
- Developing a Board Support Package (BSP) - - - A BSP is a package of recipes that, when applied during a build, results in - an image that you can run on a particular board. - Thus, the package when compiled into the new image, supports the operation of the board. - - - - For a brief list of terms used when describing the development process in the Yocto Project, - see the "Yocto Project Terms" section. - - - - The remainder of this section presents the basic steps used to create a BSP - using the Yocto Project's - BSP Tools. - For an example that shows how to create a new layer using the tools, see the - "Creating a New BSP Layer Using the yocto-bsp Script" - section in the Yocto Project Board Support Package (BSP) Developer's Guide. - - - - The following illustration and list summarize the BSP creation general workflow. - - - - - - - - - Set up your host development system to support - development using the Yocto Project: See the - "The Linux Distributions" - and the - "The Packages" sections both - in the Yocto Project Quick Start for requirements. - Establish a local copy of the project files on your - system: You need this Source - Directory available on your host system. - Having these files on your system gives you access to the build - process and to the tools you need. - For information on how to set up the - Source Directory, see the - "Getting Setup" section. - Establish the meta-intel - repository on your system: Having local copies of the - supported BSP layers on your system gives you access to the build - process and to the tools you need for creating a BSP. - For information on how to get these files, see the - "Getting Setup" section. - Create your own BSP layer using the - yocto-bsp script: - Layers are ideal for - isolating and storing work for a given piece of hardware. - A layer is really just a location or area in which you place the recipes for your BSP. - In fact, a BSP is, in itself, a special type of layer. - The simplest way to create a new BSP layer that is compliant with the - Yocto Project is to use the yocto-bsp script. - For information about that script, see the - "Creating a New BSP Layer Using the yocto-bsp Script" - section in the Yocto Project Board Support (BSP) Developer's Guide. - - - Another example that illustrates a layer is an application. - Suppose you are creating an application that has library or other dependencies in - order for it to compile and run. - The layer, in this case, would be where all the recipes that define those dependencies - are kept. - The key point for a layer is that it is an isolated area that contains - all the relevant information for the project that the OpenEmbedded build - system knows about. - For more information on layers, see the - "Understanding and Creating Layers" - section. - For more information on BSP layers, see the - "BSP Layers" section in the - Yocto Project Board Support Package (BSP) Developer's Guide. - Four BSPs exist that are part of the - Yocto Project release: atom-pc, beagleboard, - mpc8315e, and routerstationpro. - The recipes and configurations for these four BSPs are located and dispersed - within the Source Directory. - On the other hand, BSP layers for Cedar Trail, Chief River, Crown Bay, - Crystal Forest, Emenlow, Fish River, Fish River 2, Jasper Forest, N450, - Romley, sys940x, Sugar Bay, and tlk exist in their own separate layers - within the larger meta-intel layer. - When you set up a layer for a new BSP, you should follow a standard layout. - This layout is described in the section - "Example Filesystem Layout" - section of the Board Support Package (BSP) Development Guide. - In the standard layout, you will notice a suggested structure for recipes and - configuration information. - You can see the standard layout for a BSP by examining - any supported BSP found in the meta-intel layer inside - the Source Directory. - Make configuration changes to your new BSP - layer: The standard BSP layer structure organizes the files you need - to edit in conf and several recipes-* - directories within the BSP layer. - Configuration changes identify where your new layer is on the local system - and identify which kernel you are going to use. - When you run the yocto-bsp script you are able to interactively - configure many things for the BSP (e.g. keyboard, touchscreen, and so forth). - - Make recipe changes to your new BSP layer: Recipe - changes include altering recipes (.bb files), removing - recipes you don't use, and adding new recipes or append files - (.bbappend) that you need to support your hardware. - - Prepare for the build: Once you have made all the - changes to your BSP layer, there remains a few things - you need to do for the OpenEmbedded build system in order for it to create your image. - You need to get the build environment ready by sourcing an environment setup script - and you need to be sure two key configuration files are configured appropriately: - the conf/local.conf and the - conf/bblayers.conf file. - You must make the OpenEmbedded build system aware of your new layer. - See the - "Enabling Your Layer" section - for information on how to let the build system know about your new layer. - The entire process for building an image is overviewed in the section - "Building an Image" section - of the Yocto Project Quick Start. - You might want to reference this information. - Build the image: The OpenEmbedded build system - uses the BitBake tool to build images based on the type of image you want to create. - You can find more information about BitBake in the user manual, which is found in the - bitbake/doc/manual directory of the - Source Directory. - The build process supports several types of images to satisfy different needs. - See the - "Images" chapter - in the Yocto Project Reference Manual for information on - supported images. - - - - - You can view a video presentation on "Building Custom Embedded Images with Yocto" - at Free Electrons. - You can also find supplemental information in - - The Board Support Package (BSP) Development Guide. - Finally, there is wiki page write up of the example also located - - here that you might find helpful. - -
- -
- <anchor id='kernel-spot' />Modifying the Kernel - - - Kernel modification involves changing the Yocto Project kernel, which could involve changing - configuration options as well as adding new kernel recipes. - Configuration changes can be added in the form of configuration fragments, while recipe - modification comes through the kernel's recipes-kernel area - in a kernel layer you create. - - - - The remainder of this section presents a high-level overview of the Yocto Project - kernel architecture and the steps to modify the kernel. - For a complete discussion of the kernel, see the - Yocto Project Kernel Architecture and Use Manual. - You can reference the - "Patching the Kernel" section - for an example that changes the source code of the kernel. - For information on how to configure the kernel, see the - "Configuring the Kernel" section. - - -
- Kernel Overview - - - Traditionally, when one thinks of a patched kernel, they think of a base kernel - source tree and a fixed structure that contains kernel patches. - The Yocto Project, however, employs mechanisms, that in a sense, result in a kernel source - generator. - By the end of this section, this analogy will become clearer. - - - - You can find a web interface to the Yocto Project kernel source repositories at - . - If you look at the interface, you will see to the left a grouping of - Git repositories titled "Yocto Linux Kernel." - Within this group, you will find several kernels supported by - the Yocto Project: - - linux-yocto-2.6.34 - The - stable Yocto Project kernel that is based on the Linux 2.6.34 released kernel. - linux-yocto-2.6.37 - The - stable Yocto Project kernel that is based on the Linux 2.6.37 released kernel. - linux-yocto-3.0 - The stable - Yocto Project kernel that is based on the Linux 3.0 released kernel. - linux-yocto-3.0-1.1.x - The - stable Yocto Project kernel to use with the Yocto Project Release 1.1.x. This kernel - is based on the Linux 3.0 released kernel. - linux-yocto-3.2 - The - stable Yocto Project kernel to use with the Yocto Project Release 1.2. This kernel - is based on the Linux 3.2 released kernel. - linux-yocto-3.4 - The - stable Yocto Project kernel to use with the Yocto Project Release 1.3. This kernel - is based on the Linux 3.4 released kernel. - linux-yocto-dev - A development - kernel based on the latest upstream release candidate available. - - - - - The kernels are maintained using the Git revision control system - that structures them using the familiar "tree", "branch", and "leaf" scheme. - Branches represent diversions from general code to more specific code, while leaves - represent the end-points for a complete and unique kernel whose source files - when gathered from the root of the tree to the leaf accumulate to create the files - necessary for a specific piece of hardware and its features. - The following figure displays this concept: - - - - - - Within the figure, the "Kernel.org Branch Point" represents the point in the tree - where a supported base kernel is modified from the Linux kernel. - For example, this could be the branch point for the linux-yocto-3.0 - kernel. - Thus, everything further to the right in the structure is based on the - linux-yocto-3.0 kernel. - Branch points to right in the figure represent where the - linux-yocto-3.0 kernel is modified for specific hardware - or types of kernels, such as real-time kernels. - Each leaf thus represents the end-point for a kernel designed to run on a specific - targeted device. - - - - The overall result is a Git-maintained repository from which all the supported - kernel types can be derived for all the supported devices. - A big advantage to this scheme is the sharing of common features by keeping them in - "larger" branches within the tree. - This practice eliminates redundant storage of similar features shared among kernels. - - - - Keep in mind the figure does not take into account all the supported Yocto - Project kernel types, but rather shows a single generic kernel just for conceptual purposes. - Also keep in mind that this structure represents the Yocto Project source repositories - that are either pulled from during the build or established on the host development system - prior to the build by either cloning a particular kernel's Git repository or by - downloading and unpacking a tarball. - - - - Upstream storage of all the available kernel source code is one thing, while - representing and using the code on your host development system is another. - Conceptually, you can think of the kernel source repositories as all the - source files necessary for all the supported kernels. - As a developer, you are just interested in the source files for the kernel on - on which you are working. - And, furthermore, you need them available on your host system. - - - - Kernel source code is available on your host system a couple of different - ways. - If you are working in the kernel all the time, you probably would want - to set up your own local Git repository of the kernel tree. - If you just need to make some patches to the kernel, you can get at - temporary kernel source files extracted and used during the OpenEmbedded - build system. - We will just talk about working with the temporary source code. - - - - What happens during the build? - When you build the kernel on your development system, all files needed for the build - are taken from the source repositories pointed to by the - SRC_URI variable - and gathered in a temporary work area - where they are subsequently used to create the unique kernel. - Thus, in a sense, the process constructs a local source tree specific to your - kernel to generate the new kernel image - a source generator if you will. - - The following figure shows the temporary file structure - created on your host system when the build occurs. - This - Build Directory contains all the - source files used during the build. - - - - - - - - Again, for a complete discussion of the Yocto Project kernel's architecture and its - branching strategy, see the - Yocto Project Kernel Architecture and Use Manual. - You can also reference the - "Patching the Kernel" - section for a detailed example that modifies the kernel. - -
- -
- Kernel Modification Workflow - - - This illustration and the following list summarizes the kernel modification general workflow. - - - - - - - - - Set up your host development system to support - development using the Yocto Project: See - "The Linux Distributions" and - "The Packages" sections both - in the Yocto Project Quick Start for requirements. - Establish a local copy of project files on your - system: Having the Source - Directory on your system gives you access to the build process and tools - you need. - For information on how to get these files, see the bulleted item - "Yocto Project Release" earlier in this manual. - - Establish the temporary kernel source files: - Temporary kernel source files are kept in the Build Directory created by the - OpenEmbedded build system when you run BitBake. - If you have never built the kernel you are interested in, you need to run - an initial build to establish local kernel source files. - If you are building an image for the first time, you need to get the build - environment ready by sourcing - the environment setup script. - You also need to be sure two key configuration files - (local.conf and bblayers.conf) - are configured appropriately. - The entire process for building an image is overviewed in the - "Building an Image" - section of the Yocto Project Quick Start. - You might want to reference this information. - You can find more information on BitBake in the user manual, which is found in the - bitbake/doc/manual directory of the - Source Directory. - The build process supports several types of images to satisfy different needs. - See the "Images" chapter in - the Yocto Project Reference Manual for information on supported images. - - Make changes to the kernel source code if - applicable: Modifying the kernel does not always mean directly - changing source files. - However, if you have to do this, you make the changes to the files in the - Build directory. - Make kernel configuration changes - if applicable: - If your situation calls for changing the kernel's configuration, you can - use the yocto-kernel script or menuconfig - to enable and disable kernel configurations. - Using the script lets you interactively set up kernel configurations. - Using menuconfig allows you to interactively develop and test the - configuration changes you are making to the kernel. - When saved, changes using menuconfig update the kernel's - .config. - Try to resist the temptation of directly editing the .config - file found in the - Build Directory at - tmp/sysroots/<machine-name>/kernel. - Doing so, can produce unexpected results when the OpenEmbedded build system - regenerates the configuration file. - Once you are satisfied with the configuration changes made using - menuconfig, you can directly examine the - .config file against a saved original and gather those - changes into a config fragment to be referenced from within the kernel's - .bbappend file. - Rebuild the kernel image with your changes: - Rebuilding the kernel image applies your changes. - - -
-
-
- -
- Application Development Workflow - - Application development involves creating an application that you want - to run on your target hardware, which is running a kernel image created using the - OpenEmbedded build system. - The Yocto Project provides an Application Development Toolkit (ADT) and - stand-alone cross-development toolchains that - facilitate quick development and integration of your application into its run-time environment. - Using the ADT and toolchains, you can compile and link your application. - You can then deploy your application to the actual hardware or to the QEMU emulator for testing. - 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. + See all the unvarnished details of how this bug was diagnosed and + solved here: Yocto Bug #3049 - - - While we strongly suggest using the ADT to develop your application, this option might not - be best for you. - If this is the case, you can still use pieces of the Yocto Project for your development process. - However, because the process can vary greatly, this manual does not provide detail on the process. - - -
- Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark> - - - To help you understand how application development works using the ADT, this section - provides an overview of the general development process and a detailed example of the process - as it is used from within the Eclipse IDE. - - - - The following illustration and list summarize the application development general workflow. - - - - - - - - - Prepare the Host System for the Yocto Project: - See - "The Linux Distributions" and - "The Packages" sections both - in the Yocto Project Quick Start for requirements. - Secure the Yocto Project Kernel Target Image: - You must have a target kernel image that has been built using the OpenEmbeded - 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 the - - 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 for an example. - - For information on pre-built kernel image naming schemes for images - that can run on the QEMU emulator, see the - "Downloading the Pre-Built Linux Kernel" - section in the Yocto Project Quick Start. - Install the ADT: - The ADT provides a target-specific cross-development toolchain, the root filesystem, - the QEMU emulator, and other tools that can help you develop your application. - While it is possible to get these pieces separately, the ADT Installer provides an - easy method. - You can get these pieces by running an ADT installer script, which is configurable. - For information on how to install the ADT, see the - "Using the ADT Installer" - section - in the Yocto Project Application Developer's Guide. - If Applicable, Secure the Target Root Filesystem - and the Cross-development Toolchain: - If you choose not to install the ADT using the ADT Installer, - 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 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 "Using a Cross-Toolchain Tarball" - section in the Yocto Project Application Developer's Guide for information - and the - "Installing the Toolchain" - in the Yocto Project Quick Start for information on finding and installing - the correct toolchain based on your host development system and your target - architecture. - - 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. - - 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 user-space tools installed along with the ADT to debug your application. - Of course, the same user-space tools are available separately if you choose - not to use the Eclipse IDE. - - -
- -
- Working Within Eclipse - - - 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 Juno and Indigo 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. - 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. - - -
- Setting Up the Eclipse IDE - - - 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. - - - -
- Installing the Eclipse IDE - - - It is recommended that you have the Juno 4.2 version of the - Eclipse IDE installed on your development system. - However, if you currently have the Indigo 3.7.2 version installed and you do - not want to upgrade the IDE, you can configure Indigo to work with the - Yocto Project. - See the - "Configuring the Eclipse IDE (Indigo)" - section. - - - - If you don’t have the Juno 4.2 Eclipse IDE installed, you can find the tarball at - . - From that site, choose the Eclipse Classic version particular to your development - host. - 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-SDK-4.2-linux-gtk-x86_64.tar.gz - - - - - If you have the Indigo 3.7.2 Eclipse IDE already installed and you want to use that - version, one issue exists that you need to be aware of regarding the Java - Virtual machine’s garbage collection (GC) process. - The GC process does not clean up the permanent generation - space (PermGen). - This space stores metadata descriptions of classes. - The default value is set too small and it could trigger an - out-of-memory error such as the following: - - Java.lang.OutOfMemoryError: PermGen space - - - - - This error causes the application to hang. - - - - To fix this issue, you can use the --vmargs - option when you start the Indigo 3.7.2 Eclipse IDE - to increase the size of the permanent generation space: - - eclipse --vmargs --XX:PermSize=256M - - -
- -
- Configuring the Eclipse IDE (Juno) - - - This section presents the steps needed to configure the Juno 4.2 Eclipse IDE. - If you are using Indigo 3.7.2, see the - "Configuring the Eclipse IDE (Indigo)". - - - - Before installing and configuring the Eclipse Yocto Plug-in, you need to configure - the Juno 4.2 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 Juno - &ECLIPSE_JUNO_URL; - from the "Work with:" pull-down menu. - Expand the box next to "Linux Tools" and select the - "LTTng - Linux Tracing Toolkit" boxes. - Expand the box next to "Mobile and Device Development" and select the - following boxes: - - C/C++ Remote Launch - Remote System Explorer End-user Runtime - Remote System Explorer User Actions - Target Management Terminal - TCF Remote System Explorer add-in - TCF Target Explorer - - Expand the box next to Programming Languages - and select the Autotools Support for CDT - and C/C++ Development Tools boxes. - Complete the installation and restart the Eclipse IDE. - - -
- -
- Configuring the Eclipse IDE (Indigo) - - - This section presents the steps needed to configure the Indigo 3.7.2 Eclipse IDE. - If you are using Juno 4.2, see the - "Configuring the Eclipse IDE (Juno)". - - - - Before installing and configuring the Eclipse Yocto Plug-in, you need to configure - the Indigo 3.7.2 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 indigo - &ECLIPSE_INDIGO_URL; - from the "Work with:" pull-down menu. - Expand the box next to Programming Languages - and select the Autotools Support for CDT (incubation) - and C/C++ Development Tools boxes. - Expand the box next to "Linux Tools" and select the - "LTTng - Linux Tracing Toolkit(incubation)" boxes. - Complete the installation and restart the Eclipse IDE. - After the Eclipse IDE restarts and from the Workbench, select - "Install New Software" from the "Help" pull-down menu. - Click the - "Available Software Sites" link. - Check the box next to - &ECLIPSE_UPDATES_URL; - and click "OK". - Select &ECLIPSE_UPDATES_URL; - from the "Work with:" pull-down menu. - Check the box next to TM and RSE Main Features. - - Expand the box next to TM and RSE Optional Add-ons - and select every item except RSE Unit Tests and - RSE WinCE Services (incubation). - Complete the installation and restart the Eclipse IDE. - If necessary, select - "Install New Software" from the "Help" pull-down menu so you can click the - "Available Software Sites" link again. - After clicking "Available Software Sites", check the box next to - http://download.eclipse.org/tools/cdt/releases/indigo - and click "OK". - Select &ECLIPSE_INDIGO_CDT_URL; - from the "Work with:" pull-down menu. - Check the box next to CDT Main Features. - - Expand the box next to CDT Optional Features - and select C/C++ Remote Launch and - Target Communication Framework (incubation). - Complete the installation and restart the Eclipse IDE. - - -
- -
- Installing or Accessing the Eclipse Yocto Plug-in - - - 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. - If you don't want to permanently install the plug-in but just want to try it out - within the Eclipse environment, you can import the plug-in project from the - Yocto Project's Source Repositories. - - -
- Installing the Pre-built Plug-in from the Yocto Project Eclipse Update Site - - - 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; - in the URL field and provide a meaningful name in the "Name" 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 box next to Development tools and SDKs for Yocto Linux. - - Complete the remaining software installation steps and - then restart the Eclipse IDE to finish the installation of the plug-in. - - - -
- -
- Installing the Plug-in Using the Latest Source Code - - - To install the Eclipse Yocto Plug-in from the latest source code, follow these steps: - - Open a shell and create a Git repository with: - - $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse - - For this example, the repository is named - ~/yocto-eclipse. - Change to the directory where you set up - the Git repository: - - $ cd ~/yocto-eclipse - - Be sure you are in the right branch for your Git repository. - For this release set the branch to &DISTRO_NAME;: - - $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME; - - 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 of the - Git repository created earlier. - - Run the build.sh script - as directed. - Be sure to provide the name of the Git branch along with the - Yocto Project release you are using. - Here is an example that uses the &DISTRO_NAME; branches: - - $ ECLIPSE_HOME=/home/scottrif/yocto-eclipse/scripts/eclipse ./build.sh &DISTRO_NAME; &DISTRO_NAME; - - 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 seven. - This ZIP file should not be "unzipped", and must be the - *archive.zip file created by running the - build.sh script. - Click through the "Okay" buttons. - Check the box next to the new entry in the installation window and complete - the installation. - 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. -
- -
- Importing the Plug-in Project into the Eclipse Environment - - - Importing the Eclipse Yocto Plug-in project from the Yocto Project source repositories - is useful when you want to try out the latest plug-in from the tip of plug-in's - development tree. - It is important to understand when you import the plug-in you are not installing - it into the Eclipse application. - Rather, you are importing the project and just using it. - To import the plug-in project, follow these steps: - - Open a shell and create a Git repository with: - - $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse - - For this example, the repository is named - ~/yocto-eclipse. - In Eclipse, select "Import" from the "File" menu. - Expand the "General" box and select "existing projects into workspace" - and then click "Next". - Select the root directory and browse to - ~/yocto-eclipse/plugins. - Three plug-ins exist: "org.yocto.bc.ui", "org.yocto.sdk.ide", and - "org.yocto.sdk.remotetools". - Select and import all of them. - - - - - The left navigation pane in the Eclipse application shows the default projects. - Right-click on one of these projects and run it as an Eclipse application. - This brings up a second instance of Eclipse IDE that has the Yocto Plug-in. - -
-
- -
- Configuring the Eclipse Yocto Plug-in - - - 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 Windows -> Preferences to display - the Preferences Dialog - Click Yocto Project ADT - - - -
- Configuring the Cross-Compiler Options - - - 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 the - &YOCTO_ADTPATH_DIR; directory. - This is the location for toolchains installed by the ADT Installer or by hand. - Sections "Configuring - and Running the ADT Installer Script" and - "Using a Cross-Toolchain Tarball" - in the Yocto Project Application Developer's Guide - describe two ways to install a stand-alone cross-toolchain in the - /opt/poky directory. - It is possible to install a stand-alone cross-toolchain in a directory - other than /opt/poky. - However, doing so is discouraged. - If you are using a system-derived toolchain, the path you provide - for the Toolchain Root Location - field is the Build Directory. - See the "Using - BitBake and the Build Directory" section in the Yocto Project Application - Developer's Guide for information on how to install the toolchain into the build -directory. - Specify the Sysroot Location: - This location is where the root filesystem for the target hardware resides. - If you used the ADT Installer, then the location is - /opt/poky/<release>. - Additionally, when you use the ADT Installer, the same location is used for - the QEMU user-space tools and the NFS boot process. - If you used either of the other two methods to install the toolchain, then the - location of the sysroot filesystem depends on where you separately - extracted and intalled the filesystem. - For information on how to install the toolchain and on how to extract - and install the sysroot filesystem, see the - "Installing the ADT and Toolchains" 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 an Image" section - of the Yocto Project Quick Start for more information. - - -
- -
- Configuring the Target Options - - - 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 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 button to save your plug-in configurations. - -
-
-
- -
- Creating the Project - - - 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 section - "Using the Command Line" - in the Yocto Project Application Developer's Guide. - - - - To create a project based on a Yocto template and then display the source code, - follow these steps: - - Select File -> New -> Project. - Double click CC++. - Double click C Project to create the project. - Expand Yocto Project ADT 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. - - - -
- -
- Configuring the Cross-Toolchains - - - 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 Project -> Change Yocto Project Settings: - This selection brings up the Yocot 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 provide 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". - If you are running the Juno version of Eclipse, you can skip down to the next - section where you build the project. - If you are not working with Juno, you need to reconfigure the project as - described in the next step. - Select Project -> Reconfigure Project: - 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. - - -
- -
- Building the Project - - - To build the project in Juno, right click on the project in the navigator pane and select - Build Project. - If you are not running Juno, select Project -> Build Project. - The console should update and you can note the cross-compiler you are using. - -
- -
- Starting QEMU in User Space NFS Mode - - - To start the QEMU emulator from within Eclipse, follow these steps: - - Expose the Run -> External Tools 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. - For example, you could determine the IP Address - for the user-space NFS by using the ifconfig command. - - - -
- -
- Deploying and Debugging the Application - - - Once the QEMU emulator is running the image, using the Eclipse IDE - you can deploy your application and use the emulator to perform debugging. - Follow these steps to deploy the application. - - Select Run -> Debug Configurations... - 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 Run to bring up a login screen - and login. - Accept the debug perspective. - - -
- -
- Running User-Space Tools - - - 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 - YoctoTools 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 - . - The oprofile-server is installed by default on - the core-image-sato-sdk image. - Lttng2.0 ust 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 . - Do not use Lttng-user space (legacy) tool. - This tool no longer has any upstream support. - - Before you use the Lttng2.0 ust trace import tool, - you need to setup the Lttng Eclipse plug-in and create a - Tracing project. - Do the following: - - Select Window -> Open Perspective -> Other - and then select Tracing. - Click OK to change the Eclipse perspective - into the Tracing perspective. - Create a new Tracing project by selecting - File -> New -> Project. - Choose Tracing -> Tracing Project. - - Generate your tracing data on the remote target. - - Click - Yocto Project Tools -> Lttng2.0 ust trace import - 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 Trace Type... -> Common Trace Format -> Generic CTF Trace - 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. - Time to gather data(sec): is the time passed in seconds before data - is gathered from the remote target for analysis. - show pids in wakeups list: 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. - - -
- -
- Customizing an Image Using a BitBake Commander Project and Hob - - - Within Eclipse, you can create a Yocto BitBake Commander project, - edit the metadata, and then use the - Hob to build a customized - image all within one IDE. - - -
- Creating the Yocto BitBake Commander Project - - - To create a Yocto BitBake Commander project, follow these steps: - - Select Window -> Open Perspective -> Other - and then choose Bitbake Commander. - Click OK to change the Eclipse perspective into the - Bitbake Commander perspective. - Select File -> New -> Project to create a new Yocto - Bitbake Commander project. - Choose Yocto Project Bitbake Commander -> New Yocto Project - and click Next. - Enter the Project Name and choose the Project Location. - The Yocto project's metadata files will be put under the directory - <project_location>/<project_name>. - If that directory does not exist, you need to check - the "Clone from Yocto Git Repository" box, which would execute a - git clone command to get the project's metadata files. - - Select Finish to create the project. - - -
- -
- Editing the Metadata Files - - - After you create the Yocto Bitbake Commander project, you can modify the metadata files - by opening them in the project. - When editing recipe files (.bb files), you can view BitBake - variable values and information by hovering the mouse pointer over the variable name and - waiting a few seconds. - - - - To edit the metadata, follow these steps: - - Select your Yocto Bitbake Commander project. - Select File -> New -> Yocto BitBake Commander -> BitBake Recipe - to open a new recipe wizard. - Point to your source by filling in the "SRC_URL" field. - For example, you can add a recipe to your - Source Directory - by defining "SRC_URL" as follows: - - ftp://ftp.gnu.org/gnu/m4/m4-1.4.9.tar.gz - - Click "Populate" to calculate the archive md5, sha256, - license checksum values and to auto-generate the recipe filename. - Fill in the "Description" field. - Be sure values for all required fields exist. - Click Finish. - - -
- -
- Building and Customizing the Image - - - To build and customize the image in Eclipse, follow these steps: - - Select your Yocto Bitbake Commander project. - Select Project -> Launch HOB. - Enter the Build Directory where you want to put your final images. - Click OK to launch Hob. - Use Hob to customize and build your own images. - For information on Hob, see the - Hob Project Page on the - Yocto Project website. - - -
-
-
- -
- Workflow Using Stand-alone Cross-development Toolchains - - - If you want to develop an application without prior installation of the ADT, you - still can employ the cross-development toolchain, the QEMU emulator, and a number of supported - target image files. - You just need to follow these general steps: - - Install the cross-development toolchain for your target hardware: - For information on how to install the toolchain, see the - "Using a Cross-Toolchain Tarball" - section - in the Yocto Project Application Developer's Guide. - Download the Target Image: The Yocto Project supports - several target architectures and has many pre-built kernel images and root filesystem - images. - If you are going to develop your application on hardware, go to the - machines - download area and choose a target machine area - from which to download the kernel image and root filesystem. - This download area could have several files in it that support development using - actual hardware. - For example, the area might contain .hddimg files that combine the - kernel image with the filesystem, boot loaders, etc. - Be sure to get the files you need for your particular development process. - If you are going to develop your application and then run and test it using the QEMU - emulator, go to the - machines/qemu - download area. - From this area, go down into the directory for your target architecture - (e.g. qemux86_64 for an - Intel-based 64-bit architecture). - Download kernel, root filesystem, and any other files you need for your process. - In order to use the root filesystem in QEMU, you need to extract it. - See the - "Extracting the Root Filesystem" - section for information on how to extract the root filesystem. - Develop and Test your Application: At this point, - you have the tools to develop your application. - If you need to separately install and use the QEMU emulator, you can go to - QEMU Home Page to download and learn about the - emulator. - - -
-
- -
- Modifying Temporary Source Code - - - You might - find it helpful during development to modify the temporary source code used by recipes - to build packages. - For example, suppose you are developing a patch and you need to experiment a bit - to figure out your solution. - After you have initially built the package, you can iteratively tweak the - source code, which is located in the - Build Directory, and then - you can force a re-compile and quickly test your altered code. - Once you settle on a solution, you can then preserve your changes in the form of - patches. - You can accomplish these steps all within either a - Quilt or - Git workflow. - - -
- Finding the Temporary Source Code - - - During a build, the unpacked temporary source code used by recipes - to build packages is available in the Build Directory as - defined by the - S variable. - Below is the default value for the S variable as defined in the - meta/conf/bitbake.conf configuration file in the - Source Directory: - - S = ${WORKDIR}/${BP} - - You should be aware that many recipes override the S variable. - For example, recipes that fetch their source from Git usually set - S to ${WORKDIR}/git. - - The - BP - represents the base recipe name, which consists of the name and version: - - BP = ${BPN}-${PV} - - - - - - The path to the work directory for the recipe - (WORKDIR) depends - on the recipe name and the architecture of the target device. - For example, here is the work directory for recipes and resulting packages that are - not device-dependent: - - ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR} - - Let's look at an example without variables. - Assuming a top-level Source Directory - named poky - and a default Build Directory of poky/build, - the following is the work directory for the acl recipe that - creates the acl package: - - ~/poky/build/tmp/work/i586-poky-linux/acl-2.2.51-r3 - - - - - If your resulting package is dependent on the target device, - the work directory varies slightly: - - ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR} - - Again, assuming top-level Source Directory named poky - and a default Build Directory of poky/build, the - following are the work and temporary source directories, respectively, - for the acl package that is being - built for a MIPS-based device: - - ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2 - ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2/acl-2.2.51 - - - - - To better understand how the OpenEmbedded build system resolves directories during the - build process, see the glossary entries for the - WORKDIR, - TMPDIR, - TOPDIR, - PACKAGE_ARCH, - TARGET_OS, - PN, - PV, - and - PR - variables in the Yocto Project Reference Manual. - - - - Now that you know where to locate the directory that has the temporary source code, - you can use a Quilt or Git workflow to make your edits, test the changes, - and preserve the changes in the form of patches. - -
- -
- Using a Quilt Workflow - - - Quilt - is a powerful tool that allows you to capture source code changes without having - a clean source tree. - This section outlines the typical workflow you can use to modify temporary source code, - test changes, and then preserve the changes in the form of a patch all using Quilt. - - - - Follow these general steps: - - Find the Source Code: - The temporary source code used by the OpenEmbedded build system is kept in the - Build Directory. - See the - "Finding the Temporary Source Code" - section to learn how to locate the directory that has the temporary source code for a - particular package. - Change Your Working Directory: - You need to be in the directory that has the temporary source code. - That directory is defined by the - S - variable. - Create a New Patch: - Before modifying source code, you need to create a new patch. - To create a new patch file, use quilt new as below: - - $ quilt new my_changes.patch - - Notify Quilt and Add Files: - After creating the patch, you need to notify Quilt about the files - you plan to edit. - You notify Quilt by adding the files to the patch you just created: - - $ quilt add file1.c file2.c file3.c - - - Edit the Files: - Make your changes in the temporary source code to the files you added - to the patch. - Test Your Changes: - Once you have modified the source code, the easiest way to test your changes - is by calling the compile task as shown in the following example: - - $ bitbake -c compile -f <name_of_package> - - The -f or --force - option forces re-execution of the specified task. - If you find problems with your code, you can just keep editing and - re-testing iteratively until things work as expected. - All the modifications you make to the temporary source code - disappear once you -c clean or - -c cleanall with BitBake for the package. - Modifications will also disappear if you use the rm_work - feature as described in the - "Building an Image" - section of the Yocto Project Quick Start. - - Generate the Patch: - Once your changes work as expected, you need to use Quilt to generate the final patch that - contains all your modifications. - - $ quilt refresh - - At this point the my_changes.patch file has all your edits made - to the file1.c, file2.c, and - file3.c files. - You can find the resulting patch file in the patches/ - subdirectory of the source (S) directory. - Copy the Patch File: - For simplicity, copy the patch file into a directory named files, - which you can create in the same directory that holds the recipe - (.bb) file or the - append (.bbappend) file. - Placing the patch here guarantees that the OpenEmbedded build system will find - the patch. - Next, add the patch into the - SRC_URI - of the recipe. - Here is an example: - - SRC_URI += "file://my_changes.patch" - - Increment the Recipe Revision Number: - Finally, don't forget to 'bump' the - PR - value in the recipe since the resulting packages have changed. - -
- -
- Using a Git Workflow - - Git is an even more powerful tool that allows you to capture source code changes without having - a clean source tree. - This section outlines the typical workflow you can use to modify temporary source code, - test changes, and then preserve the changes in the form of a patch all using Git. - For general information on Git as it is used in the Yocto Project, see the - "Git" section. - - - - This workflow uses Git only for its ability to manage local changes to the source code - and produce patches independent of any version control system used with the Yocto Project. - - - - Follow these general steps: - - Find the Source Code: - The temporary source code used by the OpenEmbedded build system is kept in the - Build Directory. - See the - "Finding the Temporary Source Code" - section to learn how to locate the directory that has the temporary source code for a - particular package. - Change Your Working Directory: - You need to be in the directory that has the temporary source code. - That directory is defined by the - S - variable. - If needed, initialize a Git Repository: - If the recipe you are working with does not use a Git fetcher, - you need to set up a Git repository as follows: - - $ git init - $ git add * - $ git commit -m "initial revision" - - The above Git commands initialize a Git repository that is based on the - files in your current working directory, stage all the files, and commit - the files. - At this point, your Git repository is aware of all the source code files. - Any edits you now make to files can be committed later and will be tracked by - Git. - Edit the Files: - Make your changes to the temporary source code. - Test Your Changes: - Once you have modified the source code, the easiest way to test your changes - is by calling the compile task as shown in the following example: - - $ bitbake -c compile -f <name_of_package> - - The -f or --force - option forces re-execution of the specified task. - If you find problems with your code, you can just keep editing and - re-testing iteratively until things work as expected. - All the modifications you make to the temporary source code - disappear once you -c clean, -c cleansstate, - or -c cleanall with BitBake for the package. - Modifications will also disappear if you use the rm_work - feature as described in the - "Building an Image" - section of the Yocto Project Quick Start. - - See the List of Files You Changed: - Use the git status command to see what files you have actually edited. - The ability to have Git track the files you have changed is an advantage that this - workflow has over the Quilt workflow. - Here is the Git command to list your changed files: - - $ git status - - Stage the Modified Files: - Use the git add command to stage the changed files so they - can be committed as follows: - - $ git add file1.c file2.c file3.c - - Commit the Staged Files and View Your Changes: - Use the git commit command to commit the changes to the - local repository. - Once you have committed the files, you can use the git log - command to see your changes: - - $ git commit -m "<commit-summary-message>" - $ git log - - The name of the patch file created in the next step is based on your - commit-summary-message. - Generate the Patch: - Once the changes are committed, use the git format-patch - command to generate a patch file: - - $ git format-patch -1 - - Specifying "-1" causes Git to generate the - patch file for the most recent commit. - At this point, the patch file has all your edits made - to the file1.c, file2.c, and - file3.c files. - You can find the resulting patch file in the current directory and it - is named according to the git commit summary line. - The patch file ends with .patch. - Copy the Patch File: - For simplicity, copy the patch file into a directory named files, - which you can create in the same directory that holds the recipe - (.bb) file or the - append (.bbappend) file. - Placing the patch here guarantees that the OpenEmbedded build system will find - the patch. - Next, add the patch into the - SRC_URI - of the recipe. - Here is an example: - - SRC_URI += "file://0001-<commit-summary-message>.patch" - - Increment the Recipe Revision Number: - Finally, don't forget to 'bump' the - PR - value in the recipe since the resulting packages have changed. - - -
-
- -
- Image Development Using Hob - - - The Hob is a graphical user interface for the - OpenEmbedded build system, which is based on BitBake. - You can use the Hob to build custom operating system images within the Yocto Project build environment. - Hob simply provides a friendly interface over the build system used during system development. - In other words, building images with the Hob lets you take care of common build tasks more easily. - - - - For a better understanding of Hob, see the project page at - on the Yocto Project website. - The page has a short introductory training video on Hob. - The following lists some features of Hob: - - You can setup and run Hob using these commands: - - $ source oe-init-build-env - $ hob - - You can set the - MACHINE - for which you are building the image. - You can modify various policy settings such as the package format used to build with, - the parrallelism BitBake uses, whether or not to build an external toolchain, and which host - to build against. - You can manage - layers. - You can select a base image and then add extra packages for your custom build. - - You can launch and monitor the build from within Hob. - - -
- -
- Using a Development Shell - - - When debugging certain commands or even when just editing packages, - devshell can be a useful tool. - When you invoke devshell, source files are - extracted into your working directory and patches are applied. - Then, a new terminal is opened and you are placed in the working directory. - In the new terminal, all the OpenEmbedded build-related environment variables are - still defined so you can use commands such as configure and - make. - The commands execute just as if the OpenEmbedded build system were executing them. - Consequently, working this way can be helpful when debugging a build or preparing - software to be used with the OpenEmbedded build system. - - - - Following is an example that uses devshell on a target named - matchbox-desktop: - - $ bitbake matchbox-desktop -c devshell - - - - - This command spawns a terminal with a shell prompt within the OpenEmbedded build environment. - The OE_TERMINAL - controls what type of shell is opened. - - - - For spawned terminals, the following occurs: - - The PATH variable includes the - cross-toolchain. - The pkgconfig variables find the correct - .pc files. - The configure command finds the - Yocto Project site files as well as any other necessary files. - - - - - Within this environment, you can run configure or compile - commands as if they were being run by - the OpenEmbedded build system itself. - As noted earlier, the working directory also automatically changes to the - Source Directory (S). - - - - When you are finished, you just exit the shell or close the terminal window. - - - - - It is worth remembering that when using devshell - you need to use the full compiler name such as arm-poky-linux-gnueabi-gcc - instead of just using gcc. - The same applies to other applications such as binutils, - libtool and so forth. - BitBake sets up environment variables such as CC - to assist applications, such as make to find the correct tools. - - - - It is also worth noting that devshell still works over - X11 forwarding and similar situations - -
-- cgit v1.2.3-54-g00ecf