documentation/poky-ref-manual/development.xml: re-write of software dev section
This is a comprehensive pass through this entire section that incorporates understanding given to me by Scott Garman. I have added more detail and text that helps the non-developer understand what is fundamentally going on. (From yocto-docs rev: 124c722ccf0316f6e62790ca77c88d0444559378) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
34de499685
commit
96f0c57a0a
|
@ -15,40 +15,56 @@
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<section id="platdev-appdev-external-sdk">
|
<section id="platdev-appdev-external-sdk">
|
||||||
<title>External Development Using the Application Development Toolkit (ADT)</title>
|
<title>External Development Using the Meta-Toolchain</title>
|
||||||
<para>
|
<para>
|
||||||
The meta-toolchain and meta-toolchain-sdk targets build tarballs that contain toolchains and
|
The Yocto Project provides toolchains that allow you to develop your application
|
||||||
libraries suitable for application development outside of Poky.
|
outside of the Yocto Project build system for specific hardware.
|
||||||
For information on these targets see the <ulink linkend='ref-images'>Reference: Images</ulink>
|
These toolchains (called meta-toolchains) contain cross-development tools like compilers,
|
||||||
appendix.
|
linkers, and debuggers that build your application for your target.
|
||||||
|
The Yocto Project also provides images that have toolchains set up for supported
|
||||||
|
architectures.
|
||||||
|
See
|
||||||
|
<xref linkend='ref-images'>Reference: Images</xref> for a listing of the image
|
||||||
|
types that Yocto Project supports.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Using the BitBake tool you can build a meta-toolchain or meta-toolchain-sdk target,
|
||||||
|
which is in the form of a tarball.
|
||||||
|
Unpacking this tarball into the <filename class="directory">/opt/poky</filename> directory
|
||||||
|
on your host produces a setup script
|
||||||
|
(e.g. <filename>/opt/poky/environment-setup-i586-poky-linux</filename>) that
|
||||||
|
you can source to initialize your build environment.
|
||||||
|
Sourcing this script adds the compiler, QEMU scripts, QEMU binary, a special version of
|
||||||
|
<filename>pkgconfig</filename> and other
|
||||||
|
useful utilities to the <filename>PATH</filename> variable used by the Yocto Project
|
||||||
|
build environment.
|
||||||
|
Variables to assist <filename>pkgconfig</filename> and
|
||||||
|
Autotools are also defined so that, for example, <filename>configure</filename>
|
||||||
|
can find pre-generated test results for tests that need target hardware on which to run.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
These tarballs unpack into the
|
Using the toolchain with Autotool-enabled packages is straightforward - just pass the
|
||||||
<filename class="directory">/opt/poky</filename> directory and contain
|
appropriate <filename>host</filename> option to <filename>configure</filename>.
|
||||||
a setup script (e.g.
|
|
||||||
<filename>/opt/poky/environment-setup-i586-poky-linux</filename>), from which
|
|
||||||
you can source to initialize a suitable environment. Sourcing these files adds the
|
|
||||||
compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other
|
|
||||||
useful utilities to the PATH variable. Variables to assist pkgconfig and
|
|
||||||
autotools are also defined so that, for example, configure can find pre-generated test
|
|
||||||
results for tests that need target hardware on which to run.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Using the toolchain with autotool-enabled packages is straightforward - just pass the
|
|
||||||
appropriate host option to configure.
|
|
||||||
Following is an example:
|
Following is an example:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
$ ./configure --host=arm-poky-linux-gnueabi
|
$ ./configure --host=arm-poky-linux-gnueabi
|
||||||
</literallayout>
|
</literallayout>
|
||||||
For other projects it is usually a case of ensuring the cross tools are used:
|
For projects that are not Autotool-enabled, it is usually just a case of ensuring
|
||||||
|
you point to and use the cross-toolchain.
|
||||||
|
For example, the following two lines of code in a <filename>Makefile</filename>
|
||||||
|
that builds your application
|
||||||
|
specify to use the cross-compiler <filename>arm-poky-linux-gnueabi-gcc</filename>
|
||||||
|
and linker <filename>arm-poky-linux-gnueabi-ld</filename>, which are part of the
|
||||||
|
meta-toolchain you have previously established:
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld
|
CC=arm-poky-linux-gnueabi-gcc;
|
||||||
|
LD=arm-poky-linux-gnueabi-ld;
|
||||||
</literallayout>
|
</literallayout>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id="using-the-eclipse-and-anjuta-plug-ins">
|
<section id="using-the-eclipse-and-anjuta-plug-ins">
|
||||||
<title>Using the Eclipse Plug-in</title>
|
<title>External Development Using the Eclipse Plug-in</title>
|
||||||
<para>
|
<para>
|
||||||
The current release of the Yocto Project supports the Eclipse IDE plug-in
|
The current release of the Yocto Project supports the Eclipse IDE plug-in
|
||||||
to make developing software easier for the application developer.
|
to make developing software easier for the application developer.
|
||||||
|
@ -79,420 +95,74 @@
|
||||||
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
|
<ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
|
||||||
"Application Development Toolkit (ADT) User's Guide."</ulink>
|
"Application Development Toolkit (ADT) User's Guide."</ulink>
|
||||||
</para>
|
</para>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
|
||||||
<!--
|
|
||||||
|
|
||||||
<section id="the-eclipse-plug-in">
|
|
||||||
<title>The Eclipse Plug-in</title>
|
|
||||||
<para>
|
|
||||||
To use the Eclipse plug-in, a toolchain and SDK built by Poky is required along with
|
|
||||||
the Eclipse Framework (Helios 3.6.1).
|
|
||||||
To install the plug-in you need to be in the Eclipse IDE and select
|
|
||||||
the following menu:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
Help -> Install New Software
|
|
||||||
</literallayout>
|
|
||||||
Specify the target URL as
|
|
||||||
<ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink>.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
If you want to download the source code for the plug-in you can find it in the Poky
|
|
||||||
git repository, which has a web interface, and is located at
|
|
||||||
<ulink url="http://git.yoctoproject.org"></ulink> under IDE Plugins.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<section id="installing-and-setting-up-the-eclipse-ide">
|
|
||||||
<title>Installing and Setting up the Eclipse IDE</title>
|
|
||||||
<para>
|
|
||||||
If you don't have the Eclipse IDE (Helios 3.6.1) on your system you need to
|
|
||||||
download and install it from <ulink url="http://www.eclipse.org/downloads"></ulink>.
|
|
||||||
Choose the Eclipse Classic, which contains the Eclipse Platform, Java Development
|
|
||||||
Tools (JDT), and the Plug-in Development Environment.
|
|
||||||
</para>
|
|
||||||
<note>
|
|
||||||
<para>
|
|
||||||
Due to the Java Virtual Machine's garbage collection (GC) process the
|
|
||||||
permanent generation space (PermGen) is not cleaned up. This space stores
|
|
||||||
meta-data descriptions of classes. The default value is set too small
|
|
||||||
and it could trigger an out-of-memory error like the following:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
Java.lang.OutOfMemoryError: PermGen space
|
|
||||||
</literallayout>
|
|
||||||
This error causes the applications to hang.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
<para>
|
|
||||||
To fix this issue you can use the <filename>-vmargs</filename>
|
|
||||||
option when you start Eclipse to increase the size of the permanent generation space:
|
|
||||||
<literallayout class='monospaced'>
|
|
||||||
Eclipse -vmargs -XX:PermSize=256M
|
|
||||||
</literallayout>
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="installing-the-yocto-plug-in">
|
|
||||||
<title>Installing the Yocto Plug-in</title>
|
|
||||||
<para>
|
|
||||||
Once you have the Eclipse IDE installed and configured you need to install the
|
|
||||||
Yocto plug-in. You do this similar to installing the Eclipse plug-ins in the
|
|
||||||
previous section.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Do the following to install the Yocto plug-in into the Eclipse IDE:
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Select the "Help -> Install New Software" item.</para></listitem>
|
|
||||||
<listitem><para>In the "Work with:" area click "Add..." and enter the URL for
|
|
||||||
the Yocto plug-in, which is
|
|
||||||
<ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink></para></listitem>
|
|
||||||
<listitem><para>Finish out the installation of the update similar to any other
|
|
||||||
Eclipse plug-in.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="configuring-yocto-eclipse-plug-in">
|
|
||||||
<title>Configuring Yocto Eclipse plug-in</title>
|
|
||||||
<para>
|
|
||||||
To configure the Yocto Eclipse plug-in you need to select the mode and the
|
|
||||||
architecture with which you will be working. Start by selecting "Preferences"
|
|
||||||
from the "Window" menu and then select "Yocto SDK".
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
If you normally will use an installed Yocto
|
|
||||||
SDK (under <filename>/opt/poky</filename>) select “SDK Root Mode”. Otherwise, if your crosstool chain
|
|
||||||
and sysroot are within your poky tree, select “Poky Tree Mode”.
|
|
||||||
If you are in SDK Root Mode you need to provide your poky tree path, for
|
|
||||||
example, <filename>$<Poky_tree>/build/</filename>.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Next, you need to select the architecture.
|
|
||||||
Use the drop down list and select the architecture that you’ll be primarily
|
|
||||||
working against.
|
|
||||||
For target option, select your typical target QEMU vs External hardware. If you
|
|
||||||
choose QEMU, you’ll need to specify your QEMU kernel file with full path and the
|
|
||||||
rootfs mount point. Yocto QEMU boots off user mode NFS.
|
|
||||||
See the <link linkend='platdev-appdev-qemu'>Developing Externally in QEMU</link> section for
|
|
||||||
how to set it up.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
To make your settings the defaults for every new Yocto project created using
|
|
||||||
the Eclipse IDE, simply save the settings.
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="using-the-yocto-eclipse-plug-in">
|
|
||||||
<title>Using the Yocto Eclipse Plug-in</title>
|
|
||||||
<para>
|
|
||||||
As an example, this section shows you how to cross-compile a Yocto C project that
|
|
||||||
is autotools-based, deploy the project into QEMU, and then run the debugger against it.
|
|
||||||
You need to configure the project, trigger the <filename> autogen.sh</filename>, build
|
|
||||||
the image, start QEMU, and then debug.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
The following steps show how to create a Yocto autotools-based project using a given template:
|
|
||||||
</para>
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Select "File -> New -> Project" to start the wizard.</para></listitem>
|
|
||||||
<listitem><para>Expand "C/C++" and select "C Project".</para></listitem>
|
|
||||||
<listitem><para>Click "Next" and select a template (e.g. "Hello World ANSI C Project").</para></listitem>
|
|
||||||
<listitem><para>Complete the steps to create the new Yocto autotools-based project using
|
|
||||||
your chosen template.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
<para>
|
|
||||||
By default, the project uses the Yocto preferences settings as defined using the procedure in
|
|
||||||
<link linkend="configuring-yocto-eclipse-plug-in">the previous section</link>.
|
|
||||||
If there are any specific setup requirements for the newly created project
|
|
||||||
you need to reconfigure the Yocto plug-in through the menu selection by doing the following:
|
|
||||||
</para>
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Select the "Project -> Invoke Yocto Tools -> Reconfigure Yocto" menu item.</para></listitem>
|
|
||||||
<listitem><para>Complete the dialogue to specify the specific toolchain and QEMU setup information.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
<para>
|
|
||||||
To build the project follow these steps:
|
|
||||||
</para>
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Select "Project -> Reconfigure Project" to trigger the
|
|
||||||
<filename>autogen.sh</filename> command.</para></listitem>
|
|
||||||
<listitem><para>Select "Project -> Build" to build the project.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
<para>
|
|
||||||
To start QEMU follow these steps:
|
|
||||||
</para>
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Select "Run -> External Tools" and see if there is
|
|
||||||
a QEMU instance for the desired target.
|
|
||||||
If one exists, click on the instance to start QEMU.
|
|
||||||
If your target does not exist, click "External Tools Configuration" and
|
|
||||||
you should find an instance of QEMU for your architecture
|
|
||||||
under the entry under "Program".</para></listitem>
|
|
||||||
<listitem><para>Wait for the boot to complete.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
<para>
|
|
||||||
To deploy your project and start debugging follow these steps:
|
|
||||||
</para>
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Highlight your project in the project explorer.</para></listitem>
|
|
||||||
<listitem><para>Select "Run -> Debug Configurations" to bring up your remote debugging configuration
|
|
||||||
in the right-hand window.</para></listitem>
|
|
||||||
<listitem><para>Expand “C/C++ Remote Application”.</para></listitem>
|
|
||||||
<listitem><para>Select "projectname_ gdb_target-poky-linux".
|
|
||||||
You need to be sure there is an entry for the remote target.
|
|
||||||
If no entry exists, click "New..." to bring up the wizard.
|
|
||||||
Use the wizard to select TCF and enter the IP address of you remote target in the
|
|
||||||
“Host name:” field.
|
|
||||||
Back in the Remote Debug Configure window, specify in the
|
|
||||||
“Remote Absolute File Path for C/C++ Application” field the absolute path for the program on
|
|
||||||
the remote target.
|
|
||||||
By default, the program deploys into the remote target.
|
|
||||||
If you don't want this behavior then check “Skip download to target path”.</para></listitem>
|
|
||||||
<listitem><para>Click "Debug” to start the remote debugging session.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="using-yocto-eclipse-plug-in-remote-tools-suite">
|
|
||||||
<title>Using Yocto Eclipse plug-in Remote Tools Suite</title>
|
|
||||||
<para>
|
|
||||||
Remote tools allow you to perform system profiling, kernel tracing,
|
|
||||||
examine power consumption, and so forth. To see and access the remote tools use the
|
|
||||||
"Window -> YoctoTools" menu.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
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.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Here are some specifics about the remote tools:
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem><para>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 .</para></listitem>
|
|
||||||
<listitem><para>lttng: Selecting this tool runs "usttrace" on the remote target, transfers
|
|
||||||
the output data back to the local host machine and uses "lttv-gui" to graphically
|
|
||||||
display the output. The "lttv-gui" must be installed on the
|
|
||||||
local host machine to use this tool.
|
|
||||||
For information on how to use "lttng" to trace an
|
|
||||||
application, see <ulink url="http://lttng.org/files/ust/manual/ust.html"></ulink>.
|
|
||||||
<para>
|
|
||||||
For "Application" you must supply the absolute path name of the application to
|
|
||||||
be traced by user mode lttng. For example, typing <filename>/path/to/foo"
|
|
||||||
</filename> triggers "usttrace /path/to/foo" on the
|
|
||||||
remote target to trace the program <filename>/path/to/foo</filename>.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
"Argument" is passed to "usttrace" running on the remote target.
|
|
||||||
</para></para>
|
|
||||||
</listitem>
|
|
||||||
<listitem><para>powertop: Selecting this tool runs "powertop" on the
|
|
||||||
remote target machine and displays the results in a new view called "powertop".
|
|
||||||
<para>
|
|
||||||
"Time to gather data(sec):" is the time passed in seconds before data is
|
|
||||||
gathered from the remote target for analysis.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
"show pids in wakeups list:" corresponds to the <filename>-p</filename>
|
|
||||||
argument passed to "powertop".
|
|
||||||
</para></para>
|
|
||||||
</listitem>
|
|
||||||
<listitem><para>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.</para></listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="the-anjuta-plug-in">
|
|
||||||
<title>The Anjuta Plug-in</title>
|
|
||||||
<note>
|
|
||||||
<para>
|
|
||||||
Support for the Anjuta plug-in ends after Yocto project 0.9 Release.
|
|
||||||
However, the source code can be downloaded from the git repository listed later in
|
|
||||||
this section.
|
|
||||||
The community is free to continue supporting it post 0.9 Release.
|
|
||||||
</para>
|
|
||||||
</note>
|
|
||||||
<para>
|
|
||||||
An Anjuta IDE plug-in exists to make developing software within the Poky framework
|
|
||||||
easier for the application developer familiar with that environment.
|
|
||||||
The plug-in presents a graphical IDE that allows you to cross-compile, cross-debug,
|
|
||||||
profile, deploy, and execute an application.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
To use the plug-in, a toolchain and SDK built by Poky, Anjuta, its development headers and the Anjuta
|
|
||||||
Plug-in are all required.
|
|
||||||
The Poky Anjuta Plug-in is available to download as a tarball at the OpenedHand
|
|
||||||
labs <ulink url="http://labs.o-hand.com/anjuta-poky-sdk-plugin/"></ulink> page or
|
|
||||||
directly from the Poky Git repository located at git://git.yoctoproject.org/anjuta-poky.
|
|
||||||
You can access the source code from a web interface to the repository at
|
|
||||||
<ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
See the README file contained in the project for more information on
|
|
||||||
Anjuta dependencies and building the plug-in.
|
|
||||||
If you want to disable remote gdb debugging, pass the "‐‐disable-gdb-integration" switch when
|
|
||||||
you configure the plug-in.
|
|
||||||
</para>
|
|
||||||
<section id="setting-up-the-anjuta-plugin">
|
|
||||||
<title>Setting Up the Anjuta Plug-in</title>
|
|
||||||
<para>
|
|
||||||
Follow these steps to set up the plug-in:
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Extract the tarball for the toolchain into / as root.
|
|
||||||
The toolchain will be installed into <filename>/opt/poky</filename>.</para></listitem>
|
|
||||||
<listitem><para>To use the plug-in, first open or create an existing project.
|
|
||||||
If you are creating a new project, the "C GTK+"
|
|
||||||
project type will allow itself to be cross-compiled.
|
|
||||||
However, you should be aware that this type uses "glade" for the UI.</para></listitem>
|
|
||||||
<listitem><para>To activate the plug-in, select "Edit -> Preferences" and then choose
|
|
||||||
"General" from the left hand side.
|
|
||||||
Choose the "Installed plug-ins" tab, scroll down to "Poky SDK" and
|
|
||||||
check the box.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
The plug-in is now activated but not configured.
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
<section id="configuring-the-anjuta-plugin">
|
|
||||||
<title>Configuring the Anjuta Plug-in</title>
|
|
||||||
<para>
|
|
||||||
You can find the configuration options for the SDK by choosing the Poky
|
|
||||||
SDK icon from the left hand side.
|
|
||||||
You need to define the following options:
|
|
||||||
<itemizedlist>
|
|
||||||
<listitem><para>SDK root: If you use an external toolchain you need to set
|
|
||||||
SDK root, which is the root directory of the SDK's sysroot.
|
|
||||||
For an i586 SDK directory is <filename>/opt/poky/</filename>.
|
|
||||||
This directory will contain "bin", "include", "var" and so forth under your
|
|
||||||
selected target architecture subdirectory
|
|
||||||
<filename>/opt/poky/sysroot/i586-poky-linux/</filename>.
|
|
||||||
The cross-compile tools you need are in
|
|
||||||
<filename>/opt/poky/sysroot/i586-pokysdk-linux/</filename>.</para></listitem>
|
|
||||||
<listitem><para>Poky root: If you have a local Poky build tree, you need to
|
|
||||||
set the Poky root, which is the root directory of the poky build tree.
|
|
||||||
If you build your i586 target architecture under the subdirectory of
|
|
||||||
<filename>build_x86</filename> within your Poky tree, the Poky root directory
|
|
||||||
should be <filename>$<poky_tree>/build_x86/</filename>.</para></listitem>
|
|
||||||
<listitem><para>Target Architecture: This is the cross compile triplet,
|
|
||||||
for example, "i586-poky-linux".
|
|
||||||
This target triplet is the prefix extracted from the set up script file's name.
|
|
||||||
For example, if the script file name is
|
|
||||||
<filename>/opt/poky/environment-setup-i586-poky-linux</filename> then the extracted target
|
|
||||||
triplet is "i586-poky-linux".</para></listitem>
|
|
||||||
<listitem><para>Kernel: Use the file chooser to select the kernel used with QEMU.</para></listitem>
|
|
||||||
<listitem><para>Root filesystem: Use the file chooser to select the root
|
|
||||||
filesystem directory. This directory is where you use "runqemu-extract-sdk" to extract the
|
|
||||||
core-image-sdk tarball.</para></listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
<section id="using-the-anjuta-plug-in">
|
|
||||||
<title>Using the Anjuta Plug-in</title>
|
|
||||||
<para>
|
|
||||||
The steps in this section show how to cross-compile a project, deploy it into
|
|
||||||
QEMU, run a debugger against it and then perform a system-wide profile.
|
|
||||||
<orderedlist>
|
|
||||||
<listitem><para>Choose "Build -> Run Configure" or "Build -> Run Autogenerate" to run
|
|
||||||
"configure" or "autogen", respectively for the project.
|
|
||||||
Either command passes command-line arguments to instruct the
|
|
||||||
cross-compile.</para></listitem>
|
|
||||||
<listitem><para>Choose "Build -> Build Project" to build and compile the project.
|
|
||||||
If you have previously built the project in the same tree without using
|
|
||||||
the cross-compiler you might find that your project fails to link.
|
|
||||||
If this is the case, simply select "Build -> Clean Project" to remove the
|
|
||||||
old binaries.
|
|
||||||
After you clean the project you can then try building it again.</para></listitem>
|
|
||||||
<listitem><para>Choose "Tools -> Start QEMU" to start QEMU.
|
|
||||||
After QEMU starts any error messages will appear in the message view.
|
|
||||||
Once Poky has fully booted within QEMU you can deploy the project
|
|
||||||
into it.</para></listitem>
|
|
||||||
<listitem><para>Once the project is built and you have QEMU running choose
|
|
||||||
"Tools -> Deploy" to install the package into a temporary
|
|
||||||
directory and then copy it using "rsync" over SSH into the target.
|
|
||||||
A progress bar and appropriate messages appear in the message view.</para></listitem>
|
|
||||||
<listitem><para>To debug a program installed onto the target choose
|
|
||||||
"Tools -> Debug remote".
|
|
||||||
Choosing this menu item causes prompts to appear to define the local binary
|
|
||||||
for debugging and also for the command line used to run on the target.
|
|
||||||
When you provide the command line be sure to include the full path to the to binary
|
|
||||||
installed in the target.
|
|
||||||
When the command line runs a "gdbserver" over SSH is started on the target and
|
|
||||||
an instance of "cross-gdb" starts in a local terminal.
|
|
||||||
The instance of "cross-gdb" will be preloaded to connect to the server and use the SDK root to
|
|
||||||
find symbols.
|
|
||||||
It also connects to the target and loads in various libraries as well as the
|
|
||||||
target program.
|
|
||||||
You should define any breakpoints or watchpoints at this point in the process since you might not
|
|
||||||
be able to interrupt the execution later.
|
|
||||||
To stop the debugger on the target choose "Tools -> Stop debugger".</para></listitem>
|
|
||||||
<listitem><para>It is also possible to execute a command in the target over SSH.
|
|
||||||
Doing so causes the appropriate environment to be established for execution.
|
|
||||||
To execute a command choose "Choose Tools -> Run remote".
|
|
||||||
This selection opens a terminal with the SSH command inside.</para></listitem>
|
|
||||||
<listitem><para>To perform a system-wide profile against the system running in QEMU choose
|
|
||||||
"Tools -> Profile remote".
|
|
||||||
This choice starts up "OProfileUI" with the appropriate parameters to
|
|
||||||
connect to the server running inside QEMU and also supplies the path
|
|
||||||
for debug information necessary to get a useful profile.</para></listitem>
|
|
||||||
</orderedlist>
|
|
||||||
</para>
|
|
||||||
</section>
|
|
||||||
</section>
|
|
||||||
|
|
||||||
|
|
||||||
-->
|
|
||||||
|
|
||||||
</section>
|
|
||||||
|
|
||||||
<section id="platdev-appdev-qemu">
|
<section id="platdev-appdev-qemu">
|
||||||
<title>Developing Externally in QEMU</title>
|
<title>External Development Using the QEMU Emulator</title>
|
||||||
<para>
|
<para>
|
||||||
Running Poky QEMU images is covered in the
|
Running Poky QEMU images is covered in the
|
||||||
<ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html">
|
<ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html">
|
||||||
Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
|
Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Poky's QEMU images contain a complete native toolchain. This means
|
The QEMU images shipped with the Yocto Project contain complete toolchains
|
||||||
you can develop applications within QEMU similar to the way you would in a normal system.
|
native to specific target architectures.
|
||||||
Using qemux86 on an x86 machine is fast since the
|
This support allows you to develop applications within QEMU similar to the way
|
||||||
guest and host architectures match.
|
you would using a normal host development system.
|
||||||
On the other hand, using qemuarm can be slower but gives
|
</para>
|
||||||
faithful emulation of ARM-specific issues. To speed things up, these
|
|
||||||
images support using "distcc" to call a cross-compiler outside the
|
<para>
|
||||||
emulated system. If "runqemu" was used to start
|
Speed can be an issue depending on the target and host architecture mix.
|
||||||
QEMU, and "distccd" is present on the host system, any Bitbake cross-compiling
|
For example, using the <filename>qemux86</filename> image in the emulator
|
||||||
toolchain available from the build system is automatically
|
on an Intel-based 32-bit (x86) host machine is fast because the target and
|
||||||
used from within QEMU simply by calling "distcc". You can accomplish this by defining the
|
host architectures match.
|
||||||
cross-compiler variable (e.g. <filename>export CC="distcc"</filename>).
|
On the other hand, using the <filename>qemuarm</filename> image on the same Intel-based
|
||||||
Alternatively, if a suitable SDK/toolchain is present in
|
host can be slower.
|
||||||
<filename>/opt/poky</filename> it is also
|
But, you still achieve faithful emulation of ARM-specific issues.
|
||||||
automatically be used.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
There are several options for connecting into the emulated system.
|
To speed things up, the QEMU images support using <filename>distcc</filename>
|
||||||
QEMU provides a framebuffer interface that has standard consoles
|
to call a cross-compiler outside the emulated system.
|
||||||
available. There is also a serial connection available that has a
|
If you used <filename>runqemu</filename> to start QEMU, and
|
||||||
console to the system running on it and uses standard IP networking.
|
<filename>distccd</filename> is present on the host system, any BitBake cross-compiling
|
||||||
The images have a dropbear ssh server running with the root password
|
toolchain available from the build system is automatically
|
||||||
disabled to allow standard ssh and scp commands to work. The images
|
used from within QEMU simply by calling <filename>distcc</filename>.
|
||||||
also contain an NFS server that exports the guest's root filesystem, which
|
You can accomplish this by defining the cross-compiler variable
|
||||||
allows it to be made available to the host.
|
(e.g. <filename>export CC="distcc"</filename>).
|
||||||
|
Alternatively, if a suitable SDK/toolchain is present in
|
||||||
|
<filename>/opt/poky</filename> the toolchain is also automatically used.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Several mechanisms exist that let you connect into the system running on the
|
||||||
|
QEMU emulator:
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem><para>QEMU provides a framebuffer interface that makes standard
|
||||||
|
consoles available.</para></listitem>
|
||||||
|
<listitem><para>Generally, headless embedded devices have a serial port.
|
||||||
|
If so, you can configure the operating system of the running image
|
||||||
|
to use that port to run a console.
|
||||||
|
The connection uses standard IP networking.</para></listitem>
|
||||||
|
<listitem><para>The QEMU images have a Dropbear secure shell (ssh) server
|
||||||
|
that runs with the root password disabled.
|
||||||
|
This allows you to use standard <filename>ssh</filename> and
|
||||||
|
<filename>scp</filename> commands.</para></listitem>
|
||||||
|
<listitem><para>The QEMU images also contain an embedded Network Files
|
||||||
|
System (NFS) server that exports the image's root filesystem.
|
||||||
|
This allows you to make the filesystem available to the
|
||||||
|
host.</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id="platdev-appdev-insitu">
|
<section id="platdev-appdev-insitu">
|
||||||
<title>Developing in Poky Directly</title>
|
<title>Development Using Yocto Project Directly</title>
|
||||||
<para>
|
<para>
|
||||||
Working directly in Poky is a fast and effective development technique.
|
Working directly with the Yocto Project is a fast and effective development technique.
|
||||||
The idea is that you can directly edit files in
|
The idea is that you can directly edit files in a working directory
|
||||||
<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>
|
(<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>)
|
||||||
or the source directory <glossterm><link linkend='var-S'>S</link></glossterm>
|
or the source directory (<glossterm><link linkend='var-S'>S</link></glossterm>)
|
||||||
and then force specific tasks to rerun in order to test the changes.
|
and then force specific tasks to rerun in order to test the changes.
|
||||||
An example session working on the matchbox-desktop package might
|
An example session working on the matchbox-desktop package might
|
||||||
look like this:
|
look like this:
|
||||||
|
@ -505,6 +175,11 @@
|
||||||
$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
|
$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
|
||||||
$ cd matchbox-desktop-2
|
$ cd matchbox-desktop-2
|
||||||
$ vi src/main.c
|
$ vi src/main.c
|
||||||
|
.
|
||||||
|
.
|
||||||
|
[Make your changes]
|
||||||
|
.
|
||||||
|
.
|
||||||
$ exit
|
$ exit
|
||||||
$ bitbake matchbox-desktop -c compile -f
|
$ bitbake matchbox-desktop -c compile -f
|
||||||
$ bitbake matchbox-desktop
|
$ bitbake matchbox-desktop
|
||||||
|
@ -512,34 +187,56 @@
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This example builds the package, changes into the work directory for the package,
|
This example builds the <filename>matchbox-desktop</filename> package,
|
||||||
changes a file, then recompiles the package. Instead of using "sh" as it is in the example,
|
creates a new terminal, changes into the work directory for the package,
|
||||||
you can also use two different terminals. However, the risk of using two terminals
|
changes a file, exits out of the terminal, and then recompiles the
|
||||||
is that a command like "unpack" could destroy the changes you've made to the
|
package.
|
||||||
work directory. Consequently, you need to work carefully.
|
Instead of using <filename>sh</filename>,
|
||||||
|
you can also use two different terminals.
|
||||||
|
However, the risk of using two terminals is that a command like
|
||||||
|
<filename>unpack</filename> could destroy your changes in the
|
||||||
|
work directory.
|
||||||
|
Consequently, you need to work carefully.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It is useful when making changes directly to the work directory files to do
|
It is useful when making changes directly to the work directory files to do
|
||||||
so using "quilt" as detailed in the <link linkend='usingpoky-modifying-packages-quilt'>
|
so using the Quilt tool as detailed in the
|
||||||
modifying packages with quilt</link> section. You can copy the resulting patches
|
<link linkend='usingpoky-modifying-packages-quilt'>
|
||||||
into the recipe directory and use them directly in the <glossterm><link
|
Modifying Package Source Code with Quilt</link> section.
|
||||||
linkend='var-SRC_URI'>SRC_URI</link></glossterm>.
|
Using Quilt, you can copy patches into the recipe directory and use the patches directly
|
||||||
|
through use of the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
For a review of the skills used in this section see the <link
|
For a review of the skills used in this section, see the
|
||||||
linkend="usingpoky-components-bitbake">Bitbake</link> and <link
|
<link linkend="usingpoky-components-bitbake">BitBake</link> and
|
||||||
linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> Sections.
|
<link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> sections
|
||||||
|
in this manual.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id="platdev-appdev-devshell">
|
<section id="platdev-appdev-devshell">
|
||||||
<title>Developing with 'devshell'</title>
|
<title>Development Within a Development Shell</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
When debugging certain commands or even when just editing packages, the
|
When debugging certain commands or even when just editing packages,
|
||||||
'devshell' can be a useful tool.
|
<filename>devshell</filename> can be a useful tool.
|
||||||
Use a command like the following to start this tool.
|
Using <filename>devshell</filename> differs from the example shown in the previous
|
||||||
|
section in that when you invoke <filename>devshell</filename> 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 Yocto Project build-related environment variables are
|
||||||
|
still defined so you can use commands such as <filename>configure</filename> and
|
||||||
|
<filename>make</filename>.
|
||||||
|
The commands execute just as if the Yocto Project build system were executing them.
|
||||||
|
Consequently, workng this way can be helpful when debugging a build or preparing
|
||||||
|
software to be used with the Yocto Project build system.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Following is an example that uses <filename>devshell</filename> on a target named
|
||||||
|
<filename>matchbox-desktop</filename>:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
@ -550,62 +247,77 @@
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This command opens a terminal with a shell prompt within the Poky
|
This command opens a terminal with a shell prompt within the Poky
|
||||||
environment. Consequently, the following occurs:
|
environment.
|
||||||
|
The following occurs:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para>The PATH variable includes the cross toolchain.</para></listitem>
|
<listitem><para>The <filename>PATH</filename> variable includes the
|
||||||
<listitem><para>The pkgconfig variables find the correct <filename>.pc</filename> files.</para></listitem>
|
cross-toolchain.</para></listitem>
|
||||||
<listitem><para>"configure" finds the Poky site files as well as any other necessary files.</para></listitem>
|
<listitem><para>The <filename>pkgconfig</filename> variables find the correct
|
||||||
|
<filename>.pc</filename> files.</para></listitem>
|
||||||
|
<listitem><para>The <filename>configure</filename> command finds the
|
||||||
|
Yocto Project site files as well as any other necessary files.</para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
Within this environment, you can run "configure" or "compile" commands as if they
|
Within this environment, you can run <filename>configure</filename>
|
||||||
were being run by Poky itself.
|
or <filename>compile</filename> commands as if they were being run by
|
||||||
The working directory also automatically changes to the (<glossterm><link linkend='var-S'>S</link></glossterm>)
|
the Yocto Project build system itself.
|
||||||
directory.
|
As noted earlier, the working directory also automatically changes to the
|
||||||
|
source directory (<glossterm><link linkend='var-S'>S</link></glossterm>).
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
When you are finished, you just exit the shell or close the terminal window.
|
When you are finished, you just exit the shell or close the terminal window.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The default shell used by "devshell" is the gnome-terminal.
|
The default shell used by <filename>devshell</filename> is the GNOME Terminal.
|
||||||
You can use other forms of terminal can by setting the <glossterm>
|
You can use other terminal forms by setting the
|
||||||
<link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and <glossterm>
|
<glossterm><link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and
|
||||||
<link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables
|
<glossterm><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables
|
||||||
in <filename>local.conf</filename>.
|
in the Yocto Project's <filename>local.conf</filename> file found in the build
|
||||||
For examples of the other options available, see
|
directory.
|
||||||
<filename>meta/conf/bitbake.conf</filename>.
|
For examples of the other options available, see the "UI/Interaction Configuration"
|
||||||
</para>
|
section of the
|
||||||
<para>
|
<filename>meta/conf/bitbake.conf</filename> configuration file in the Yocto Project
|
||||||
An external shell is launched rather than opening directly into the original terminal
|
files.
|
||||||
window.
|
|
||||||
This allows easier interaction with Bitbake's multiple threads as well as
|
|
||||||
for a future client/server split.
|
|
||||||
Note that "devshell" will still work over X11 forwarding or similar situations.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
It is worth remembering that inside "devshell" you need to use the full
|
Because an external shell is launched rather than opening directly into the
|
||||||
compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
|
original terminal window, it allows easier interaction with Bitbake's multiple
|
||||||
instead of just <filename>gcc</filename>.
|
threads as well as accomodates a future client/server split.
|
||||||
The same applies to other applications such as gcc, bintuils, libtool and so forth.
|
|
||||||
Poky will have setup environmental variables such as CC to assist applications, such as make,
|
|
||||||
find the correct tools.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<note>
|
||||||
|
<para>It is worth remembering that when using <filename>devshell</filename>
|
||||||
|
you need to use the full compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
|
||||||
|
instead of just using <filename>gcc</filename>.
|
||||||
|
The same applies to other applications such as <filename>bintuils</filename>,
|
||||||
|
<filename>libtool</filename> and so forth.
|
||||||
|
The Yocto Project has setup environment variables such as <filename>CC</filename>
|
||||||
|
to assist applications, such as <filename>make</filename> to find the correct tools.</para>
|
||||||
|
<para>It is also worth noting that <filename>devshell</filename> still works over
|
||||||
|
X11 forwarding and similar situations</para>
|
||||||
|
</note>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id="platdev-appdev-srcrev">
|
<section id="platdev-appdev-srcrev">
|
||||||
<title>Developing within Poky with an External SCM-based Package</title>
|
<title>Development Within Yocto Project for a Package that Uses an External SCM</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If you're working on a recipe that pulls from an external SCM it
|
If you're working on a recipe that pulls from an external Source Code Manager (SCM), it
|
||||||
is possible to have Poky notice new changes added to the
|
is possible to have the Yocto Project build system notice new changes added to the
|
||||||
SCM and then build the latest version using them.
|
SCM and then build the package that depends on them using the latest version.
|
||||||
This only works for SCMs from which it is possible to get a sensible revision number for changes.
|
This only works for SCMs from which it is possible to get a sensible revision number for changes.
|
||||||
Currently it works for svn, git and bzr repositories.
|
Currently, you can do this with Apache Subversion (SVN), Git, and Bazaar (BZR) repositories.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To enable this behavior simply add <glossterm>
|
To enable this behavior, simply add the following to the <filename>local.conf</filename>
|
||||||
<link linkend='var-SRCREV'>SRCREV</link></glossterm>_pn-<glossterm>
|
configuration file in the build directory of the Yocto Project files:
|
||||||
<link linkend='var-PN'>PN</link></glossterm> = "${AUTOREV}" to
|
<literallayout class='monospaced'>
|
||||||
<filename>local.conf</filename>, where <glossterm><link linkend='var-PN'>PN</link></glossterm>
|
SRCREV_pn-<PN> = "${AUTOREV}"
|
||||||
|
</literallayout>
|
||||||
|
where <filename>PN</filename>
|
||||||
is the name of the package for which you want to enable automatic source
|
is the name of the package for which you want to enable automatic source
|
||||||
revision updating.
|
revision updating.
|
||||||
</para>
|
</para>
|
||||||
|
|
Loading…
Reference in New Issue