Linux：Embedded Development
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

Chapter 7. ADT Eclipse Plug-ins

In this chapter, you will be presented with a new perspective of the available tool in the Yocto Project. This chapter marks the beginning of the introduction to various tools available in the Yocto Project ecosystem, tools that are very useful and different from the Poky reference system. In this chapter, a short presentation to the Application Development Environment (ADE) is presented with emphasis on the Eclipse project and the Yocto Project's added plug-ins. A number of the plug-ins are shown along with their configurations and use cases.

A broader view of the Application Development Toolkit (ADT) will also be shown to you. This project's main objective is to offer a software stack that is able to develop, compile, run, debug, and profile software applications. It tries to do this without requiring extra learning from the developer's point of view. Its learning curve is very low, taking into consideration the fact that Eclipse is one of the most used Integrated Development Environment (IDEs), and over time, it has become very user-friendly, stable, and dependable. The ADT user experience is very similar to the one that any Eclipse or non-Eclipse user has when they use an Eclipse IDE. The available plug-ins try to make this experience as similar as possible so that development is similar to any Eclipse IDE. The only difference is between configuration steps, and this defines the difference between one Eclipse IDE version and another.

The ADT offers the possibility of using a standalone cross-compiler, debugging tool profilers, emulators, and even development board interaction in a platform-independent manner. Although interaction with hardware is the best option for an embedded developer, in most cases, the real hardware is missing due to various reasons. For these scenarios, it is possible to use a QEMU emulator to simulate the necessary hardware.

The Application Development Toolkit

ADT is one of the components of the Yocto Project and provides a cross-development platform, which is perfect for user-specific application development. For the development process to take place in an orderly manner, some components are required:

  • Eclipse IDE Yocto plug-ins
  • QEMU emulator for specific hardware simulations
  • Cross-toolchain alongside its specific sysroot, which are both architecture-specific and are generated using the metadata and the build system made available by the Yocto Project
  • Userspace tools to enhance a developer's experience with the application development process

The Eclipse plug-ins are available when offering full support to the Yocto Project with the Eclipse IDE and maximizing the Yocto experience. The end result is an environment that is customized for the Yocto developer's needs, with a cross-toolchain, deployment on a real hardware, or QEMU emulation features, and also a number of tools that are available for collecting data, tracing, profiling, and performance reviews.

The QEMU emulator is used to simulate various hardware. It can be obtained with these methods:

  • Using the ADT installer script, which offers the possibility of installing it
  • Cloning a Poky repository and sourcing the environment, access is granted to a QEMU environment
  • Downloading a Yocto release and sourcing the environment offers for the same result
  • Installing a cross-toolchain and sourcing the environment to make the QEMU environment available

The toolchain contains a cross-debugger, cross-compiler, and cross-linker, which are very well used in the process of application development. The toolchain also comes with a matching sysroot for the target device because it needs access to various headers and libraries necessary to run on the target architecture. The sysroot is generated from the root filesystem and uses the same metadata configuration.

The userspace tools include the tools already mentioned in the previous chapters, such as SystemTap, PowerTop, LatencyTop, perf, OProfile, and LTTng-UST. They are used for getting information about the system and developed application; information, such as power consumption, desktop stutters, counting of events, performance overviews, and diagnosing software, hardware, or functional problems, and even tracing software activities.

Setting up the environment

Before explaining the ADT Project further, its Eclipse IDE plug-ins, other features, and functionalities of the setup would be required. To install the Eclipse IDE, the first step involves the setup of a host system. There are multiple methods to do this:

  • Using an ADT install script: This is the recommended method to install the ADT, mostly because the installation process is completely automated. Users are in control of the features that they want available.
  • Using the ADT tarball: This method involves a section of an appropriate tarball with the architecture-specific toolchain and setting it up using a script. The tarball can be both downloaded and manually built using Bitbake. This method also has limitations due to the fact that not all of its features are available after installation, apart from the cross-toolchain and QEMU emulator.
  • Using a toolchain from the build directory: This method takes advantage of the fact that a build directory is already available, so the setup of the cross-toolchain is very easy. Also, in this case, it faces the same limitation as the one mentioned in the preceding point.

The ADT install script is the preferred method to install the ADT. Of course, before moving on to the installation step, the necessary dependencies need to be available to make sure that the ADT install script runs smoothly.

These packages were already mentioned in the previous chapters, but they will once again, be explained here to make things easy for you. I advise you to go back to these chapters and refer to the information once again as a memory exercise. To refer to packages that might be of interest to you, take a look at the ADT Installer packages, such as autoconf automake libtool libglib2.0-dev, Eclipse Plug-ins, and graphical support offered by the libsdl1.2-dev xterm packages.

After the host system is prepared with all the required dependencies, the ADT tarball can be downloaded from http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/adt-installer/. At this location, the adt_installer.tar.bz2 archive is available. It needs to be downloaded and its content extracted.

This tarball can also be generated using the Bitbake build system inside a build directory, and the result will be available inside the tmp/deploy/sdk/adt_installer.tar.bz2 location. To generate it, the next command needs to be given into the build directory, which is bitbake adt-installer. The build directory also needs to be properly configured for the target device.

The archive is unpacked using the tar -xjf adt_installer.tar.bz2 command. It can be extracted in any directory, and after unpacking the adt-installer directory, it is created and contains the ADT installer script called adt_installer. It also has a configuration file called adt_installer.conf, which is used to define the configurations before running the script. The configuration file defines information, such as the filesystem, kernel, QEMU support, and so on.

These are the variables that the configuration file contains:

  • YOCTOADT_REPO: This defines the packages and root filesystem on which the installation is dependent. Its reference value is defined at http://adtrepo.yoctoproject.org//1.7. Here, the directory structure is defined and its structure is the same between releases.
  • YOCTOADT_TARGETS: This defines the target architecture for which the cross development environment is set up. There are default values defined that can be associated with this variable, such as arm, ppc, mips, x86, and x86_64. Also, multiple values can be associated with it and the separation between them being is done using the space separator.
  • YOCTOADT_QEMU: This variable defines the use of the QEMU emulator. If it is set to Y, the emulator will be available after installation; otherwise the value is set to N, and hence, the emulator won't be available.
  • YOCTOADT_NFS_UTIL: This defines if the NFS user-mode that will be installed. The available values are, as defined previously, Y and N. For the use of the Eclipse IDE plug-ins, it is necessary to define the Y value for both YOCTOADT_QEMU and YOCTOADT_NFS_UTIL.
  • YOCTOADT_ROOTFS_<arch>: This specifies which architecture root filesystem to use from the repository that is defined in the first mentioned YOCTOADT_REPO variable. For the arch variable, the default values are the ones already mentioned in the YOCTOADT_TARGETS variable. This variable's valid values are represented by the image files available, such as minimal, sato, minimal-dev, sato-sdk,lsb, lsb-sdk, and so on. For multiple arguments to the variable, the space separator can be used.
  • YOCTOADT_TARGET_SYSROOT_IMAGE_<arch>: This represents the root filesystem from which the sysroot of the cross-development toolchain will be generated. The valid values for the 'arch' variable are the same as the one mentioned previously. Its value is dependent on what was previously defined as values for the YOCTOADT_ROOTFS_<arch> variable. So, if only one variable is defines as the value for the YOCTOADT_ROOTFS_<arch> variable, the same value will be available for YOCTOADT_TARGET_SYSROOT_IMAGE_<arch>. Also, if multiple variables are defined in the YOCTOADT_ROOTFS_<arch> variable, then one of them needs to define the YOCTOADT_TARGET_SYSROOT_IMAGE_<arch> variable.
  • YOCTOADT_TARGET_MACHINE_<arch>: This defines the machine for which the image is downloaded, as there could be compilation option differences between machines of the same architecture. The valid values for this variable are can be mentioned as: qemuarm, qemuppc, ppc1022ds, edgerouter, beaglebone, and so on.
  • YOCTOADT_TARGET_SYSROOT_LOC_<arch>: This defines the location where the target sysroot will be available after the installation process.

There are also some variables defined in the configuration files, such as YOCTOADT_BITBAKE and YOCTOADT_METADATA, which are defined for future work references. After all the variables are defined according to the needs of the developer, the installation process can start. This is done by running the adt_installer script:

cd adt-installer
./adt_installer

Here is an example of the adt_installer.conf file:

# Yocto ADT Installer Configuration File
#
# Copyright 2010-2011 by Intel Corp.
#
# Permission is hereby granted, free of charge, to any person obtaining a copy 
# of this software and associated documentation files (the "Software"), to deal 
# in the Software without restriction, including without limitation the rights 
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
# copies of the Software, and to permit persons to whom the Software is 
# furnished to do so, subject to the following conditions:

# The above copyright notice and this permission notice shall be included in 
# all copies or substantial portions of the Software.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
# THE SOFTWARE.


# Your yocto distro repository, this should include IPKG based packages and root filesystem files where the installation is based on

YOCTOADT_REPO="http://adtrepo.yoctoproject.org//1.7"
YOCTOADT_TARGETS="arm x86"
YOCTOADT_QEMU="Y"
YOCTOADT_NFS_UTIL="Y"

#YOCTOADT_BITBAKE="Y"
#YOCTOADT_METADATA="Y"

YOCTOADT_ROOTFS_arm="minimal sato-sdk"
YOCTOADT_TARGET_SYSROOT_IMAGE_arm="sato-sdk"
YOCTOADT_TARGET_MACHINE_arm="qemuarm"
YOCTOADT_TARGET_SYSROOT_LOC_arm="$HOME/test-yocto/$YOCTOADT_TARGET_MACHINE_arm"

#Here's a template for setting up target arch of x86 
YOCTOADT_ROOTFS_x86="sato-sdk"
YOCTOADT_TARGET_SYSROOT_IMAGE_x86="sato-sdk"
YOCTOADT_TARGET_MACHINE_x86="qemux86"
YOCTOADT_TARGET_SYSROOT_LOC_x86="$HOME/test-yocto/$YOCTOADT_TARGET_MACHINE_x86"

#Here's some template of other arches, which you need to change the value in ""
YOCTOADT_ROOTFS_x86_64="sato-sdk"
YOCTOADT_TARGET_SYSROOT_IMAGE_x86_64="sato-sdk"
YOCTOADT_TARGET_MACHINE_x86_64="qemux86-64"
YOCTOADT_TARGET_SYSROOT_LOC_x86_64="$HOME/test-yocto/$YOCTOADT_TARGET_MACHINE_x86_64"

YOCTOADT_ROOTFS_ppc="sato-sdk"
YOCTOADT_TARGET_SYSROOT_IMAGE_ppc="sato-sdk"
YOCTOADT_TARGET_MACHINE_ppc="qemuppc"
YOCTOADT_TARGET_SYSROOT_LOC_ppc="$HOME/test-yocto/$YOCTOADT_TARGET_MACHINE_ppc"

YOCTOADT_ROOTFS_mips="sato-sdk"
YOCTOADT_TARGET_SYSROOT_IMAGE_mips="sato-sdk"
YOCTOADT_TARGET_MACHINE_mips="qemumips"
YOCTOADT_TARGET_SYSROOT_LOC_mips="$HOME/test-yocto/$YOCTOADT_TARGET_MACHINE_mips"

After the installation has started, the user is asked the location of the cross-toolchain. If no alternative is offered, the default path is selected and the cross-toolchain is installed in the /opt/poky/<release> directory. The installation process can be visualized both in a silent or interactive way. By using the I option, the installation is done in an interactive mode, while the silent mode is enabled using the S option.

At the end of the install procedure, the cross-toolchain will be found in its defined location. An environment setup script will be available for later usage, and the image tarball in the adt-installer directory, and the sysroot directory is defined in the location of the YOCTOADT_TARGET_SYSROOT_LOC_<arch> variable.

As shown previously, there is more than one method to prepare the ADT environment. The second method involves only the installation of the toolchain installer—although it offers the possibility of having a prebuilt cross-tooolchain, support files and scripts, such as the runqemu script to start something similar to a kernel or Linux image in an emulator—which does not offer the same possibilities as the first option. Also, this option has its limitations regarding the sysroot directory. Although it's been generated, the sysroot directory might still need to be extracted and installed in a separate location. This can happened for various reasons, such as the need to boot a root filesystem over NFS or develop the application using the root filesystem as the target sysroot.

The root filesystem can be extracted from an already generated cross-toolchain using the runqemu-extract-sdk script, which should be called only after the cross-development environment script was set up using source command.

There are two methods to obtain the toolchain installed for this second option. The first method involves the use of the toolchain installer available at the folder that matches your development host machine. In this folder, multiple install scripts are available. Each one matches a target architecture, so the right one should be selected for the target you have. One such example can be seen from http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh, which is, in fact, the installer script for the armv7a target and the x86_64 host machine.

If your target machine is not one of the ones that are made available by the Yocto community, or if you prefer an alternative to this method, then building the toolchain installer script is the method for you. In this case, you will require a build directory, and you will be presented with two alternatives, both of them are equally good:

  • The first one involves the use of the bitbake meta-toolchain command, and the end result is an installer script that requires the installation and set up of the cross-toolchain in a separate location.
  • The second alternative involves the use of the bitbake –c populate_sdk <image-name> task, which offers the toolchain installer script and the matching sysroot for the target. The advantage here is that the binaries are linked with only one and the same libc, making the toolchain self-contained. There is, of course, a limitation that each architecture can create only one specific build. However, target-specific options are passed through the gcc options. Using variables, such as CC or LD, makes the process easier to maintain and also saves some space in the build directory.

After the installer is downloaded, make sure that the install script has set the execution correctly, and start the installation with the ./poky-glibc-x86_64-core-image-sato-armv7a-vfp-neon-toolchain-1.7.sh command.

Some of the information you require includes the place where the installation should be made, the default location being the /opt/poky/1.7 directory. To avoid this, the script can be called with the –d <install-location> argument and the installation can be made in the <install-location> location, as mentioned.

Note

Make sure that the MACHINE variable is set accordingly in the local.conf file. Also, if the build is done for a different host machine, then SDKMACHINE should also be set. More than one MACHINE cross-toolchain can be generated in the same build directory, but these variables need to be properly configured.

After the installation process is finished, the cross-toolchain will be available in the selected location, and the environment script will also be available for sourcing when needed.

The third option involves the use of the build directory and the execution of the bitbake meta-ide-support command. Inside the build directory, the proper environment needs to be set using one of the two available build environment setup scripts, which include the oe-init-build-env script or oe-init-build-env-memres. The local configuration from the local.conf file also needs to be set accordingly for the target architecture. After these steps are fulfilled by the developer, the bitbake meta-ide-support command could be used to start the generation of the cross-toolchain. At the end of the process, an environment setup script will be available inside the <build-dir-path>/tmp directory, but in this case, the toolchain is tightly linked into the build directory in which it was built.

With the environment set up, writing of an application can start, but the developer would still need to complete some steps before finishing the activity, such as testing the application on the real root filesystem, debugging, and many others. For the kernel module and driver implementation, the kernel source code will be required, so the activity is just starting.

Eclipse IDE

The plug-ins available for Eclipse from the Yocto Project include the functionalities for the ADT Project and toolchain. They allow developers to use a cross-compiler, debugger, and all the available tools generated with the Yocto Project, Poky, and additional meta layers. Not only can these components be used within the Eclipse IDE, but they also offer a familiar environment for application development.

The Eclipse IDE is an alternative for developers who are not interested in interacting with editors, such as vim, although, in my opinion, vim can be used for all kinds of projects. Even if their dimensions or complexities are not a problem, the overhead for using vim might not suit all tastes. The Eclipse IDE is the best alternative available for all developers. It has a lot of useful features and functionalities that can make your life a little easier and it is pretty easy to grasp.

The Yocto Project offers support for two versions of Eclipse, Kepler and Juno. The Kepler version is the one recommended with the latest Poky release. I also recommend the Kepler 4.3.2 version of Eclipse, the one downloaded from the official download site of Eclipse, http://www.eclipse.org/downloads.

From this site, the Eclipse Standard 4.3.2 version containing the Java Development Tools (JDT), the Eclipse Platform, and the Development Environment Plug-ins for the host machine should be downloaded. After the download is finished, the received archive content should be extracted using the tar command:

tar xzf eclipse-standard-kepler-SR2-linux-gtk-x86_64.tar.gzls

The next step is represented by the configuration. With the content extracted, the Eclipse IDE needs to be configured before installing the Yocto Project-specific plug-ins. The configuration starts with initializing the Eclipse IDE:

The Eclipse IDE is started after executing the ./eclipse executable and setting the Workspace location. This is how the starting windows looks:

Eclipse window

To initialize the Eclipse IDE perform the following steps:

  1. Select Workbench, and you will be moved into the empty workbench where the projects source code will be written.
  2. Now, navigate through the Help menu and select Install New Software.

    Help menu

  3. A new window will open, and in the Work with: drop-down menu, select Kepler - http://download.eclipse.org/releases/kepler, as shown in the following screenshot:

    Install window

  4. Expand the Linux Tools section and select LTTng – Linux Tracing Toolkit box, as shown in the following screenshot:

    Install—LTTng – Linux Tracing Toolkit box

  5. Expand the Moble and Device Development section and select the following:
    • 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
  6. Expand the Programming Languages section and select the following:
    • C/C++ Autotools Support
    • C/C++ Development Tools

    This is shown in the following screenshot:

    Available software list window

  7. Finish the installation after taking a quick look at the Install Details menu and enabling the license agreement:

    Install details window

After these steps, the Yocto Project Eclipse plug-ins can be installed into the IDE, but not before restarting the Eclipse IDE to make sure that the preceding changes take effect. The result after the configuration phase is visible here:

Eclipse—Configuring phase results

To install the Eclipse plug-ins for the Yocto Project, these steps are required:

  1. Start the Eclipse IDE as mentioned previously.
  2. As shown in the previous configuration, select the Install New Software option from the Help menu.
  3. Click on the Add button and insert downloads.yoctoproject.org/releases/eclipse-plugin/1.7/kepler/ in the URL section. Give a proper name to the new Work with: site as indicated here:

    Edit site window

  4. After the OK button is pressed, and the Work with site is updated, new boxes appear. Select all of them, as shown in this image, and click on the Next button:

    Install details window

  5. One final pick at the installed components and the installation is approaching its end.

    Install details window

  6. If this warning message appears, press OK and move further. It only lets you know that the installed packages have unsigned content.

    Security warning window

The installation finishes only after the Eclipse IDE is restarted for the changes to take effect.

After the installation, the Yocto plug-ins are available and ready to be configured. The configuration process involves the setup of the target-specific option and cross-compiler. For each specific target, the preceding configurations steps need to be performed accordingly.

The configuration process is done by selecting the Preferences option from the Window menu. A new window will open, and from there, the Yocto Project ADT option should be selected. More details are available, as shown in the following screenshot:

Eclipse IDE—Preferences

The next thing to do involves the configuration of the available options of the cross-compiler. The first option refers to the toolchain type, and there are two options available, Standalone prebuilt toolchain and Build system derived toolchain, which is the default selected option. The former refers to a toolchain specific for an architecture that already has an existing kernel and root filesystem, so the developed application will be made available in the image manually. However, this step is not a requirement since all the components are separated. The latter option refers to a toolchain built inside a Yocto Project build directory.

The next elements that need to be configured are the toolchain location, sysroot location, and the target architecture. The Toolchain Root Location is used to define the toolchain install location. For an installation done with the adt_installer script, for example, the toolchain will be available in the /opt/poky/<release> directory. The second argument, Sysroot Location, represents the location of the target device root filesystem. It can be found in the /opt/poky/<release> directory, as seen the preceding example, or even inside the build directory if other method to generate it were used. The third and last option from this section is represented by the Target Architecture and it indicates the type of hardware used or emulated. As it can be seen on the window, it is a pull-down menu where the required option is selected, and a user will find all the supported architectures listed. In a situation where the necessary architecture is not available inside the pull-down menu, the corresponding image for the architecture will need to be built.

The last remaining section is represented by the target specific option. This refers to the possibility of emulating an architecture using QEMU or running the image on the externally available hardware. For external hardware, use the External HW option that needs to be selected for the work to be finished, but for the QEMU emulation, there are still things to do besides selecting the QEMU option. In this scenario, the user will also need to indicate the Kernel and Custom Option. For the kernel selection, the process is simple. It is available in the prebuilt image location in case the Standalone pre-built toolchain option was selected or in the tmp/deploy/images/<machine-name> directory if the Build system derived toolchain option was selected. For the second option, the Custom Option argument, the process for adding it will not be as simple as the preceding options.

The Custom Option field needs to be filled with various options, such as kvm, nographic, publicvnc, or serial, which indicate major options for the emulated architecture or their parameters. These are kept inside angled brackets, and include parameters, such as the memory used (-m 256), networking support (-net), and full screen support (-full-screen). More information regarding the available options and parameters can be found using the man qemu command. All of the preceding configurations can be overwritten using the Change Yocto Project Settings option from the Project menu after a project is defined.

To define a project, these steps need to be taken:

  1. Select the Project… option from the File | New menu option, as shown here:

    Eclipse IDE—Project

  2. Select C project from the C/C++ option. This will open a C Project window:

    Eclipse IDE—New project window

  3. In the C Project window, there are multiple options available. Let's select Yocto Project ADT Autotools Project, and from there, the Hello World ANSI C Autotools Project option. Add a name for the new project, and we are ready to move to the next steps:

    C project window

  4. In the C Project window we you be prompted to add information regarding the Author, Copyright notice, Hello world greetings, Source, and License fields accordingly:

    C project—basic settings window

  5. After all the information is added, the Finish button can be clicked on. The user will be prompted in the new C/C++ perspective that is specific for the opened project, with the newly created project appearing on the left-hand side of the menu.
  6. After the project is created and the source code is written, to build the project, select the Build Project option from the Project… menu.

QEMU emulator

QEMU is used in the Yocto Project as a virtualization machine and emulator for various target architectures. It is very useful to run and test various Yocto generated applications and images, apart from fulfilling other purposes. Its primary use outside of the Yocto world is its selling point for the Yocto Project too, making it the default tool to be used to emulate hardware.

Note

More information about the use case of QEMU can be found by accessing http://www.yoctoproject.org/docs/1.7/adt-manual/adt-manual.html#the-qemu-emulator.

Interaction with the QEMU emulation is done within Eclipse, as shown previously. For this to happen, the proper configuration would be required, as instructed in the preceding section. Starting the QEMU emulation here is done using the External Tools option from the Run menu. A new window will be opened for the emulator, and after the corresponding login information is passed to the prompt, the shell will be available for user interaction. An application can be deployed and debugged on the emulator also.

Note

More information regarding QEMU interaction is available at http://www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#dev-manual-qemu.

Debugging

Debugging an application can also be done using the QEMU emulator or the actual target hardware, if it exists. When the project was configured, a run/debug Eclipse configuration was generated as a C/C+ Remote Application instance, and it can be found on the basis of its name, which is according to the <project-name>_gdb_-<suffix> syntax. For example, TestProject_gdb_armv5te-poky-linux-gnueabi could be an example of this.

To connect to the Eclipse GDB interface and start the remote target debugging process, the user is required to perform a few steps:

  1. Select C/C++ Remote application from the Run | Debug configuration menu and choose the run/debug configuration from the C/C++ Remote Application available in the left panel.
  2. Select the suitable connection from the drop-down list.
  3. Select the binary application to deploy. If multiple executables are available in your project, by pushing the Search Project button, Eclipse will parse the project and provide a list with all the available binaries.
  4. Enter the absolute path in which the application will be deployed by setting the Remote Absolute File Path for C/C++ Application: field accordingly.
  5. Selecting the debugger option is available in the Debugger tab. To debug shared libraries, a few extra steps are necessary:
    • Select the Add | Path Mapping option from the Source tab to make sure a path mapping is available for the debug configuration.
    • Select Load shared libraries symbols automatically from the Debug/Shared Library tab and indicate the path of the shared libraries accordingly. This path is highly dependent on the architecture of the processor, so be very careful which library file you indicate. Usually, for the 32-bit architecture, the lib directory is selected, and for the 64-bit architecture, the lib64 directory is chosen.
    • On the Arguments tab, there is a possibility of passing various arguments to the application binary during the time of execution.
  6. Once all the debug configurations are finished, click on the Apply and Debug buttons. A new GDB session will be launched and Debug perspective will open. When the debugger is being initialized, Eclipse will open three consoles:
    • A GDB console named after the GDB binary described previously, used for command-line interaction
    • A remote shell used to run an application display results
    • A local machine console that is named after the binary path, which in most of cases, is not used. It remains as an artefact.
  7. After the setup of the debug configuration, the application can be rebuilt and executed again using the available Debug icon in the toolbar. If, in fact, you want only to run and deploy the application, the Run icon can be used.

Profiling and tracing

Inside the Yocto Tools menu, you can see the supported tools that are used for the tracing and profiling of developed applications. These tools are used for enhancing various properties of the application and, in general, the development process and experience. The tools that will be presented are LTTng, Perf, LatencyTop, PerfTop, SystemTap, and KGDB.

The first one we'll take a look at is the LTTng Eclipse Plug-in, which offers the possibility of tracing a target session and analyzing the results. To start working with the tool, a quick configuration is necessary first, as follows:

  1. Start the tracing perspective by selecting Open Perspective from the Window menu.
  2. Create a new tracing project by selecting Project from the File | New menu.
  3. Select Control View from the Window | Show view | Other… | Lttng menu. This will enable you to access all these desired operations:
    • Creating a new connection
    • Creating a session
    • Starting/stopping tracing
    • Enabling events

Next, we'll introduce the user space performance analyzing tool called Perf. It offers statistical profiling of the application code and a simple CPU for multiple threads and kernel. To do this, it uses a number of performance counters, dynamic probes, or trace points. To use the Eclipse Plug-in, a remote connection to the target is required. It can be done by the Perf wizard or by using the Remote System Explorer | Connection option from the File | New | Other menu. After the remote connection is set up, interaction with the tool is the same as in the case of the command line support available for the tool.

LatencyTop is an application that is used to identify the latencies available within the kernel and also their root cause. This tool is not available for ARM kernels that have Symmetric multiprocessing (SMP) support enabled due to the limitation of the ARM kernels. This application also requires a remote connection. After the remote connection is set up, the interaction is the same as in the case of the command line support available for the tool. This application is run from the Eclipse Plug-in using sudo.

PowerTop is used to measure the consumption of electrical power. It analyzes the applications, kernel options, and device drivers that run on a Linux system and estimates their power consumption. It is very useful to identify components that use the most amount of power. This application requires a remote connection. After the remote connection is set up, the interaction with the application is the same as for the command line available support for the tool. This application is run from the Eclipse Plug-in using the –d option to display the output in the Eclipse window.

SystemTap is a tool that enables the use of scripts to get results from a running Linux. SystemTap provides free software (GPL) infrastructure to simplify the gathering of information about the running Linux system via the tracing of all kernel calls. It's very similar to dtrace from Solaris, but it is still not suited for production systems, unlike dtrace. It uses a language similar to awk and its scripts have the .stp extension. The monitored data can be extracted and various filters and complex processing can be done on them. The Eclipse Plug-in uses the crosstap script to translate the .stp scripts to a C language to create a Makefile, run a C compiler to create a kernel module for the target architecture that is inserted into the target kernel, and later, collect the tracing data from the kernel. To start the SystemTap plug-in in Eclipse, there are a number of steps to be followed:

  1. Select the systemtap option from the Yocto Project Tools menu.
  2. In the opened windows, the crosstap argument needs to be passed:
    • Set the Metadata Location variable to the corresponding poky directory
    • Set Remote User ID by entering the root (the default option) because it has ssh access to the target-any other user that has the same privileges is also a good choice
    • Set in the Remote Host variable to the corresponding IP address for the target
    • Use the Systemtap Scripts variable for the full path to the .stp scripts
    • Set additional cross options using the Systemtap Args field

The output of the .stp script should be available in the console view from Eclipse.

The last tool we'll take a look at is KGDB. This tool is used specifically for the debugging of Linux kernel, and is useful only if development on the Linux kernel source code is done inside the Eclipse IDE. To use this tool, a number of necessary configuration setups are required:

  • Disable the C/C++ indexing:
    • Select the C/C++ Indexer option from the Window | Preferences menu
    • Unselect the Enable indexer checkbox
  • Create a project where the kernel source code can be imported:
    • Select the C/C++ | C Project option from the File | New menu
    • Select the Makefile project | Empty project option and give a proper name to the project
    • Unselect the Use default location option
    • Click on the Browse button and identify the kernel source code local git repository location
    • Press the Finish button and the project should be created

After the prerequisites are fulfilled, the actual configuration can start:

  • Select the Debug Configuration option from the Run menu.
  • Double-click on the GDB Hardware Debugging option to create a default configuration named <project name> Default.
  • From the Main tab, browse to the location of the vmlinux built image, select the Disable auto build radio button, as well as the GDB (DFS) Hardware Debugging Launcher option.
  • For the C/C++ Application option available in the Debugger tab, browse for the location of the GDB binary available inside the toolchain (if ADT installer script is available, its default location should be /opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb). Select Generic serial option from the JTAG Device menu. The Use remote target option is a requirement.
  • From the Startup tab, select the Load symbols option. Make sure that the Use Project binary option indicates the correct vmlinux image and that the Load image option is not selected.
  • Press the Apply button to make sure the previous configuration is enabled.
  • Prepare the target for the serial communication debugging:
    • Set the echo ttyS0,115200 | /sys/module/kgdboc/parameters/kgdboc option to make sure the appropriate device is used for debugging
    • Start KGDB on the echo g | /proc/sysrq-trigger target
    • Close the terminal with the target but keep the serial connectivity
  • Select the Debug Configuration option from the Run menu
  • Select the previously created configuration and click on the Debug button

After the Debug button is pressed, the debug session should start and the target will be halted in the kgdb_breakpoint() function. From there, all the commands specific to GDB are available and ready to be used.

The Yocto Project bitbake commander

The bitbake commander offers the possibility of editing recipes and creating a metadata project in a manner similar to the one available in the command line. The difference between the two is that the Eclipse IDE is used to do the metadata interaction.

To make sure that a user is able to do these sort of actions, a number of steps are required:

  • Select the Project option from the File | New menu
  • Select the Yocto Project BitBake Commander wizard from the opened window
  • Select the New Yocto Project option and a new window will be opened tp define properties of the new project
  • Using Project Location, identify the parent of the poky directory
  • Use the Project Name option to define the project name. Its default value is poky
  • For the Remote service provider variable, select the Local choice and make use of the same choice for the Connection name drop-down list
  • Make sure that the Clone checkbox is not selected for an installed poky source directory

By using the Eclipse IDE, its features are available to be used. One of the most useful features is the quick search option that could prove to be very useful for some developers. Other benefits include the possibility of creating recipes using templates, editing them with syntax highlighting, auto completion, error reports on the fly, and many more.

Note

The use of bitbake commander is restricted to local connections only. The remote connection causes the IDE to freeze due to a bug available upstream.

Summary

In this chapter, you were presented with information about the functionalities of the ADE offered by the Yocto Project, and the numerous Eclipse Plug-ins available for application development not only as an alternative, but also as a solution for developers who are connected to their IDEs. Although the chapter started with an introduction to the application development options for the command-line enthusiast, it shortly became more about IDE interaction than anything else. This happened because alternative solutions need to be available so that developers could choose what fits their needs best.

In the next chapter, a number of Yocto Project components will be presented. This time, they are not related to application development, but involve metadata interaction, quality assurance, and continuous integration services. I will try to present yet another face of the Yocto Project that I believe will help readers get a better picture of the Yocto Project, and eventually, interact with and contribute to the components that suit them and their needs best.

上一章目录下一章