Poky Reference Manual: General edits up to the "Debugging with GDB Remotely" section.
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
175be120f3
commit
62f93ac42d
|
|
@ -14,22 +14,26 @@
|
|||
<section id="platdev-appdev-external-sdk">
|
||||
<title>External Development Using the Poky SDK</title>
|
||||
<para>
|
||||
The meta-toolchain and meta-toolchain-sdk targets (<link linkend='ref-images'>see
|
||||
the images section</link>) build tarballs that contain toolchains and
|
||||
libraries suitable for application development outside of Poky. These tarballs
|
||||
unpack into the
|
||||
The meta-toolchain and meta-toolchain-sdk targets build tarballs that contain toolchains and
|
||||
libraries suitable for application development outside of Poky.
|
||||
For information on these targets see the <ulink linkend='ref-images'>Reference: Images</ulink>
|
||||
appendix.
|
||||
</para>
|
||||
<para>
|
||||
These tarballs unpack into the
|
||||
<filename class="directory">/opt/poky</filename> directory and contain
|
||||
a setup script (e.g.
|
||||
<filename>/opt/poky/environment-setup-i586-poky-linux</filename>, which
|
||||
you can source to initialize a suitable environment. Sourcing these adds the
|
||||
<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 set so that, for example, configure can find pre-generated test
|
||||
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 as in the following example:
|
||||
appropriate host option to configure.
|
||||
Following is an example:
|
||||
<literallayout class='monospaced'>
|
||||
$ ./configure --host=arm-poky-linux-gnueabi
|
||||
</literallayout>
|
||||
|
|
@ -47,7 +51,7 @@
|
|||
easier for the application developer. The plug-ins provide capability
|
||||
extensions to the graphical IDE allowing for cross compilation,
|
||||
deployment and execution of the output in a QEMU emulation session.
|
||||
Support of these plug-ins also supports cross debugging and
|
||||
Support of these plug-ins also allows for cross debugging and
|
||||
profiling. Additionally, the Eclipse plug-in provides a suite of tools
|
||||
that allows the developer to perform remote profiling, tracing, collection of
|
||||
power data, collection of latency data and collection of performance data.
|
||||
|
|
@ -57,13 +61,13 @@
|
|||
<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).
|
||||
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 http://yocto./download (real link needed).
|
||||
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
|
||||
|
|
@ -74,23 +78,25 @@
|
|||
<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) on your system you need to
|
||||
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>
|
||||
<para>
|
||||
NOTE: Due to the Java Virtual Machine's garbage collection (GC) process the
|
||||
permanent generation space (PermGen) is not cleaned up. This space is used
|
||||
to store meta-data descriptions of classes. The default value is set too small
|
||||
and it could trigger an out of memory error like the following:
|
||||
<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>
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
To fix this issue you can use the <command>-vmargs</command>
|
||||
To fix this issue you can use the <filename>-vmargs</filename>
|
||||
option when you start Eclipse to increase the size of the permenant generation space:
|
||||
<literallayout class='monospaced'>
|
||||
Eclipse -vmargs -XX:PermSize=256M
|
||||
|
|
@ -101,149 +107,173 @@
|
|||
<section id="installing-the-yocto-plug-in">
|
||||
<title>Installing the Yocto Plug-in</title>
|
||||
<para>
|
||||
Once you have the Eclipse IDE installed and configure you need to install the
|
||||
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:
|
||||
<itemizedlist>
|
||||
<orderedlist>
|
||||
<listitem>Select the "Help -> Install New Software" item.</listitem>
|
||||
<listitem>In the "Work with:" area click "Add..." and enter the URL for
|
||||
the Yocto plug-in (we need to supply this URL).</listitem>
|
||||
the Yocto plug-in, which is
|
||||
<ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink></listitem>
|
||||
<listitem>Finish out the installation of the update similar to any other
|
||||
Eclipse plug-in.</listitem>
|
||||
</itemizedlist>
|
||||
</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 then the
|
||||
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 selecting "Yocto SDK".
|
||||
from the "Window" menu and then select "Yocto SDK".
|
||||
</para>
|
||||
<para>
|
||||
If you normally will use an installed Yocto
|
||||
SDK (under /opt/poky) select “SDK Root Mode”. Otherwise, if your crosstool chain
|
||||
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 will need to provide your poky tree path, for
|
||||
example, $<Poky_tree>/build/.
|
||||
If you are in SDK Root Mode you need to provide your poky tree path, for
|
||||
example, <filename>$<Poky_tree>/build/</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Now you need to select the architecture.
|
||||
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 HW. 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, Please refer to QEMU
|
||||
section for how to set it up. (Section TBD)
|
||||
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>
|
||||
Save all your settings and they become your defaults for every new Yocto project
|
||||
created using the Eclipse IDE.
|
||||
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 autotools
|
||||
based project, deploy it into QEMU, and then run the debugger against it.
|
||||
You need to configure the project, trigger <command> autogen.sh</command>, build
|
||||
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>Creating a Yocto Autotools Based Project Using a Template:
|
||||
Get to the Wizard selection by selecting the File -> New -> Project
|
||||
menu. Expand "C/C++" and select "C Project". Click "Next" and select a template
|
||||
to start with, for example "Hello World ANSI C Project". Complete the steps
|
||||
to create a new Yocto autotools based project using this template.</listitem>
|
||||
<listitem>Specify Specific Toolchain Configurations: 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
|
||||
Project -> Invoke Yocto Tools -> Reconfigure Yocto. Use this dialogue
|
||||
to specify specific toolchain and QEMU setups for the project.</listitem>
|
||||
<listitem>Building the Project: Trigger <command>autogen.sh</command> through
|
||||
Project -> Reconfigure Project. Then build the project using
|
||||
Project -> Build.</listitem>
|
||||
<listitem>Starting QEMU: Use the Run -> External Tools menu and see if there is
|
||||
a QEMU instance for the desired target. If there is click on the instance
|
||||
to start QEMU. If your target is not there then click "External Tools
|
||||
Configuration". You should find an instance of QEMU for your architecture
|
||||
under the entry under "Program". After the boot completes you are ready to
|
||||
deploy the image into QEMU.</listitem>
|
||||
<listitem>Debugging: To bring up your remote debugging configuration in the
|
||||
right-hand window highlight your project in “Project Explorer”, select
|
||||
the Run -> Debug Configurations menu item and expand “C/C++ Remote Application”.
|
||||
Next, select projectname_ gdb_target-poky-linux.
|
||||
You need to be sure that there is an
|
||||
entry for the remote target you want to deploy and cross debug with. If there
|
||||
is no entry then click "New..." to bring up the wizard. Using the wizard
|
||||
select TCF and enter the IP address of you remote target in the
|
||||
“Host name:” field. Back in the remote debug configure window,
|
||||
you need to specify the absolute path for the program on the remote target
|
||||
in the “Remote Absolute File Path for C/C++ Application” field. By default,
|
||||
the program deploys into the remote target. If you don't want this then check
|
||||
“Skip download to target path”. Finally, click "Debug” to start the remote
|
||||
debugging session.</listitem>
|
||||
<listitem>Select "File -> New -> Project" to start the wizard.</listitem>
|
||||
<listitem>Expand "C/C++" and select "C Project".</listitem>
|
||||
<listitem>Click "Next" and select a template (e.g. "Hello World ANSI C Project").</listitem>
|
||||
<listitem>Complete the steps to create the new Yocto autotools-based project using
|
||||
your chosen template.</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>Select the "Project -> Invoke Yocto Tools -> Reconfigure Yocto" menu item.</listitem>
|
||||
<listitem>Complete the dialogue to specify the specific toolchain and QEMU setup information.</listitem>
|
||||
</orderedlist>
|
||||
<para>
|
||||
To build the project follow these steps:
|
||||
</para>
|
||||
<orderedlist>
|
||||
<listitem>Select "Project -> Reconfigure Project" to trigger the
|
||||
<filename>autogen.sh</filename> command.</listitem>
|
||||
<listitem>Select "Project -> Build" to build the project.</listitem>
|
||||
</orderedlist>
|
||||
<para>
|
||||
To start QEMU follow these steps:
|
||||
</para>
|
||||
<orderedlist>
|
||||
<listitem>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".</listitem>
|
||||
<listitem>Wait for the boot to complete.</listitem>
|
||||
</orderedlist>
|
||||
<para>
|
||||
To deploy your project and start debugging follow these steps:
|
||||
</para>
|
||||
<orderedlist>
|
||||
<listitem>Highlight your project in the project explorer.</listitem>
|
||||
<listitem>Select "Run -> Debug Configurations" to bring up your remote debugging configuration
|
||||
in the right-hand window.</listitem>
|
||||
<listitem>Expand “C/C++ Remote Application”.</listitem>
|
||||
<listitem>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”.</listitem>
|
||||
<listitem>Click "Debug” to start the remote debugging session.</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 let you do things like perform system profiling, kernel tracing,
|
||||
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.
|
||||
"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 have to select an existing TCF-based
|
||||
RSE connection to the remote target. If one does not exist you need to create one
|
||||
by clicking "New"
|
||||
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>Oprofile: Selecting this tool causes the oprofile-server on the remote
|
||||
target to launch on the local host machine. To use the oprofile the oprofile-viewer
|
||||
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.</listitem>
|
||||
<listitem>lttng: Selecting this tool runs ustrace on the remote target, transfers
|
||||
the output data back to the local host machine and uses lttv-gui to graphically
|
||||
display the output. To use this tool the lttv-gui must be installed on the
|
||||
local host machine. See <ulink url="http://lttng.org/files/ust/manual/ust.html">
|
||||
</ulink> for information on how to use <command>lttng</command> to trace an
|
||||
application.
|
||||
installed on the remote target, respectively, in order to use .</listitem>
|
||||
<listitem>lttng: Selecting this tool runs "ustrace" 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 to the application to
|
||||
be traced by user mode lttng. For example, typing <command>/path/to/foo"
|
||||
</command> triggers <command>usttrace /path/to/foo</command> on the
|
||||
remote target to trace the program <command>/path/to/foo</command>.
|
||||
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>
|
||||
</listitem>
|
||||
<listitem>powertop: Selecting this tool runs <command>powertop</command> on the
|
||||
remote target machine and displays the result in a new view called "powertop".
|
||||
<listitem>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 <command>-p</command>
|
||||
argument passed to <command>powertop</command>
|
||||
"show pids in wakeups list:" corresponds to the <filename>-p</filename>
|
||||
argument passed to "powertop".
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>latencytop and perf: The <command>latencytop</command> identifies
|
||||
system latency, while <command>perf</command> monitors the system's performance
|
||||
<listitem>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 in which you can run the tools. Both tools refresh the
|
||||
terminal view to appear from which you can run the tools. Both tools refresh the
|
||||
entire screen to display results while they run.</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
|
@ -252,25 +282,24 @@
|
|||
|
||||
<section id="the-anjuta-plug-in">
|
||||
<title>The Anjuta Plug-in</title>
|
||||
<para>
|
||||
<emphasis>Note:</emphasis> We will stop Anjuta plug-in support after
|
||||
Yocto project 0.9 release. Its source
|
||||
code can be downloaded from git respository listed below, and free for the community to
|
||||
continue supporting it moving forward.
|
||||
</para>
|
||||
<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 plugin exists to make developing software within the Poky framework
|
||||
easier for the application developer.
|
||||
It presents a graphical IDE with which you can cross compile an application
|
||||
then deploy and execute the output in a
|
||||
QEMU emulation session.
|
||||
It also supports cross debugging and profiling.
|
||||
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 plugin, a toolchain and SDK built by Poky is required,
|
||||
Anjuta, it's development headers and the Anjuta plugin.
|
||||
The Poky Anjuta plugin is available to download as a tarball at the
|
||||
OpenedHand
|
||||
To use the plugin, a toolchain and SDK built by Poky, Anjuta, it's 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
|
||||
<ulink url="git://git.pokylinux.org/anjuta-poky"></ulink>.
|
||||
|
|
@ -279,10 +308,9 @@
|
|||
</para>
|
||||
<para>
|
||||
See the README file contained in the project for more information on
|
||||
Anjuta dependencies and building the plugin.
|
||||
If you want to disable remote gdb debugging,
|
||||
please pass the <command>--diable-gdb-integration</command> switch when doing
|
||||
configure.
|
||||
Anjuta dependencies and building the plug-in.
|
||||
If you want to disable remote gdb debugging, pass the "--diable-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>
|
||||
|
|
@ -290,18 +318,17 @@
|
|||
Follow these steps to set up the plug-in:
|
||||
<orderedlist>
|
||||
<listitem>Extract the tarball for the toolchain into / as root.
|
||||
The toolchain will be installed into <command>/opt/poky</command>.</listitem>
|
||||
The toolchain will be installed into <filename>/opt/poky</filename>.</listitem>
|
||||
<listitem>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 uses glade for the UI.</listitem>
|
||||
<listitem>To activate the plug-in go to Edit -> Preferences, then choose
|
||||
General from the left hand side.
|
||||
Choose the Installed plug-ins tab, scroll down to Poky SDK and
|
||||
However, you should be aware that this type uses "glade" for the UI.</listitem>
|
||||
<listitem>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.</listitem>
|
||||
</orderedlist>
|
||||
The plug-in is now activated but not configured.
|
||||
See the next section to learn how to configure it.
|
||||
</para>
|
||||
</section>
|
||||
<section id="configuring-the-anjuta-plugin">
|
||||
|
|
@ -309,89 +336,82 @@
|
|||
<para>
|
||||
You can find the configuration options for the SDK by choosing the Poky
|
||||
SDK icon from the left hand side.
|
||||
You need to set the following options:
|
||||
You need to define the following options:
|
||||
<itemizedlist>
|
||||
<listitem>SDK root: If you use an external toolchain you need to set
|
||||
SDK root. This is the root directory of the
|
||||
SDK's sysroot.
|
||||
For an i586 SDK this will be <command>/opt/poky/</command>.
|
||||
This directory will contain <command>bin</command>, <command>include
|
||||
</command>, <command>var</command> and so forth under your
|
||||
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
|
||||
<command>/opt/poky/sysroot/i586-poky-linux/</command>.
|
||||
The cross comple tools you need are in
|
||||
<command>/opt/poky/sysroot/i586-pokysdk-linux/</command>.</listitem>
|
||||
<listitem>Poky root: If you have a local poky build tree, you need to
|
||||
set the Poky root.
|
||||
This is the root directory of the poky build tree.
|
||||
<filename>/opt/poky/sysroot/i586-poky-linux/</filename>.
|
||||
The cross-compile tools you need are in
|
||||
<filename>/opt/poky/sysroot/i586-pokysdk-linux/</filename>.</listitem>
|
||||
<listitem>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
|
||||
<command>build_x86</command> within your poky tree, the Poky root directory
|
||||
should be <command>$<poky_tree>/build_x86/</command>.</listitem>
|
||||
<filename>build_x86</filename> within your Poky tree, the Poky root directory
|
||||
should be <filename>$<poky_tree>/build_x86/</filename>.</listitem>
|
||||
<listitem>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
|
||||
name.
|
||||
For example, "i586-poky-linux" is extracted from the
|
||||
set up script file
|
||||
<command>/opt/poky/environment-setup-i586-poky-linux</command>.</listitem>
|
||||
<listitem>Kernel: Use the file chooser to select the kernel to use
|
||||
with QEMU.</listitem>
|
||||
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".</listitem>
|
||||
<listitem>Kernel: Use the file chooser to select the kernel used with QEMU.</listitem>
|
||||
<listitem>Root filesystem: Use the file chooser to select the root
|
||||
filesystem directory. This directory is where you use the
|
||||
<command>poky-extract-sdk</command> to extract the poky-image-sdk
|
||||
tarball.</listitem>
|
||||
filesystem directory. This directory is where you use "poky-extract-sdk" to extract the
|
||||
poky-image-sdk tarball.</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
<section id="using-the-anjuta-plug-in">
|
||||
<title>Using the Anjuta Plug-in</title>
|
||||
<para>
|
||||
This section uses an example that cross-compiles a project, deploys it into
|
||||
QEMU, runs a debugger against it and then does a system wide profile.
|
||||
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>Choose Build -> Run Configure or Build -> Run Autogenerate to run
|
||||
"configure" or autogen, respectively for the project.
|
||||
<listitem>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.</listitem>
|
||||
<listitem>Select Build -> Build Project to build and compile the project.
|
||||
<listitem>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
|
||||
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.</listitem>
|
||||
<listitem>Start QEMU by selecting Tools -> Start QEMU. This menu selection
|
||||
starts QEMU and will show any error messages in the message view.
|
||||
Once Poky has fully booted within QEMU you can now deploy the project
|
||||
<listitem>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.</listitem>
|
||||
<listitem>Once the project is built and you have QEMU running choose
|
||||
Tools -> Deploy.
|
||||
This selection installs the package into a temporary
|
||||
directory and then copies using rsync over SSH into the target.
|
||||
Progress and messages appear in the message view.</listitem>
|
||||
"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.</listitem>
|
||||
<listitem>To debug a program installed onto the target choose
|
||||
Tools -> Debug remote.
|
||||
This selection prompts you for the local binary to debug and also the
|
||||
command line to run on the target.
|
||||
The command line to run should include the full path to the to binary
|
||||
"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.
|
||||
This will start a gdbserver over SSH on the target and also an instance
|
||||
of a cross-gdb in a local terminal.
|
||||
This will be preloaded to connect to the server and use the SDK root to
|
||||
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.
|
||||
This gdb will connect to the target and load in various libraries and the
|
||||
It also connects to the target and loads in various libraries as well as the
|
||||
target program.
|
||||
You should setup any breakpoints or watchpoints now since you might not
|
||||
You should define any breakpoints or watchpoints at this point in the process since you might not
|
||||
be able to interrupt the execution later.
|
||||
You can stop the debugger on the target using Tools -> Stop debugger.</listitem>
|
||||
<listitem>It is also possible to execute a command in the target over SSH,
|
||||
the appropriate environment will be be set for the execution.
|
||||
Choose Tools -> Run remote to do this.
|
||||
To stop the debugger on the target choose "Tools -> Stop debugger".</listitem>
|
||||
<listitem>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.</listitem>
|
||||
<listitem>To do a system wide profile against the system running in QEMU choose
|
||||
Tools -> Profile remote.
|
||||
This selection starts up OProfileUI with the appropriate parameters to
|
||||
<listitem>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
|
||||
to the debug information necessary to get a useful profile.</listitem>
|
||||
for debug information necessary to get a useful profile.</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -399,7 +419,7 @@
|
|||
</section>
|
||||
|
||||
<section id="platdev-appdev-qemu">
|
||||
<title>Developing externally in QEMU</title>
|
||||
<title>Developing Externally in QEMU</title>
|
||||
<para>
|
||||
Running Poky QEMU images is covered in the
|
||||
<ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html">
|
||||
|
|
@ -407,35 +427,36 @@
|
|||
</para>
|
||||
<para>
|
||||
Poky's QEMU images contain a complete native toolchain. This means
|
||||
that applications can be developed within QEMU in the same was as a
|
||||
normal system. Using qemux86 on an x86 machine is fast since the
|
||||
guest and host architectures match, qemuarm is slower but gives
|
||||
faithful emulation of ARM specific issues. To speed things up these
|
||||
images support using distcc to call a cross-compiler outside the
|
||||
emulated system too. If <command>runqemu</command> was used to start
|
||||
QEMU, and distccd is present on the host system, any bitbake cross
|
||||
compiling toolchain available from the build system will automatically
|
||||
be used from within qemu simply by calling distcc
|
||||
(<command>export CC="distcc"</command> can be set in the enviroment).
|
||||
you can develop applications within QEMU similar to the way you would in a normal system.
|
||||
Using qemux86 on an x86 machine is fast since the
|
||||
guest and host architectures match.
|
||||
On the other hand, using qemuarm can be slower but gives
|
||||
faithful emulation of ARM-specific issues. To speed things up, these
|
||||
images support using "distcc" to call a cross-compiler outside the
|
||||
emulated system. If "runqemu" was used to start
|
||||
QEMU, and "distccd" is present on the host system, any Bitbake cross-compiling
|
||||
toolchain available from the build system is automatically
|
||||
used from within QEMU simply by calling "distcc". You can accomplish this by defining the
|
||||
cross-compiler variable (e.g. <filename>export CC="distcc"</filename>).
|
||||
Alterntatively, if a suitable SDK/toolchain is present in
|
||||
<filename class="directory">/opt/poky</filename> it will also
|
||||
<filename>/opt/poky</filename> it is also
|
||||
automatically be used.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are several options for connecting into the emulated system.
|
||||
QEMU provides a framebuffer interface which has standard consoles
|
||||
available. There is also a serial connection available which has a
|
||||
console to the system running on it and IP networking as standard.
|
||||
QEMU provides a framebuffer interface that has standard consoles
|
||||
available. There is also a serial connection available that has a
|
||||
console to the system running on it and uses standard IP networking.
|
||||
The images have a dropbear ssh server running with the root password
|
||||
disabled allowing standard ssh and scp commands to work. The images
|
||||
also contain an NFS server exporting the guest's root filesystem
|
||||
allowing that to be made available to the host.
|
||||
disabled to allow standard ssh and scp commands to work. The images
|
||||
also contain an NFS server that exports the guest's root filesystem, which
|
||||
allows it to be made available to the host.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="platdev-appdev-insitu">
|
||||
<title>Developing in Poky directly</title>
|
||||
<title>Developing in Poky Directly</title>
|
||||
<para>
|
||||
Working directly in Poky is a fast and effective development technique.
|
||||
The idea is that you can directly edit files in
|
||||
|
|
@ -448,36 +469,36 @@
|
|||
|
||||
<para>
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake matchbox-desktop
|
||||
$ sh
|
||||
$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
|
||||
$ cd matchbox-desktop-2
|
||||
$ vi src/main.c
|
||||
$ exit
|
||||
$ bitbake matchbox-desktop -c compile -f
|
||||
$ bitbake matchbox-desktop
|
||||
</literallayout>
|
||||
$ bitbake matchbox-desktop
|
||||
$ sh
|
||||
$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
|
||||
$ cd matchbox-desktop-2
|
||||
$ vi src/main.c
|
||||
$ exit
|
||||
$ bitbake matchbox-desktop -c compile -f
|
||||
$ bitbake matchbox-desktop
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here, we build the package, change into the work directory for the package,
|
||||
change a file, then recompile the package. Instead of using sh like this,
|
||||
you can also use two different terminals. The risk with working like this
|
||||
is that a command like unpack could wipe out the changes you've made to the
|
||||
work directory so you need to work carefully.
|
||||
This example builds the package, changes into the work directory for the package,
|
||||
changes a file, then recompiles the package. Instead of using "sh" as it is in the example,
|
||||
you can also use two different terminals. However, the risk of using two terminals
|
||||
is that a command like "unpack" could destroy the changes you've made to the
|
||||
work directory. Consequently, you need to work carefully.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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'>
|
||||
modifying packages with quilt</link> section. The resulting patches can be copied
|
||||
into the recipe directory and used directly in the <glossterm><link
|
||||
so using "quilt" as detailed in the <link linkend='usingpoky-modifying-packages-quilt'>
|
||||
modifying packages with quilt</link> section. You can copy the resulting patches
|
||||
into the recipe directory and use them directly in the <glossterm><link
|
||||
linkend='var-SRC_URI'>SRC_URI</link></glossterm>.
|
||||
</para>
|
||||
<para>
|
||||
For a review of the skills used in this section see Sections <link
|
||||
linkend="usingpoky-components-bitbake">2.1.1</link> and <link
|
||||
linkend="usingpoky-debugging-taskrunning">2.4.2</link>.
|
||||
For a review of the skills used in this section see the <link
|
||||
linkend="usingpoky-components-bitbake">Bitbake</link> and <link
|
||||
linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> Sections.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
|
|
@ -485,67 +506,75 @@ $ bitbake matchbox-desktop
|
|||
<title>Developing with 'devshell'</title>
|
||||
|
||||
<para>
|
||||
When debugging certain commands or even to just edit packages, the
|
||||
'devshell' can be a useful tool. To start it you run a command like:
|
||||
When debugging certain commands or even when just editing packages, the
|
||||
'devshell' can be a useful tool.
|
||||
Use a command like the following to start this tool.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake matchbox-desktop -c devshell
|
||||
</literallayout>
|
||||
$ bitbake matchbox-desktop -c devshell
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
which will open a terminal with a shell prompt within the Poky
|
||||
environment. This means PATH is setup to include the cross toolchain,
|
||||
the pkgconfig variables are setup to find the right .pc files,
|
||||
configure will be able to find the Poky site files etc. Within this
|
||||
environment, you can run configure or compile command as if they
|
||||
were being run by Poky itself. You are also changed into the
|
||||
source (<glossterm><link linkend='var-S'>S</link></glossterm>)
|
||||
directory automatically. When finished with the shell just exit it
|
||||
or close the terminal window.
|
||||
This command opens a terminal with a shell prompt within the Poky
|
||||
environment. Consequently, the following occurs:
|
||||
<itemizedlist>
|
||||
<listitem>The PATH variable includes the cross toolchain.</listitem>
|
||||
<listitem>The pkgconfig variables find the correct <filename>.pc</filename> files.</listitem>
|
||||
<listitem>"configure" finds the Poky site files as well as any other necessary files.</listitem>
|
||||
</itemizedlist>
|
||||
Within this environment, you can run "configure" or "compile" commands as if they
|
||||
were being run by Poky itself.
|
||||
The working directory also automatically changes to the (<glossterm><link linkend='var-S'>S</link></glossterm>)
|
||||
directory.
|
||||
When you are finished, you just exit the shell or close the terminal window.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The default shell used by devshell is the gnome-terminal. Other
|
||||
forms of terminal can also be used by setting the <glossterm>
|
||||
The default shell used by "devshell" is the gnome-terminal.
|
||||
You can use other forms of terminal can by setting the <glossterm>
|
||||
<link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and <glossterm>
|
||||
<link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables
|
||||
in local.conf. For examples of the other options available, see
|
||||
<filename>meta/conf/bitbake.conf</filename>. An external shell is
|
||||
launched rather than opening directly into the original terminal
|
||||
window to make interaction with bitbakes multiple threads easier
|
||||
and also allow a client/server split of bitbake in the future
|
||||
(devshell will still work over X11 forwarding or similar).
|
||||
in <filename>local.conf</filename>.
|
||||
For examples of the other options available, see
|
||||
<filename>meta/conf/bitbake.conf</filename>.
|
||||
</para>
|
||||
<para>
|
||||
An external shell is launched rather than opening directly into the original terminal
|
||||
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>
|
||||
It is worth remembering that inside devshell you need to use the full
|
||||
compiler name such as <command>arm-poky-linux-gnueabi-gcc</command>
|
||||
instead of just <command>gcc</command> and the same applies to other
|
||||
applications from gcc, bintuils, libtool etc. Poky will have setup
|
||||
environmental variables such as CC to assist applications, such as make,
|
||||
It is worth remembering that inside "devshell" you need to use the full
|
||||
compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename>
|
||||
instead of just <filename>gcc</filename>.
|
||||
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>
|
||||
</section>
|
||||
|
||||
<section id="platdev-appdev-srcrev">
|
||||
<title>Developing within Poky with an external SCM based package</title>
|
||||
<title>Developing within Poky with an External SCM-based Package</title>
|
||||
|
||||
<para>
|
||||
If you're working on a recipe which pulls from an external SCM it
|
||||
If you're working on a recipe that pulls from an external SCM it
|
||||
is possible to have Poky notice new changes added to the
|
||||
SCM and then build the latest version. This only works for SCMs
|
||||
where its possible to get a sensible revision number for changes.
|
||||
SCM and then build the latest version using them.
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To enable this behaviour it is simply a case of adding <glossterm>
|
||||
To enable this behavior simply add <glossterm>
|
||||
<link linkend='var-SRCREV'>SRCREV</link></glossterm>_pn-<glossterm>
|
||||
<link linkend='var-PN'>PN</link></glossterm> = "${AUTOREV}" to
|
||||
local.conf where <glossterm><link linkend='var-PN'>PN</link></glossterm>
|
||||
<filename>local.conf</filename>, where <glossterm><link linkend='var-PN'>PN</link></glossterm>
|
||||
is the name of the package for which you want to enable automatic source
|
||||
revision updating.
|
||||
</para>
|
||||
|
|
|
|||
Loading…
Reference in New Issue