From c527fd1f14c27855a37f2e8ac5346ce8d940ced2 Mon Sep 17 00:00:00 2001 From: Tudor Florea Date: Thu, 16 Oct 2014 03:05:19 +0200 Subject: initial commit for Enea Linux 4.0-140929 Migrated from the internal git server on the daisy-enea-point-release branch Signed-off-by: Tudor Florea --- documentation/dev-manual/dev-manual-model.xml | 2069 +++++++++++++++++++++++++ 1 file changed, 2069 insertions(+) create mode 100644 documentation/dev-manual/dev-manual-model.xml (limited to 'documentation/dev-manual/dev-manual-model.xml') diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml new file mode 100644 index 0000000000..4fd4c4e1e3 --- /dev/null +++ b/documentation/dev-manual/dev-manual-model.xml @@ -0,0 +1,2069 @@ + %poky; ] > + + + +Common Development Models + + + 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. + For more complete information on how to work with the kernel, see the + Yocto Project Linux Kernel + Development Manual. + + User Application Development: + User Application Development covers development of applications that you intend + to run on 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 you implement the solution, 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. + + + +
+ System Development Workflow + + + 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. + + + + 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. + + +
+ 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. + Although not required for BSP creation, the + meta-intel repository, which contains + many BSPs supported by the Yocto Project, is part of the example. + + + + 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 Distribution" + 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 Set Up" section. + Establish the meta-intel + repository on your system: Having local copies + of these supported BSP layers on your system gives you + access to layers you might be able to build on or modify + to create your BSP. + For information on how to get these files, see the + "Getting Set Up" 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 and configurations 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. + Five BSPs exist that are part of the + Yocto Project release: genericx86, genericx86-64, + beaglebone, + mpc8315e, and edgerouter. + The recipes and configurations for these five BSPs are located and dispersed + within the Source Directory. + On the other hand, BSP layers for Crown Bay, + Crystal Forest, Emenlow, Fish River Island 2, Haswell, + Jasper Forest, NUC DC3217IYE, + Romley, 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 + "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 do not 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 + (i.e. oe-init-build-env or + oe-init-build-env-memres) + 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 + BitBake User Manual. + + 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. + After going to the page, just search for "Embedded". + You can also find supplemental information in the + + Yocto Project Board Support Package (BSP) Developer's Guide. + Finally, there is a 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. + 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. + For more information on the kernel and on modifying the kernel, see the + Yocto Project Linux Kernel Development Manual. + + +
+ 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-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-3.8 - The + stable Yocto Project kernel to use with the Yocto Project Release 1.4. This kernel + is based on the Linux 3.8 released kernel. + linux-yocto-3.10 - The + stable Yocto Project kernel to use with the Yocto Project Release 1.5. This kernel + is based on the Linux 3.10 released kernel. + linux-yocto-3.14 - The + stable Yocto Project kernel to use with the Yocto Project Release 1.6. This kernel + is based on the Linux 3.14 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.4 + kernel. + Thus, everything further to the right in the structure is based on the + linux-yocto-3.4 kernel. + Branch points to right in the figure represent where the + linux-yocto-3.4 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 + 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 access + temporary kernel source files that were extracted and used + during a build. + We will just talk about working with the temporary source code. + For more information on how to get kernel source code onto your + host system, see the + "Yocto Project Kernel" + bulleted item earlier in the manual. + + + + 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 additional information on the Yocto Project kernel's + architecture and its branching strategy, see the + Yocto Project Linux Kernel Development 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 Distribution" 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 in which you are + interested, 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 an environment setup script + (i.e. oe-init-build-env or + oe-init-build-env-memres). + 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 + BitBake User Manual. + + 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 file. + 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 compare 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 runtime 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. + + + + 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 + "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 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, inclusive 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 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 "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 Kepler + and Juno 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. + + +
+ 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 Kepler 4.3.2 version of + the Eclipse IDE installed on your development system. + However, if you currently have the Juno 4.2 version + installed and you do not want to upgrade the IDE, you can + configure Juno to work with the Yocto Project. + + + + If you do not have the Kepler 4.3.2 Eclipse IDE installed, + you can find the tarball at + . + From that site, choose the Eclipse Standard 4.3.2 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-standard-kepler-SR2-linux-gtk-x86_64.tar.gz + + +
+ +
+ Configuring the Eclipse IDE + + + 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 + Kepler - &ECLIPSE_KEPLER_URL; + from the "Work with:" pull-down menu. + + For Juno, select + Juno - &ECLIPSE_JUNO_URL; + + + 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 (Requires RSE Remote System Explorer) + 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 + C/C++ Autotools Support + and C/C++ Development Tools + boxes. + 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. + + +
+ 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;/kepler + in the URL field and provide a meaningful name + in the "Name" field. + + If you are using Juno, use + &ECLIPSE_DL_PLUGIN_URL;/juno + 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. + + + +
+ +
+ Installing the Plug-in Using the Latest Source Code + + + 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 appropriate 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 as follows: + + export PATH=~/jdk1.7.0_40/bin:$PATH + + + In the same shell, create a Git + repository with: + + $ cd ~ + $ git clone git://git.yoctoproject.org/eclipse-poky-kepler + + + If you are using Juno, the repository is + located at + git://git.yoctoproject.org/eclipse-poky-juno. + + For this example, the repository is named + ~/eclipse-poky-kepler. + + Change to the directory where you + set up the Git repository: + + $ cd ~/eclipse-poky-kepler + + Be sure you are in the right branch + for your Git repository. + For this release set the branch to + &DISTRO_NAME;: + + $ git checkout &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 + directory 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; branch: + + $ ECLIPSE_HOME=/home/scottrif/eclipse-poky-kepler/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 eight. + 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 boxes + 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. +
+
+ +
+ 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 "Preferences" from the + "Windows" menu 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 where it is + installed. + If you used the ADT Installer script and + accepted the default installation directory, the + toolchain will be installed in the + &YOCTO_ADTPATH_DIR; + directory. + Sections "Configuring and Running the ADT Installer Script" + and + "Using a Cross-Toolchain Tarball" + in the Yocto Project Application Developer's + Guide describe how to install a stand-alone + cross-toolchain. + 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 script and + accepted the default installation directory, + then the location is + /opt/poky/&DISTRO;. + Additionally, when you use the ADT Installer + script, 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 or did not + accept the ADT Installer script's default + installation directory, then 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 + "Installing the ADT and Toolchains" + section in the Yocto Project Application + Developer's Guide. + + 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/<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. + +
+
+
+ +
+ 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. + + 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 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 "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". + 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 "Reconfigure Project" from the + "Project" 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. + + + +
+ +
+ 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 "Build Project" from the + "Project" menu. + 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 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. + 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, 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 "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 + . + 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 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 + 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 ust 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 "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. + + Generate your tracing data on the + remote target. + Select "Lttng2.0 ust 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. + + + +
+ +
+ Customizing an Image Using a BitBake Commander Project and Hob + + + Within the Eclipse IDE, you can create a Yocto BitBake Commander + project, edit the Metadata, and + then use + 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 "Other" from the + "Window -> Open Perspective" menu + and then choose "Bitbake Commander". + + Click "OK" to change the perspective to + Bitbake Commander. + Select "Project" from the "File -> New" + menu to create a new Yocto + Bitbake Commander project. + Choose "New Yocto Project" from the + "Yocto Project Bitbake Commander" menu 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. + + Do not specify your BitBake Commander project + location as your Eclipse workspace. + Doing so causes an error indicating that the + current project overlaps the location of + another project. + This error occurs even if no such project exits. + + Select Finish to + create the project. + + +
+ +
+ Editing the Metadata + + + 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 "BitBake Recipe" from the + "File -> New -> Yocto BitBake Commander" menu + 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 Using Hob + + + To build and customize the image using Hob from within the + Eclipse IDE, follow these steps: + + Select your Yocto Bitbake Commander + project. + Select "Launch Hob" from the "Project" + menu. + 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, and + so forth. + 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) + is defined as follows: + + ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} + + The actual directory depends on several things: + + TMPDIR: + The top-level build output directory + MULTIMACH_TARGET_SYS: + The target system identifier + PN: + The recipe name + EXTENDPE: + The epoch - (if + PE + is not specified, which is usually the case for most + recipes, then EXTENDPE is blank) + PV: + The recipe version + PR: + The recipe revision + + + + + As an example, assume a Source Directory top-level folder + name poky, a default Build Directory at + poky/build, and a + qemux86-poky-linux machine target + system. + Furthermore, suppose your recipe is named + foo_1.3.0-r0.bb. + In this case, the work directory the build system uses to + build the package would be as follows: + + poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0 + + + + + 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 the specified task to execute. + 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 the specified task to execute. + 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 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. + If you follow the "Documentation" link from the Hob page, you will + find 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 with which to build, + the parallelism 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 + variable 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