mirror of
https://git.yoctoproject.org/poky
synced 2026-01-29 21:08:42 +01:00
Compare commits
57 Commits
walnascar-
...
1.4_M6.rc1
| Author | SHA1 | Date | |
|---|---|---|---|
|
dab237bc6a | ||
|
|
c9442c8eea | ||
|
|
54de6b4390 | ||
|
|
f2d5900a18 | ||
|
|
d27584da67 | ||
|
|
1696043662 | ||
|
|
1336753f02 | ||
|
|
39be3e0902 | ||
|
|
5825581a9c | ||
|
|
1f083ee863 | ||
|
|
b8b3559690 | ||
|
|
eea3a1d0cc | ||
|
|
37c1ac944c | ||
|
|
1ca2e833d9 | ||
|
|
a033ef6b5f | ||
|
|
563525d621 | ||
|
|
07721a9ca5 | ||
|
|
f4ec6ca109 | ||
|
|
56eff8f76b | ||
|
|
20907b4cd8 | ||
|
|
c8e07b41da | ||
|
|
39e586db8e | ||
|
|
bd987922e6 | ||
|
|
0bf8b70c18 | ||
|
|
efac313dd8 | ||
|
|
38f2044de8 | ||
|
|
ddde2b5cca | ||
|
|
dcbd0fef40 | ||
|
|
21629e825e | ||
|
|
bc08b90fea | ||
|
|
af433229de | ||
|
|
fca52503d1 | ||
|
|
78e8bf18f8 | ||
|
|
120faaf7be | ||
|
|
c973b36249 | ||
|
|
b5d55cfe03 | ||
|
|
53623cb381 | ||
|
|
4045c3bd53 | ||
|
|
d3762f29b3 | ||
|
|
98c1f5b1ea | ||
|
|
98b7d1d6a2 | ||
|
|
194aec50c6 | ||
|
|
1de5bda888 | ||
|
|
4a20f6b23e | ||
|
|
5d3d1019eb | ||
|
|
a54046cfbf | ||
|
|
adb63ca023 | ||
|
|
b2a88072c8 | ||
|
|
01c84014a4 | ||
|
|
6619534183 | ||
|
|
e73060cf32 | ||
|
|
56a12e3f90 | ||
|
|
7dc51a7b09 | ||
|
|
4cb8950b29 | ||
|
|
013157a38a | ||
|
|
86f91a1ca2 | ||
|
|
349544d8a2 |
@@ -3868,25 +3868,51 @@
|
||||
<ulink url="http://sourceware.org/gdb/documentation/">GDB site</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The remainder of this section describes the steps you need to take
|
||||
to debug using the GNU project debugger.
|
||||
</para>
|
||||
|
||||
<section id='platdev-gdb-remotedebug-setup'>
|
||||
<title>Set Up the Cross-Development Debugging Environment</title>
|
||||
|
||||
<para>
|
||||
Before you can initiate a remote debugging session, you need
|
||||
to be sure you have set up the cross-development environment,
|
||||
toolchain, and sysroot.
|
||||
The "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-prepare'>Preparing for Application Development</ulink>"
|
||||
chapter of the Yocto Project Application Developer's Guide
|
||||
describes this process.
|
||||
Be sure you have read that chapter and have your environment
|
||||
set up.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="platdev-gdb-remotedebug-launch-gdbserver">
|
||||
<title>Launching Gdbserver on the Target</title>
|
||||
|
||||
<para>
|
||||
First, make sure Gdbserver is installed on the target.
|
||||
If it is not, install the package <filename>gdbserver</filename>, which needs the
|
||||
Make sure Gdbserver is installed on the target.
|
||||
If it is not, install the package
|
||||
<filename>gdbserver</filename>, which needs the
|
||||
<filename>libthread-db1</filename> package.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As an example, to launch Gdbserver on the target and make it ready to "debug" a
|
||||
program located at <filename>/path/to/inferior</filename>, connect
|
||||
to the target and launch:
|
||||
As an example, to launch Gdbserver on the target and make it
|
||||
ready to "debug" a binary named
|
||||
<filename>helloworld</filename>, from the host
|
||||
you need to enter a command like the following.
|
||||
This command connects to the target and launches Gdbserver
|
||||
on the target:
|
||||
<literallayout class='monospaced'>
|
||||
$ gdbserver localhost:2345 /path/to/inferior
|
||||
$ gdbserver localhost:2345 /usr/bin/helloworld
|
||||
</literallayout>
|
||||
Gdbserver should now be listening on port 2345 for debugging
|
||||
commands coming from a remote GDB process that is running on the host computer.
|
||||
Communication between Gdbserver and the host GDB are done using TCP.
|
||||
commands coming from a remote GDB process that is running on
|
||||
the host computer.
|
||||
Communication between Gdbserver and the host GDB are done
|
||||
using TCP.
|
||||
To use other communication protocols, please refer to the
|
||||
<ulink url='http://www.gnu.org/software/gdb/'>Gdbserver documentation</ulink>.
|
||||
</para>
|
||||
@@ -3903,20 +3929,24 @@
|
||||
<section id="platdev-gdb-remotedebug-launch-gdb-buildcross">
|
||||
<title>Build the Cross-GDB Package</title>
|
||||
<para>
|
||||
A suitable GDB cross-binary is required that runs on your host computer but
|
||||
also knows about the the ABI of the remote target.
|
||||
You can get this binary from the meta-toolchain.
|
||||
A suitable GDB cross-binary is required that runs on your
|
||||
host computer but also knows about the the ABI of the
|
||||
remote target.
|
||||
You can get this binary from the
|
||||
<link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
|
||||
Here is an example where the toolchain has been installed
|
||||
in the default directory <filename>/opt/poky/&DISTRO;</filename>:
|
||||
in the default directory
|
||||
<filename>/opt/poky/&DISTRO;</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
/opt/poky/1.4/sysroots/i686-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
|
||||
</literallayout>
|
||||
where <filename>arm</filename> is the target architecture and
|
||||
<filename>linux-gnueabi</filename> the target ABI.
|
||||
where <filename>arm</filename> is the target architecture
|
||||
and <filename>linux-gnueabi</filename> the target ABI.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Alternatively, you can use BitBake to build the <filename>gdb-cross</filename> binary.
|
||||
Alternatively, you can use BitBake to build the
|
||||
<filename>gdb-cross</filename> binary.
|
||||
Here is an example:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake gdb-cross
|
||||
@@ -3929,7 +3959,7 @@
|
||||
</section>
|
||||
|
||||
<section id='create-the-gdb-initialization-file'>
|
||||
<title>Create the GDB Initialization File</title>
|
||||
<title>Create the GDB Initialization File and Point to Your Root Filesystem</title>
|
||||
|
||||
<para>
|
||||
Aside from the GDB cross-binary, you also need a GDB
|
||||
@@ -3943,17 +3973,15 @@
|
||||
by maintained by
|
||||
<ulink url='http://www.sourceware.org'>sourceware.org</ulink>.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='point-to-your-root-filesystem'>
|
||||
<title>Point to Your Root Filesystem</title>
|
||||
|
||||
<para>
|
||||
Before starting your debugging session, you need to enter
|
||||
the following to set your root filesystem location
|
||||
by using a command with this form:
|
||||
You need to add a statement in the
|
||||
<filename>.gdbinit</filename> file that points to your
|
||||
root filesystem.
|
||||
Here is an example that points to the root filesystem for
|
||||
an ARM-based target device:
|
||||
<literallayout class='monospaced'>
|
||||
set sysroot <your-sysroot-path>
|
||||
set sysroot /home/jzhang/sysroot_arm
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
@@ -3962,143 +3990,67 @@
|
||||
<title>Launch the Host GDB</title>
|
||||
|
||||
<para>
|
||||
To launch the host GDB, you need to source the
|
||||
cross-debugging environment script, which if you installed
|
||||
the root filesystem in the default location is at
|
||||
<filename>/opt/poky/&DISTRO;</filename> and begins with the
|
||||
string "environment-setup".
|
||||
Before launching the host GDB, you need to be sure
|
||||
you have sourced the cross-debugging environment script,
|
||||
which if you installed the root filesystem in the default
|
||||
location is at <filename>/opt/poky/&DISTRO;</filename>
|
||||
and begins with the string "environment-setup".
|
||||
For more information, see the
|
||||
"<ulink url='&YOCTO_DOCS_ADT_URL;#setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</ulink>"
|
||||
section in the Yocto Project Application Developer's
|
||||
Guide.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, run the <filename>cross-gdb</filename> binary
|
||||
and provide the inferior binary as part of the command line.
|
||||
For example, the following command form continues with the
|
||||
example used in the previous section.
|
||||
This command form loads the <filename>foo</filename> binary
|
||||
as well as the debugging information:
|
||||
Finally, switch to the directory where the binary resides
|
||||
and run the <filename>cross-gdb</filename> binary.
|
||||
Provide the binary file you are going to debug.
|
||||
For example, the following command continues with the
|
||||
example used in the previous section by loading
|
||||
the <filename>helloworld</filename> binary as well as the
|
||||
debugging information:
|
||||
<literallayout class='monospaced'>
|
||||
$ <target-abi>-gdb rootfs/usr/bin/foo
|
||||
$ arm-poky-linux-gnuabi-gdb helloworld
|
||||
</literallayout>
|
||||
The commands in your <filename>.gdbinit</filename> execute
|
||||
and the GDB prompt appears.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<!--
|
||||
<section id="platdev-gdb-remotedebug-launch-gdb-inferiorbins">
|
||||
<title>Making the Inferior Binaries Available</title>
|
||||
<section id='platdev-gdb-connect-to-the-remote-gdb-server'>
|
||||
<title>Connect to the Remote GDB Server</title>
|
||||
|
||||
<para>
|
||||
The inferior binary (complete with all debugging symbols), as well as any
|
||||
libraries (and their debugging symbols) on which the inferior binary depends,
|
||||
needs to be available.
|
||||
There are a number of ways you can make these items available.
|
||||
</para>
|
||||
<para>
|
||||
From the target, you need to connect to the remote GDB
|
||||
server that is running on the host.
|
||||
You need to specify the remote host and port.
|
||||
Here is the command continuing with the example:
|
||||
<literallayout class='monospaced'>
|
||||
target remote 192.168.7.2:2345
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<para>
|
||||
Perhaps the easiest way is to have an SDK image that corresponds to the plain
|
||||
image installed on the device.
|
||||
In the case of <filename>core-image-sato</filename>,
|
||||
<filename>core-image-sato-sdk</filename> would contain suitable symbols.
|
||||
Because the SDK images already have the debugging symbols installed, it is just a
|
||||
question of expanding the archive to some location and then informing GDB.
|
||||
</para>
|
||||
<section id="platdev-gdb-remotedebug-launch-gdb-using">
|
||||
<title>Use the Debugger</title>
|
||||
|
||||
<para>
|
||||
Alternatively, the OpenEmbedded build system can build a custom directory of files
|
||||
for a specific
|
||||
debugging purpose by reusing its <filename>tmp/rootfs</filename> directory.
|
||||
This directory contains the contents of the last built image.
|
||||
This process assumes two things:
|
||||
<itemizedlist>
|
||||
<listitem><para>The image running on the target was the last image to
|
||||
be built.</para></listitem>
|
||||
<listitem><para>The package (<filename>foo</filename> in the following
|
||||
example) that contains the inferior binary to be debugged has been built
|
||||
without optimization and has debugging information available.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following steps show how to build the custom directory of files:
|
||||
<orderedlist>
|
||||
<listitem><para>Install the package (<filename>foo</filename> in this case) to
|
||||
<filename>tmp/rootfs</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
|
||||
tmp/work/<target-abi>/core-image-sato-1.0-r0/temp/opkg.conf -o \
|
||||
tmp/rootfs/ update
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>Install the debugging information:
|
||||
<literallayout class='monospaced'>
|
||||
$ tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
|
||||
tmp/work/<target-abi>/core-image-sato-1.0-r0/temp/opkg.conf \
|
||||
-o tmp/rootfs install foo
|
||||
|
||||
$ tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
|
||||
tmp/work/<target-abi>/core-image-sato-1.0-r0/temp/opkg.conf \
|
||||
-o tmp/rootfs install foo-dbg
|
||||
</literallayout></para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="platdev-gdb-remotedebug-launch-gdb-launchhost">
|
||||
<title>Launch the Host GDB</title>
|
||||
|
||||
<para>
|
||||
To launch the host GDB, you run the <filename>cross-gdb</filename> binary and provide
|
||||
the inferior binary as part of the command line.
|
||||
For example, the following command form continues with the example used in
|
||||
the previous section.
|
||||
This command form loads the <filename>foo</filename> binary
|
||||
as well as the debugging information:
|
||||
<literallayout class='monospaced'>
|
||||
$ <target-abi>-gdb rootfs/usr/bin/foo
|
||||
</literallayout>
|
||||
Once the GDB prompt appears, you must instruct GDB to load all the libraries
|
||||
of the inferior binary from <filename>tmp/rootfs</filename> as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ set solib-absolute-prefix /path/to/tmp/rootfs
|
||||
</literallayout>
|
||||
The pathname <filename>/path/to/tmp/rootfs</filename> must either be
|
||||
the absolute path to <filename>tmp/rootfs</filename> or the location at which
|
||||
binaries with debugging information reside.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
At this point you can have GDB connect to the Gdbserver that is running
|
||||
on the remote target by using the following command form:
|
||||
<literallayout class='monospaced'>
|
||||
$ target remote remote-target-ip-address:2345
|
||||
</literallayout>
|
||||
The <filename>remote-target-ip-address</filename> is the IP address of the
|
||||
remote target where the Gdbserver is running.
|
||||
Port 2345 is the port on which the GDBSERVER is running.
|
||||
</para>
|
||||
</section>
|
||||
-->
|
||||
|
||||
<section id="platdev-gdb-remotedebug-launch-gdb-using">
|
||||
<title>Use the Debugger</title>
|
||||
|
||||
<para>
|
||||
You can now proceed with debugging as normal - as if you were debugging
|
||||
on the local machine.
|
||||
For example, to instruct GDB to break in the "main" function and then
|
||||
continue with execution of the inferior binary use the following commands
|
||||
from within GDB:
|
||||
<literallayout class='monospaced'>
|
||||
<para>
|
||||
You can now proceed with debugging as normal - as if you were debugging
|
||||
on the local machine.
|
||||
For example, to instruct GDB to break in the "main" function and then
|
||||
continue with execution of the inferior binary use the following commands
|
||||
from within GDB:
|
||||
<literallayout class='monospaced'>
|
||||
(gdb) break main
|
||||
(gdb) continue
|
||||
</literallayout>
|
||||
</para>
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more information about using GDB, see the project's online documentation at
|
||||
<ulink url="http://sourceware.org/gdb/download/onlinedocs/"/>.
|
||||
</para>
|
||||
</section>
|
||||
<para>
|
||||
For more information about using GDB, see the project's online documentation at
|
||||
<ulink url="http://sourceware.org/gdb/download/onlinedocs/"/>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>User Application Development:</emphasis>
|
||||
User Application Development covers development of applications that you intend
|
||||
to run on some target hardware.
|
||||
to run on target hardware.
|
||||
For information on how to set up your host development system for user-space
|
||||
application development, see the
|
||||
<ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
|
||||
@@ -35,10 +35,10 @@
|
||||
<listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
|
||||
Direct modification of temporary source code is a convenient development model
|
||||
to quickly iterate and develop towards a solution.
|
||||
Once the solution has been implemented, you should of course take steps to
|
||||
Once you implement the solution, you should of course take steps to
|
||||
get the changes upstream and applied in the affected recipes.</para></listitem>
|
||||
<listitem><para><emphasis>Image Development using Hob:</emphasis>
|
||||
You can use the <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build
|
||||
You can use the <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build
|
||||
custom operating system images within the build environment.
|
||||
Hob provides an efficient interface to the OpenEmbedded build system.</para></listitem>
|
||||
<listitem><para><emphasis>Using a Development Shell:</emphasis>
|
||||
@@ -117,21 +117,22 @@
|
||||
Directory</link> available on your host system.
|
||||
Having these files on your system gives you access to the build
|
||||
process and to the tools you need.
|
||||
For information on how to set up the
|
||||
<link linkend='source-directory'>Source Directory</link>, see the
|
||||
"<link linkend='getting-setup'>Getting Set up</link>" section.</para></listitem>
|
||||
For information on how to set up the Source Directory,
|
||||
see the
|
||||
"<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
|
||||
<listitem><para><emphasis>Establish the <filename>meta-intel</filename>
|
||||
repository on your system</emphasis>: Having local copies
|
||||
of these supported BSP layers on your system gives you
|
||||
access to layers you might be able to build on or modify
|
||||
to create your BSP.
|
||||
For information on how to get these files, see the
|
||||
"<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
|
||||
"<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
|
||||
<listitem><para><emphasis>Create your own BSP layer using the
|
||||
<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>:
|
||||
Layers are ideal for
|
||||
isolating and storing work for a given piece of hardware.
|
||||
A layer is really just a location or area in which you place the recipes for your BSP.
|
||||
A layer is really just a location or area in which you place
|
||||
the recipes and configurations for your BSP.
|
||||
In fact, a BSP is, in itself, a special type of layer.
|
||||
The simplest way to create a new BSP layer that is compliant with the
|
||||
Yocto Project is to use the <filename>yocto-bsp</filename> script.
|
||||
@@ -160,11 +161,11 @@
|
||||
The recipes and configurations for these four BSPs are located and dispersed
|
||||
within the <link linkend='source-directory'>Source Directory</link>.
|
||||
On the other hand, BSP layers for Cedar Trail, Chief River, Crown Bay,
|
||||
Crystal Forest, Emenlow, Fish River, Fish River 2, Jasper Forest, N450,
|
||||
Crystal Forest, Emenlow, Fish River Island, Fish River Island 2, Jasper Forest, N450,
|
||||
Romley, sys940x, Sugar Bay, and tlk exist in their own separate layers
|
||||
within the larger <filename>meta-intel</filename> layer.</note>
|
||||
<para>When you set up a layer for a new BSP, you should follow a standard layout.
|
||||
This layout is described in the section
|
||||
This layout is described in the
|
||||
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
|
||||
section of the Board Support Package (BSP) Development Guide.
|
||||
In the standard layout, you will notice a suggested structure for recipes and
|
||||
@@ -178,7 +179,7 @@
|
||||
directories within the BSP layer.
|
||||
Configuration changes identify where your new layer is on the local system
|
||||
and identify which kernel you are going to use.
|
||||
When you run the <filename>yocto-bsp</filename> script you are able to interactively
|
||||
When you run the <filename>yocto-bsp</filename> script, you are able to interactively
|
||||
configure many things for the BSP (e.g. keyboard, touchscreen, and so forth).
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>: Recipe
|
||||
@@ -268,21 +269,15 @@
|
||||
Within this group, you will find several kernels supported by
|
||||
the Yocto Project:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The
|
||||
stable Yocto Project kernel that is based on the Linux 2.6.34 released kernel.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
|
||||
stable Yocto Project kernel that is based on the Linux 2.6.37 released kernel.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable
|
||||
Yocto Project kernel that is based on the Linux 3.0 released kernel.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The
|
||||
stable Yocto Project kernel to use with the Yocto Project Release 1.1.x. This kernel
|
||||
is based on the Linux 3.0 released kernel.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The
|
||||
stable Yocto Project kernel to use with the Yocto Project Release 1.2. This kernel
|
||||
is based on the Linux 3.2 released kernel.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.4</filename></emphasis> - The
|
||||
stable Yocto Project kernel to use with the Yocto Project Release 1.3. This kernel
|
||||
is based on the Linux 3.4 released kernel.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-3.4</filename></emphasis> - The
|
||||
stable Yocto Project kernel to use with the Yocto Project Release 1.4. This kernel
|
||||
is based on the Linux 3.8 released kernel.</para></listitem>
|
||||
<listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
|
||||
kernel based on the latest upstream release candidate available.</para></listitem>
|
||||
</itemizedlist>
|
||||
@@ -292,8 +287,8 @@
|
||||
The kernels are maintained using the Git revision control system
|
||||
that structures them using the familiar "tree", "branch", and "leaf" scheme.
|
||||
Branches represent diversions from general code to more specific code, while leaves
|
||||
represent the end-points for a complete and unique kernel whose source files
|
||||
when gathered from the root of the tree to the leaf accumulate to create the files
|
||||
represent the end-points for a complete and unique kernel whose source files,
|
||||
when gathered from the root of the tree to the leaf, accumulate to create the files
|
||||
necessary for a specific piece of hardware and its features.
|
||||
The following figure displays this concept:
|
||||
<para>
|
||||
@@ -304,12 +299,12 @@
|
||||
<para>
|
||||
Within the figure, the "Kernel.org Branch Point" represents the point in the tree
|
||||
where a supported base kernel is modified from the Linux kernel.
|
||||
For example, this could be the branch point for the <filename>linux-yocto-3.0</filename>
|
||||
For example, this could be the branch point for the <filename>linux-yocto-3.4</filename>
|
||||
kernel.
|
||||
Thus, everything further to the right in the structure is based on the
|
||||
<filename>linux-yocto-3.0</filename> kernel.
|
||||
<filename>linux-yocto-3.4</filename> kernel.
|
||||
Branch points to right in the figure represent where the
|
||||
<filename>linux-yocto-3.0</filename> kernel is modified for specific hardware
|
||||
<filename>linux-yocto-3.4</filename> kernel is modified for specific hardware
|
||||
or types of kernels, such as real-time kernels.
|
||||
Each leaf thus represents the end-point for a kernel designed to run on a specific
|
||||
targeted device.
|
||||
@@ -347,10 +342,14 @@
|
||||
ways.
|
||||
If you are working in the kernel all the time, you probably would want
|
||||
to set up your own local Git repository of the kernel tree.
|
||||
If you just need to make some patches to the kernel, you can get at
|
||||
temporary kernel source files extracted and used during the OpenEmbedded
|
||||
build system.
|
||||
If you just need to make some patches to the kernel, you can access
|
||||
temporary kernel source files that were extracted and used
|
||||
during a build.
|
||||
We will just talk about working with the temporary source code.
|
||||
For more information on how to get kernel source code onto your
|
||||
host system, see the
|
||||
"<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
|
||||
bulleted item earlier in the manual.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@@ -412,7 +411,9 @@
|
||||
"<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Establish the temporary kernel source files</emphasis>:
|
||||
Temporary kernel source files are kept in the Build Directory created by the
|
||||
Temporary kernel source files are kept in the
|
||||
<link linkend='build-directory'>Build Directory</link>
|
||||
created by the
|
||||
OpenEmbedded build system when you run BitBake.
|
||||
If you have never built the kernel you are interested in, you need to run
|
||||
an initial build to establish local kernel source files.</para>
|
||||
@@ -428,7 +429,7 @@
|
||||
You might want to reference this information.
|
||||
You can find more information on BitBake in the user manual, which is found in the
|
||||
<filename>bitbake/doc/manual</filename> directory of the
|
||||
<link linkend='source-directory'>Source Directory</link>.</para>
|
||||
Source Directory.</para>
|
||||
<para>The build process supports several types of images to satisfy different needs.
|
||||
See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
|
||||
the Yocto Project Reference Manual for information on supported images.
|
||||
@@ -447,10 +448,9 @@
|
||||
Using <filename>menuconfig</filename> allows you to interactively develop and test the
|
||||
configuration changes you are making to the kernel.
|
||||
When saved, changes using <filename>menuconfig</filename> update the kernel's
|
||||
<filename>.config</filename>.
|
||||
<filename>.config</filename> file.
|
||||
Try to resist the temptation of directly editing the <filename>.config</filename>
|
||||
file found in the
|
||||
<link linkend='build-directory'>Build Directory</link> at
|
||||
file found in the Build Directory at
|
||||
<filename>tmp/sysroots/<machine-name>/kernel</filename>.
|
||||
Doing so, can produce unexpected results when the OpenEmbedded build system
|
||||
regenerates the configuration file.</para>
|
||||
@@ -474,9 +474,11 @@
|
||||
Application development involves creating an application that you want
|
||||
to run on your target hardware, which is running a kernel image created using the
|
||||
OpenEmbedded build system.
|
||||
The Yocto Project provides an Application Development Toolkit (ADT) and
|
||||
stand-alone cross-development toolchains that
|
||||
facilitate quick development and integration of your application into its run-time environment.
|
||||
The Yocto Project provides an
|
||||
<ulink url='&YOCTO_DOCS_ADT_URL;#adt-intro-section'>Application Development Toolkit (ADT)</ulink>
|
||||
and stand-alone
|
||||
<ulink url='&YOCTO_DOCS_ADT_URL;#the-cross-development-toolchain'>cross-development toolchains</ulink>
|
||||
that facilitate quick development and integration of your application into its runtime environment.
|
||||
Using the ADT and toolchains, you can compile and link your application.
|
||||
You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
|
||||
If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE,
|
||||
@@ -511,12 +513,12 @@
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:
|
||||
<listitem><para><emphasis>Prepare the host system for the Yocto Project</emphasis>:
|
||||
See
|
||||
"<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>" and
|
||||
"<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
|
||||
in the Yocto Project Quick Start for requirements.</para></listitem>
|
||||
<listitem><para><emphasis>Secure the Yocto Project Kernel Target Image</emphasis>:
|
||||
<listitem><para><emphasis>Secure the Yocto Project kernel target image</emphasis>:
|
||||
You must have a target kernel image that has been built using the OpenEmbedded
|
||||
build system.</para>
|
||||
<para>Depending on whether the Yocto Project has a pre-built image that matches your target
|
||||
@@ -548,14 +550,14 @@
|
||||
The ADT provides a target-specific cross-development toolchain, the root filesystem,
|
||||
the QEMU emulator, and other tools that can help you develop your application.
|
||||
While it is possible to get these pieces separately, the ADT Installer provides an
|
||||
easy method.
|
||||
easy, inclusive method.
|
||||
You can get these pieces by running an ADT installer script, which is configurable.
|
||||
For information on how to install the ADT, see the
|
||||
"<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
|
||||
section
|
||||
in the Yocto Project Application Developer's Guide.</para></listitem>
|
||||
<listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem
|
||||
and the Cross-development Toolchain</emphasis>:
|
||||
<listitem><para><emphasis>If applicable, secure the target root filesystem
|
||||
and the Cross-development toolchain</emphasis>:
|
||||
If you choose not to install the ADT using the ADT Installer,
|
||||
you need to find and download the appropriate root filesystem and
|
||||
the cross-development toolchain.</para>
|
||||
@@ -563,7 +565,7 @@
|
||||
for the kernel image.
|
||||
Depending on the type of image you are running, the root filesystem you need differs.
|
||||
For example, if you are developing an application that runs on an image that
|
||||
supports Sato, you need to get root filesystem that supports Sato.</para>
|
||||
supports Sato, you need to get a root filesystem that supports Sato.</para>
|
||||
<para>You can find the cross-development toolchains at
|
||||
<ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
|
||||
Be sure to get the correct toolchain for your development host and your
|
||||
@@ -576,20 +578,20 @@
|
||||
the correct toolchain based on your host development system and your target
|
||||
architecture.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Create and Build your Application</emphasis>:
|
||||
<listitem><para><emphasis>Create and build your application</emphasis>:
|
||||
At this point, you need to have source files for your application.
|
||||
Once you have the files, you can use the Eclipse IDE to import them and build the
|
||||
project.
|
||||
If you are not using Eclipse, you need to use the cross-development tools you have
|
||||
installed to create the image.</para></listitem>
|
||||
<listitem><para><emphasis>Deploy the Image with the Application</emphasis>:
|
||||
<listitem><para><emphasis>Deploy the image with the application</emphasis>:
|
||||
If you are using the Eclipse IDE, you can deploy your image to the hardware or to
|
||||
QEMU through the project's preferences.
|
||||
If you are not using the Eclipse IDE, then you need to deploy the application
|
||||
to the hardware using other methods.
|
||||
Or, if you are using QEMU, you need to use that tool and load your image in for testing.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Test and Debug the Application</emphasis>:
|
||||
<listitem><para><emphasis>Test and debug the application</emphasis>:
|
||||
Once your application is deployed, you need to test it.
|
||||
Within the Eclipse IDE, you can use the debugging environment along with the
|
||||
set of user-space tools installed along with the ADT to debug your application.
|
||||
@@ -617,7 +619,8 @@
|
||||
Installing and configuring the Plug-in results in an environment that
|
||||
has extensions specifically designed to let you more easily develop software.
|
||||
These extensions allow for cross-compilation, deployment, and execution of
|
||||
your output into a QEMU emulation session.
|
||||
your output into a QEMU emulation session as well as actual target
|
||||
hardware.
|
||||
You can also perform cross-debugging and profiling.
|
||||
The environment also supports a suite of tools that allows you to perform
|
||||
remote profiling, tracing, collection of power data, collection of
|
||||
@@ -662,7 +665,7 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you don’t have the Juno 4.2 Eclipse IDE installed, you can find the tarball at
|
||||
If you do not have the Juno 4.2 Eclipse IDE installed, you can find the tarball at
|
||||
<ulink url='&ECLIPSE_MAIN_URL;'></ulink>.
|
||||
From that site, choose the Eclipse Classic version particular to your development
|
||||
host.
|
||||
@@ -731,7 +734,7 @@
|
||||
<listitem><para>Select <filename>Juno - &ECLIPSE_JUNO_URL;</filename>
|
||||
from the "Work with:" pull-down menu.</para></listitem>
|
||||
<listitem><para>Expand the box next to "Linux Tools" and select the
|
||||
"LTTng - Linux Tracing Toolkit" boxes.</para></listitem>
|
||||
<filename>LTTng - Linux Tracing Toolkit</filename> boxes.</para></listitem>
|
||||
<listitem><para>Expand the box next to "Mobile and Device Development" and select the
|
||||
following boxes:
|
||||
<itemizedlist>
|
||||
@@ -742,7 +745,7 @@
|
||||
<listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem>
|
||||
<listitem><para><filename>TCF Target Explorer</filename></para></listitem>
|
||||
</itemizedlist></para></listitem>
|
||||
<listitem><para>Expand the box next to <filename>Programming Languages</filename>
|
||||
<listitem><para>Expand the box next to "Programming Languages"
|
||||
and select the <filename>Autotools Support for CDT</filename>
|
||||
and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
|
||||
<listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
|
||||
@@ -770,11 +773,12 @@
|
||||
</para></listitem>
|
||||
<listitem><para>Select <filename>indigo - &ECLIPSE_INDIGO_URL;</filename>
|
||||
from the "Work with:" pull-down menu.</para></listitem>
|
||||
<listitem><para>Expand the box next to <filename>Programming Languages</filename>
|
||||
<listitem><para>Expand the box next to "Programming Languages"
|
||||
and select the <filename>Autotools Support for CDT (incubation)</filename>
|
||||
and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
|
||||
<listitem><para>Expand the box next to "Linux Tools" and select the
|
||||
"LTTng - Linux Tracing Toolkit(incubation)" boxes.</para></listitem>
|
||||
<filename>LTTng - Linux Tracing Toolkit(incubation)</filename>
|
||||
boxes.</para></listitem>
|
||||
<listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
|
||||
<listitem><para>After the Eclipse IDE restarts and from the Workbench, select
|
||||
"Install New Software" from the "Help" pull-down menu.</para></listitem>
|
||||
@@ -801,7 +805,7 @@
|
||||
from the "Work with:" pull-down menu.</para></listitem>
|
||||
<listitem><para>Check the box next to <filename>CDT Main Features</filename>.
|
||||
</para></listitem>
|
||||
<listitem><para>Expand the box next to <filename>CDT Optional Features</filename>
|
||||
<listitem><para>Expand the box next to "CDT Optional Features"
|
||||
and select <filename>C/C++ Remote Launch</filename> and
|
||||
<filename>Target Communication Framework (incubation)</filename>.</para></listitem>
|
||||
<listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
|
||||
@@ -816,7 +820,7 @@
|
||||
You can install the Eclipse Yocto Plug-in into the Eclipse IDE
|
||||
one of two ways: use the Yocto Project's Eclipse Update site to install the pre-built plug-in,
|
||||
or build and install the plug-in from the latest source code.
|
||||
If you don't want to permanently install the plug-in but just want to try it out
|
||||
If you do not want to permanently install the plug-in but just want to try it out
|
||||
within the Eclipse environment, you can import the plug-in project from the
|
||||
Yocto Project's Source Repositories.
|
||||
</para>
|
||||
@@ -889,7 +893,7 @@
|
||||
as directed.
|
||||
Be sure to provide the name of the Git branch along with the
|
||||
Yocto Project release you are using.
|
||||
Here is an example that uses the <filename>&DISTRO_NAME;</filename> branches:
|
||||
Here is an example that uses the <filename>&DISTRO_NAME;</filename> branch:
|
||||
<literallayout class='monospaced'>
|
||||
$ ECLIPSE_HOME=/home/scottrif/yocto-eclipse/scripts/eclipse ./build.sh &DISTRO_NAME; &DISTRO_NAME;
|
||||
</literallayout>
|
||||
@@ -930,6 +934,9 @@
|
||||
It is important to understand when you import the plug-in you are not installing
|
||||
it into the Eclipse application.
|
||||
Rather, you are importing the project and just using it.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To import the plug-in project, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Open a shell and create a Git repository with:
|
||||
@@ -943,16 +950,18 @@
|
||||
and then click "Next".</para></listitem>
|
||||
<listitem><para>Select the root directory and browse to
|
||||
<filename>~/yocto-eclipse/plugins</filename>.</para></listitem>
|
||||
<listitem><para>Three plug-ins exist: "org.yocto.bc.ui", "org.yocto.sdk.ide", and
|
||||
"org.yocto.sdk.remotetools".
|
||||
<listitem><para>Three plug-ins exist:
|
||||
<filename>org.yocto.bc.ui</filename>,
|
||||
<filename>org.yocto.sdk.ide</filename>, and
|
||||
<filename>org.yocto.sdk.remotetools</filename>.
|
||||
Select and import all of them.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The left navigation pane in the Eclipse application shows the default projects.
|
||||
Right-click on one of these projects and run it as an Eclipse application.
|
||||
This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
|
||||
Right-click on one of these projects and run it as an Eclipse application
|
||||
to bring up a second instance of Eclipse IDE that has the Yocto Plug-in.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@@ -971,9 +980,10 @@
|
||||
<para>
|
||||
To start, you need to do the following from within the Eclipse IDE:
|
||||
<itemizedlist>
|
||||
<listitem><para>Choose <filename>Windows -> Preferences</filename> to display
|
||||
the <filename>Preferences</filename> Dialog</para></listitem>
|
||||
<listitem><para>Click <filename>Yocto Project ADT</filename></para></listitem>
|
||||
<listitem><para>Choose "Preferences" from the
|
||||
"Windows" menu to display
|
||||
the Preferences Dialog</para></listitem>
|
||||
<listitem><para>Click "Yocto Project ADT"</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
@@ -1000,7 +1010,8 @@
|
||||
<listitem><para><emphasis>
|
||||
<filename>Build System Derived Toolchain:</filename></emphasis>
|
||||
Select this mode if the cross-toolchain has been installed and built
|
||||
as part of the Build Directory.
|
||||
as part of the
|
||||
<link linkend='build-directory'>Build Directory</link>.
|
||||
When you select <filename>Build system derived toolchain</filename>,
|
||||
you are using the toolchain bundled
|
||||
inside the Build Directory.
|
||||
@@ -1009,33 +1020,35 @@
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Point to the Toolchain:</emphasis>
|
||||
If you are using a stand-alone pre-built toolchain, you should be pointing to the
|
||||
<filename>&YOCTO_ADTPATH_DIR;</filename> directory.
|
||||
This is the location for toolchains installed by the ADT Installer or by hand.
|
||||
where it is installed.
|
||||
If you used the ADT Installer script and accepted the default
|
||||
installation directory, the toolchain will be installed in
|
||||
the <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
|
||||
Sections "<ulink url='&YOCTO_DOCS_ADT_URL;#configuring-and-running-the-adt-installer-script'>Configuring
|
||||
and Running the ADT Installer Script</ulink>" and
|
||||
"<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
|
||||
in the Yocto Project Application Developer's Guide
|
||||
describe two ways to install a stand-alone cross-toolchain in the
|
||||
<filename>/opt/poky</filename> directory.
|
||||
<note>It is possible to install a stand-alone cross-toolchain in a directory
|
||||
other than <filename>/opt/poky</filename>.
|
||||
However, doing so is discouraged.</note></para>
|
||||
describe how to install a stand-alone cross-toolchain.</para>
|
||||
<para>If you are using a system-derived toolchain, the path you provide
|
||||
for the <filename>Toolchain Root Location</filename>
|
||||
field is the Build Directory.
|
||||
field is the <link linkend='build-directory'>Build Directory</link>.
|
||||
See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using
|
||||
BitBake and the Build Directory</ulink>" section in the Yocto Project Application
|
||||
Developer's Guide for information on how to install the toolchain into the build
|
||||
directory.</para></listitem>
|
||||
Developer's Guide for information on how to install
|
||||
the toolchain into the Build Directory.</para></listitem>
|
||||
<listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
|
||||
This location is where the root filesystem for the target hardware resides.
|
||||
If you used the ADT Installer, then the location is
|
||||
If you used the ADT Installer script and accepted the
|
||||
default installation directory, then the location is
|
||||
<filename>/opt/poky/<release></filename>.
|
||||
Additionally, when you use the ADT Installer, the same location is used for
|
||||
Additionally, when you use the ADT Installer script,
|
||||
the same location is used for
|
||||
the QEMU user-space tools and the NFS boot process.</para>
|
||||
<para>If you used either of the other two methods to install the toolchain, then the
|
||||
<para>If you used either of the other two methods to
|
||||
install the toolchain or did not accept the ADT Installer
|
||||
script's default installation directory, then the
|
||||
location of the sysroot filesystem depends on where you separately
|
||||
extracted and intalled the filesystem.</para>
|
||||
extracted and installed the filesystem.</para>
|
||||
<para>For information on how to install the toolchain and on how to extract
|
||||
and install the sysroot filesystem, see the
|
||||
"<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>" section.
|
||||
@@ -1086,7 +1099,7 @@ directory.</para></listitem>
|
||||
</literallayout></para>
|
||||
<para>
|
||||
Regardless of the mode, Sysroot is already defined as part of the
|
||||
Cross Compiler Options configuration in the
|
||||
Cross-Compiler Options configuration in the
|
||||
<filename>Sysroot Location:</filename> field.</para></listitem>
|
||||
<listitem><para><emphasis><filename>External HW:</filename></emphasis> Select this option
|
||||
if you will be using actual hardware.</para></listitem>
|
||||
@@ -1094,7 +1107,7 @@ directory.</para></listitem>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Click the <filename>OK</filename> button to save your plug-in configurations.
|
||||
Click the "OK" to save your plug-in configurations.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
@@ -1116,7 +1129,7 @@ directory.</para></listitem>
|
||||
To create a project based on a Yocto template and then display the source code,
|
||||
follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Select <filename>File -> New -> Project</filename>.</para></listitem>
|
||||
<listitem><para>Select "Project" from the "File -> New" menu.</para></listitem>
|
||||
<listitem><para>Double click <filename>CC++</filename>.</para></listitem>
|
||||
<listitem><para>Double click <filename>C Project</filename> to create the project.</para></listitem>
|
||||
<listitem><para>Expand <filename>Yocto Project ADT Project</filename>.</para></listitem>
|
||||
@@ -1124,11 +1137,11 @@ directory.</para></listitem>
|
||||
This is an Autotools-based project based on a Yocto template.</para></listitem>
|
||||
<listitem><para>Put a name in the <filename>Project name:</filename> field.
|
||||
Do not use hyphens as part of the name.</para></listitem>
|
||||
<listitem><para>Click <filename>Next</filename>.</para></listitem>
|
||||
<listitem><para>Click "Next".</para></listitem>
|
||||
<listitem><para>Add information in the <filename>Author</filename> and
|
||||
<filename>Copyright notice</filename> fields.</para></listitem>
|
||||
<listitem><para>Be sure the <filename>License</filename> field is correct.</para></listitem>
|
||||
<listitem><para>Click <filename>Finish</filename>.</para></listitem>
|
||||
<listitem><para>Click "Finish".</para></listitem>
|
||||
<listitem><para>If the "open perspective" prompt appears, click "Yes" so that you
|
||||
in the C/C++ perspective.</para></listitem>
|
||||
<listitem><para>The left-hand navigation pane shows your project.
|
||||
@@ -1147,31 +1160,32 @@ directory.</para></listitem>
|
||||
configurations.
|
||||
You can override these settings for a given project by following these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Select <filename>Project -> Change Yocto Project Settings</filename>:
|
||||
This selection brings up the <filename>Yocot Project Settings</filename> Dialog
|
||||
<listitem><para>Select "Change Yocto Project Settings" from the
|
||||
"Project" menu.
|
||||
This selection brings up the Yocto Project Settings Dialog
|
||||
and allows you to make changes specific to an individual project.
|
||||
</para>
|
||||
<para>By default, the Cross Compiler Options and Target Options for a project
|
||||
are inherited from settings you provide using the <filename>Preferences</filename>
|
||||
are inherited from settings you provide using the Preferences
|
||||
Dialog as described earlier
|
||||
in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse
|
||||
Yocto Plug-in</link>" section.
|
||||
The <filename>Yocto Project Settings</filename>
|
||||
Dialog allows you to override those default settings
|
||||
for a given project.</para></listitem>
|
||||
The Yocto Project Settings Dialog allows you to override
|
||||
those default settings for a given project.</para></listitem>
|
||||
<listitem><para>Make your configurations for the project and click "OK".
|
||||
If you are running the Juno version of Eclipse, you can skip down to the next
|
||||
section where you build the project.
|
||||
If you are not working with Juno, you need to reconfigure the project as
|
||||
described in the next step.</para></listitem>
|
||||
<listitem><para>Select <filename>Project -> Reconfigure Project</filename>:
|
||||
<listitem><para>Select "Reconfigure Project" from the
|
||||
"Project" menu.
|
||||
This selection reconfigures the project by running
|
||||
<filename>autogen.sh</filename> in the workspace for your project.
|
||||
The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
|
||||
<filename>autoconf</filename>, <filename>autoheader</filename>,
|
||||
<filename>automake --a</filename>, and
|
||||
<filename>./configure</filename>.
|
||||
Click on the <filename>Console</filename> tab beneath your source code to
|
||||
Click on the "Console" tab beneath your source code to
|
||||
see the results of reconfiguring your project.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
@@ -1182,19 +1196,21 @@ directory.</para></listitem>
|
||||
|
||||
<para>
|
||||
To build the project in Juno, right click on the project in the navigator pane and select
|
||||
<filename>Build Project</filename>.
|
||||
If you are not running Juno, select <filename>Project -> Build Project</filename>.
|
||||
"Build Project".
|
||||
If you are not running Juno, select "Build Project" from the
|
||||
"Project" menu.
|
||||
The console should update and you can note the cross-compiler you are using.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='starting-qemu-in-user-space-nfs-mode'>
|
||||
<title>Starting QEMU in User Space NFS Mode</title>
|
||||
<title>Starting QEMU in User-Space NFS Mode</title>
|
||||
|
||||
<para>
|
||||
To start the QEMU emulator from within Eclipse, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Expose the <filename>Run -> External Tools</filename> menu.
|
||||
<listitem><para>Expose and select "External Tools" from
|
||||
the "Run" menu.
|
||||
Your image should appear as a selectable menu item.
|
||||
</para></listitem>
|
||||
<listitem><para>Select your image from the menu to launch the
|
||||
@@ -1216,33 +1232,36 @@ directory.</para></listitem>
|
||||
<title>Deploying and Debugging the Application</title>
|
||||
|
||||
<para>
|
||||
Once the QEMU emulator is running the image, using the Eclipse IDE
|
||||
you can deploy your application and use the emulator to perform debugging.
|
||||
Once the QEMU emulator is running the image, you can deploy
|
||||
your application using the Eclipse IDE and use then use
|
||||
the emulator to perform debugging.
|
||||
Follow these steps to deploy the application.
|
||||
<orderedlist>
|
||||
<listitem><para>Select <filename>Run -> Debug Configurations...</filename></para></listitem>
|
||||
<listitem><para>Select "Debug Configurations..." from the
|
||||
"Run" menu.</para></listitem>
|
||||
<listitem><para>In the left area, expand <filename>C/C++Remote Application</filename>.</para></listitem>
|
||||
<listitem><para>Locate your project and select it to bring up a new
|
||||
tabbed view in the <filename>Debug Configurations</filename> Dialog.</para></listitem>
|
||||
tabbed view in the Debug Configurations Dialog.</para></listitem>
|
||||
<listitem><para>Enter the absolute path into which you want to deploy
|
||||
the application.
|
||||
Use the <filename>Remote Absolute File Path for C/C++Application:</filename> field.
|
||||
Use the "Remote Absolute File Path for C/C++Application:" field.
|
||||
For example, enter <filename>/usr/bin/<programname></filename>.</para></listitem>
|
||||
<listitem><para>Click on the <filename>Debugger</filename> tab to see the cross-tool debugger
|
||||
<listitem><para>Click on the "Debugger" tab to see the cross-tool debugger
|
||||
you are using.</para></listitem>
|
||||
<listitem><para>Click on the <filename>Main</filename> tab.</para></listitem>
|
||||
<listitem><para>Click on the "Main" tab.</para></listitem>
|
||||
<listitem><para>Create a new connection to the QEMU instance
|
||||
by clicking on <filename>new</filename>.</para></listitem>
|
||||
by clicking on "new".</para></listitem>
|
||||
<listitem><para>Select <filename>TCF</filename>, which means Target Communication
|
||||
Framework.</para></listitem>
|
||||
<listitem><para>Click <filename>Next</filename>.</para></listitem>
|
||||
<listitem><para>Clear out the <filename>host name</filename> field and enter the IP Address
|
||||
<listitem><para>Click "Next".</para></listitem>
|
||||
<listitem><para>Clear out the "host name" field and enter the IP Address
|
||||
determined earlier.</para></listitem>
|
||||
<listitem><para>Click <filename>Finish</filename> to close the
|
||||
<filename>New Connections</filename> Dialog.</para></listitem>
|
||||
<listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick
|
||||
the IP Address you entered.</para></listitem>
|
||||
<listitem><para>Click <filename>Run</filename> to bring up a login screen
|
||||
<listitem><para>Click "Finish" to close the
|
||||
New Connections Dialog.</para></listitem>
|
||||
<listitem><para>Use the drop-down menu now in the
|
||||
"Connection" field and pick the IP Address you entered.
|
||||
</para></listitem>
|
||||
<listitem><para>Click "Run" to bring up a login screen
|
||||
and login.</para></listitem>
|
||||
<listitem><para>Accept the debug perspective.</para></listitem>
|
||||
</orderedlist>
|
||||
@@ -1257,14 +1276,14 @@ directory.</para></listitem>
|
||||
your development experience.
|
||||
These tools are aids in developing and debugging applications and images.
|
||||
You can run these user-space tools from within the Eclipse IDE through the
|
||||
<filename>YoctoTools</filename> menu.
|
||||
"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 <filename>New</filename> to create one.
|
||||
If one does not exist, click "New" to create one.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@@ -1279,10 +1298,10 @@ directory.</para></listitem>
|
||||
You must compile and install the <filename>oprofile-viewer</filename> from the source code
|
||||
on your local host machine.
|
||||
Furthermore, in order to convert the target's sample format data into a form that the
|
||||
host can use, you must have <filename>oprofile</filename> version 0.9.4 or
|
||||
host can use, you must have OProfile version 0.9.4 or
|
||||
greater installed on the host.</para>
|
||||
<para>You can locate both the viewer and server from
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
|
||||
You can also find more information on setting up and
|
||||
using this tool in the
|
||||
"<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
|
||||
@@ -1292,64 +1311,71 @@ directory.</para></listitem>
|
||||
<listitem><para><emphasis><filename>Lttng2.0 ust trace import</filename>:</emphasis>
|
||||
Selecting this tool transfers the remote target's
|
||||
<filename>Lttng</filename> tracing data back to the local host machine
|
||||
and uses the <filename>Lttng</filename> Eclipse plug-in to graphically
|
||||
and uses the Lttng Eclipse plug-in to graphically
|
||||
display the output.
|
||||
For information on how to use <filename>Lttng</filename> to trace an application,
|
||||
see <ulink url='http://lttng.org/documentation'></ulink>.
|
||||
For information on how to use Lttng to trace an application,
|
||||
see <ulink url='http://lttng.org/documentation'></ulink>
|
||||
and the
|
||||
"<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>"
|
||||
section, which is in the Yocto Project Profiling and Tracing Manual.
|
||||
<note>Do not use <filename>Lttng-user space (legacy)</filename> tool.
|
||||
This tool no longer has any upstream support.</note>
|
||||
</para>
|
||||
<para>Before you use the <filename>Lttng2.0 ust trace import</filename> tool,
|
||||
you need to setup the <filename>Lttng</filename> Eclipse plug-in and create a
|
||||
<filename>Tracing</filename> project.
|
||||
you need to setup the Lttng Eclipse plug-in and create a
|
||||
Tracing project.
|
||||
Do the following:
|
||||
<orderedlist>
|
||||
<listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
|
||||
and then select <filename>Tracing</filename>.</para></listitem>
|
||||
<listitem><para>Click <filename>OK</filename> to change the Eclipse perspective
|
||||
into the <filename>Tracing</filename> perspective.</para></listitem>
|
||||
<listitem><para>Create a new <filename>Tracing</filename> project by selecting
|
||||
<filename>File -> New -> Project</filename>.</para></listitem>
|
||||
<listitem><para>Choose <filename>Tracing -> Tracing Project</filename>.
|
||||
<listitem><para>Select "Open Perspective" from the
|
||||
"Window" menu and then select "Tracing".</para></listitem>
|
||||
<listitem><para>Click "OK" to change the Eclipse perspective
|
||||
into the Tracing perspective.</para></listitem>
|
||||
<listitem><para>Create a new Tracing project by selecting
|
||||
"Project" from the "File -> New" menu.</para></listitem>
|
||||
<listitem><para>Choose "Tracing Project" from the
|
||||
"Tracing" menu.
|
||||
</para></listitem>
|
||||
<listitem><para>Generate your tracing data on the remote target.
|
||||
</para></listitem>
|
||||
<listitem><para>Click
|
||||
<filename>Yocto Project Tools -> Lttng2.0 ust trace import</filename>
|
||||
to start the data import process.</para></listitem>
|
||||
<listitem><para>Select "Lttng2.0 ust trace import" from
|
||||
the "Yocto Project Tools" menu to
|
||||
start the data import process.</para></listitem>
|
||||
<listitem><para>Specify your remote connection name.</para></listitem>
|
||||
<listitem><para>For the Ust directory path, specify the location of
|
||||
your remote tracing data.
|
||||
Make sure the location ends with <filename>ust</filename> (e.g.
|
||||
<filename>/usr/mysession/ust</filename>.</para></listitem>
|
||||
<listitem><para>Click <filename>OK</filename> to complete the import process.
|
||||
<filename>/usr/mysession/ust</filename>).</para></listitem>
|
||||
<listitem><para>Click "OK" to complete the import process.
|
||||
The data is now in the local tracing project you created.</para></listitem>
|
||||
<listitem><para>Right click on the data and then use the menu to
|
||||
<filename>Select Trace Type... -> Common Trace Format -> Generic CTF Trace</filename>
|
||||
to map the tracing type.</para></listitem>
|
||||
<listitem><para>Right click the mouse and select <filename>Open</filename>
|
||||
to bring up the Eclipse <filename>Lttng</filename> Trace Viewer so you
|
||||
Select "Generic CTF Trace" from the
|
||||
"Trace Type... -> Common Trace Format" menu to map
|
||||
the tracing type.</para></listitem>
|
||||
<listitem><para>Right click the mouse and select "Open"
|
||||
to bring up the Eclipse Lttng Trace Viewer so you
|
||||
view the tracing data.</para></listitem>
|
||||
</orderedlist></para></listitem>
|
||||
<listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis> Selecting this tool runs
|
||||
<filename>powertop</filename> on the remote target machine and displays the results in a
|
||||
new view called <filename>powertop</filename>.</para>
|
||||
<para><filename>Time to gather data(sec):</filename> is the time passed in seconds before data
|
||||
PowerTOP on the remote target machine and displays the results in a
|
||||
new view called PowerTOP.</para>
|
||||
<para>The "Time to gather data(sec):" field is the time passed in seconds before data
|
||||
is gathered from the remote target for analysis.</para>
|
||||
<para><filename>show pids in wakeups list:</filename> corresponds to the
|
||||
<para>The "show pids in wakeups list:" field corresponds to the
|
||||
<filename>-p</filename> argument
|
||||
passed to <filename>powertop</filename>.</para></listitem>
|
||||
<listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
|
||||
<filename>latencytop</filename> identifies system latency, while
|
||||
<filename>perf</filename> monitors the system's
|
||||
performance counter registers.
|
||||
passed to <filename>PowerTOP</filename>.</para></listitem>
|
||||
<listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
|
||||
LatencyTOP identifies system latency, while
|
||||
Perf monitors the system's performance counter registers.
|
||||
Selecting either of these tools causes an RSE terminal view to appear
|
||||
from which you can run the tools.
|
||||
Both tools refresh the entire screen to display results while they run.
|
||||
For more informationi on setting up and using <filename>perf</filename>,
|
||||
For more information on setting up and using <filename>perf</filename>,
|
||||
see the
|
||||
"<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
|
||||
section in the Yocto Project Profiling and Tracing Manual.
|
||||
For information on LatencyTOP, see the
|
||||
<ulink url='https://latencytop.org/'>LatencyTOP</ulink>
|
||||
website.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
@@ -1359,9 +1385,9 @@ directory.</para></listitem>
|
||||
<title>Customizing an Image Using a BitBake Commander Project and Hob</title>
|
||||
|
||||
<para>
|
||||
Within Eclipse, you can create a Yocto BitBake Commander project,
|
||||
edit the metadata, and then use the
|
||||
<ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build a customized
|
||||
Within the Eclipse IDE, you can create a Yocto BitBake Commander project,
|
||||
edit the <link linkend='metadata'>Metadata</link>, and then use
|
||||
<ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build a customized
|
||||
image all within one IDE.
|
||||
</para>
|
||||
|
||||
@@ -1371,31 +1397,35 @@ directory.</para></listitem>
|
||||
<para>
|
||||
To create a Yocto BitBake Commander project, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
|
||||
and then choose <filename>Bitbake Commander</filename>.</para></listitem>
|
||||
<listitem><para>Click <filename>OK</filename> to change the Eclipse perspective into the
|
||||
Bitbake Commander perspective.</para></listitem>
|
||||
<listitem><para>Select <filename>File -> New -> Project</filename> to create a new Yocto
|
||||
<listitem><para>Select "Other" from the
|
||||
"Window -> Open Perspective" menu
|
||||
and then choose "Bitbake Commander".</para></listitem>
|
||||
<listitem><para>Click "OK" to change the perspective to
|
||||
Bitbake Commander.</para></listitem>
|
||||
<listitem><para>Select "Project" from the "File -> New"
|
||||
menu to create a new Yocto
|
||||
Bitbake Commander project.</para></listitem>
|
||||
<listitem><para>Choose <filename>Yocto Project Bitbake Commander -> New Yocto Project</filename>
|
||||
and click <filename>Next</filename>.</para></listitem>
|
||||
<listitem><para>Choose "New Yocto Project" from the
|
||||
"Yocto Project Bitbake Commander" menu and click
|
||||
"Next".</para></listitem>
|
||||
<listitem><para>Enter the Project Name and choose the Project Location.
|
||||
The Yocto project's metadata files will be put under the directory
|
||||
The Yocto project's Metadata files will be put under the directory
|
||||
<filename><project_location>/<project_name></filename>.
|
||||
If that directory does not exist, you need to check
|
||||
the "Clone from Yocto Git Repository" box, which would execute a
|
||||
<filename>git clone</filename> command to get the project's metadata files.
|
||||
<filename>git clone</filename> command to get the project's Metadata files.
|
||||
</para></listitem>
|
||||
<listitem><para>Select <filename>Finish</filename> to create the project.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='editing-the-metadata-files'>
|
||||
<title>Editing the Metadata Files</title>
|
||||
<section id='editing-the-metadata'>
|
||||
<title>Editing the Metadata</title>
|
||||
|
||||
<para>
|
||||
After you create the Yocto Bitbake Commander project, you can modify the metadata files
|
||||
After you create the Yocto Bitbake Commander project, you can modify the
|
||||
<link linkend='metadata'>Metadata</link> files
|
||||
by opening them in the project.
|
||||
When editing recipe files (<filename>.bb</filename> files), you can view BitBake
|
||||
variable values and information by hovering the mouse pointer over the variable name and
|
||||
@@ -1403,10 +1433,11 @@ directory.</para></listitem>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To edit the metadata, follow these steps:
|
||||
To edit the Metadata, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
|
||||
<listitem><para>Select <filename>File -> New -> Yocto BitBake Commander -> BitBake Recipe</filename>
|
||||
<listitem><para>Select "BitBake Recipe" from the
|
||||
"File -> New -> Yocto BitBake Commander" menu
|
||||
to open a new recipe wizard.</para></listitem>
|
||||
<listitem><para>Point to your source by filling in the "SRC_URL" field.
|
||||
For example, you can add a recipe to your
|
||||
@@ -1419,24 +1450,28 @@ directory.</para></listitem>
|
||||
license checksum values and to auto-generate the recipe filename.</para></listitem>
|
||||
<listitem><para>Fill in the "Description" field.</para></listitem>
|
||||
<listitem><para>Be sure values for all required fields exist.</para></listitem>
|
||||
<listitem><para>Click <filename>Finish</filename>.</para></listitem>
|
||||
<listitem><para>Click "Finish".</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='buiding-and-customizing-the-image'>
|
||||
<title>Building and Customizing the Image</title>
|
||||
<section id='biding-and-customizing-the-image-using-hob'>
|
||||
<title>Building and Customizing the Image Using Hob</title>
|
||||
|
||||
<para>
|
||||
To build and customize the image in Eclipse, follow these steps:
|
||||
To build and customize the image using Hob from within the
|
||||
Eclipse IDE, follow these steps:
|
||||
<orderedlist>
|
||||
<listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
|
||||
<listitem><para>Select <filename>Project -> Launch HOB</filename>.</para></listitem>
|
||||
<listitem><para>Enter the Build Directory where you want to put your final images.</para></listitem>
|
||||
<listitem><para>Click <filename>OK</filename> to launch Hob.</para></listitem>
|
||||
<listitem><para>Select "Launch Hob" from the "Project"
|
||||
menu.</para></listitem>
|
||||
<listitem><para>Enter the
|
||||
<link linkend='build-directory'>Build Directory</link>
|
||||
where you want to put your final images.</para></listitem>
|
||||
<listitem><para>Click "OK" to launch Hob.</para></listitem>
|
||||
<listitem><para>Use Hob to customize and build your own images.
|
||||
For information on Hob, see the
|
||||
<ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob Project Page</ulink> on the
|
||||
<ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob Project Page</ulink> on the
|
||||
Yocto Project website.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
@@ -1445,7 +1480,7 @@ directory.</para></listitem>
|
||||
</section>
|
||||
|
||||
<section id='workflow-using-stand-alone-cross-development-toolchains'>
|
||||
<title>Workflow Using Stand-alone Cross-development Toolchains</title>
|
||||
<title>Workflow Using Stand-Alone Cross-Development Toolchains</title>
|
||||
|
||||
<para>
|
||||
If you want to develop an application without prior installation
|
||||
@@ -1473,7 +1508,8 @@ directory.</para></listitem>
|
||||
support development using actual hardware.
|
||||
For example, the area might contain
|
||||
<filename>.hddimg</filename> files that combine the
|
||||
kernel image with the filesystem, boot loaders, etc.
|
||||
kernel image with the filesystem, boot loaders, and
|
||||
so forth.
|
||||
Be sure to get the files you need for your particular
|
||||
development process.</para>
|
||||
<para>If you are going to develop your application and
|
||||
@@ -1660,7 +1696,7 @@ directory.</para></listitem>
|
||||
$ bitbake -c compile -f <name_of_package>
|
||||
</literallayout>
|
||||
The <filename>-f</filename> or <filename>--force</filename>
|
||||
option forces re-execution of the specified task.
|
||||
option forces the specified task to execute.
|
||||
If you find problems with your code, you can just keep editing and
|
||||
re-testing iteratively until things work as expected.
|
||||
<note>All the modifications you make to the temporary source code
|
||||
@@ -1677,7 +1713,7 @@ directory.</para></listitem>
|
||||
<literallayout class='monospaced'>
|
||||
$ quilt refresh
|
||||
</literallayout>
|
||||
At this point the <filename>my_changes.patch</filename> file has all your edits made
|
||||
At this point, the <filename>my_changes.patch</filename> file has all your edits made
|
||||
to the <filename>file1.c</filename>, <filename>file2.c</filename>, and
|
||||
<filename>file3.c</filename> files.</para>
|
||||
<para>You can find the resulting patch file in the <filename>patches/</filename>
|
||||
@@ -1757,7 +1793,7 @@ directory.</para></listitem>
|
||||
$ bitbake -c compile -f <name_of_package>
|
||||
</literallayout>
|
||||
The <filename>-f</filename> or <filename>--force</filename>
|
||||
option forces re-execution of the specified task.
|
||||
option forces the specified task to execute.
|
||||
If you find problems with your code, you can just keep editing and
|
||||
re-testing iteratively until things work as expected.
|
||||
<note>All the modifications you make to the temporary source code
|
||||
@@ -1834,17 +1870,19 @@ directory.</para></listitem>
|
||||
<title>Image Development Using Hob</title>
|
||||
|
||||
<para>
|
||||
The <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> is a graphical user interface for the
|
||||
The <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> is a graphical user interface for the
|
||||
OpenEmbedded build system, which is based on BitBake.
|
||||
You can use the Hob to build custom operating system images within the Yocto Project build environment.
|
||||
Hob simply provides a friendly interface over the build system used during system development.
|
||||
Hob simply provides a friendly interface over the build system used during development.
|
||||
In other words, building images with the Hob lets you take care of common build tasks more easily.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For a better understanding of Hob, see the project page at
|
||||
<ulink url='&YOCTO_HOME_URL;/projects/hob'></ulink> on the Yocto Project website.
|
||||
The page has a short introductory training video on Hob.
|
||||
<ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'></ulink>
|
||||
on the Yocto Project website.
|
||||
If you follow the "Documentation" link from the Hob page, you will
|
||||
find a short introductory training video on Hob.
|
||||
The following lists some features of Hob:
|
||||
<itemizedlist>
|
||||
<listitem><para>You can setup and run Hob using these commands:
|
||||
@@ -1855,9 +1893,11 @@ directory.</para></listitem>
|
||||
<listitem><para>You can set the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
for which you are building the image.</para></listitem>
|
||||
<listitem><para>You can modify various policy settings such as the package format used to build with,
|
||||
the parallelism BitBake uses, whether or not to build an external toolchain, and which host
|
||||
to build against.</para></listitem>
|
||||
<listitem><para>You can modify various policy settings such as the
|
||||
package format with which to build,
|
||||
the parallelism BitBake uses, whether or not to build an
|
||||
external toolchain, and which host to build against.
|
||||
</para></listitem>
|
||||
<listitem><para>You can manage
|
||||
<link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>
|
||||
<listitem><para>You can select a base image and then add extra packages for your custom build.
|
||||
@@ -1895,7 +1935,7 @@ directory.</para></listitem>
|
||||
<para>
|
||||
This command spawns a terminal with a shell prompt within the OpenEmbedded build environment.
|
||||
The <ulink url='&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL'><filename>OE_TERMINAL</filename></ulink>
|
||||
controls what type of shell is opened.
|
||||
variable controls what type of shell is opened.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@@ -1935,7 +1975,7 @@ directory.</para></listitem>
|
||||
|
||||
<para>
|
||||
It is also worth noting that <filename>devshell</filename> still works over
|
||||
X11 forwarding and similar situations
|
||||
X11 forwarding and similar situations.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
@@ -6,8 +6,9 @@ require conf/machine/include/tune-mips32.inc
|
||||
|
||||
MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 serial"
|
||||
|
||||
KERNEL_ALT_IMAGETYPE = "vmlinux"
|
||||
KERNEL_IMAGETYPE = "vmlinux.bin"
|
||||
KERNEL_IMAGETYPE = "vmlinux"
|
||||
KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
|
||||
KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = ".comment"
|
||||
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
PREFERRED_VERSION_linux-yocto ?= "3.4%"
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
DISTRO = "poky"
|
||||
DISTRO_NAME = "Poky 8.0 (Yocto Project 1.3 Reference Distro)"
|
||||
DISTRO_VERSION = "1.3+snapshot-${DATE}"
|
||||
DISTRO_NAME = "Poky 9.0 (Yocto Project 1.4 Reference Distro)"
|
||||
DISTRO_VERSION = "1.4"
|
||||
DISTRO_CODENAME = "dylan"
|
||||
SDK_VENDOR = "-pokysdk"
|
||||
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
|
||||
SDK_VERSION := "${@'${DISTRO_VERSION}'}"
|
||||
|
||||
MAINTAINER = "Poky <poky@yoctoproject.org>"
|
||||
|
||||
@@ -70,6 +70,7 @@ CONNECTIVITY_CHECK_URIS ?= " \
|
||||
http://bugzilla.yoctoproject.org/report.cgi"
|
||||
|
||||
SANITY_TESTED_DISTROS ?= " \
|
||||
Yocto-1.3 \n \
|
||||
Yocto-1.2 \n \
|
||||
Poky-1.2 \n \
|
||||
Poky-1.3 \n \
|
||||
@@ -89,6 +90,7 @@ SANITY_TESTED_DISTROS ?= " \
|
||||
SUSE-LINUX-11.4 \n \
|
||||
SUSE-LINUX-12.1 \n \
|
||||
SUSE-LINUX-12.2 \n \
|
||||
openSUSE-project-12.3 \n \
|
||||
"
|
||||
|
||||
# Default hash policy for distro
|
||||
|
||||
@@ -216,7 +216,7 @@ def package_qa_check_dev(path, name, d, elf, messages):
|
||||
Check for ".so" library symlinks in non-dev packages
|
||||
"""
|
||||
|
||||
if not name.endswith("-dev") and not name.endswith("-dbg") and not name.startswith("nativesdk-") and path.endswith(".so") and os.path.islink(path):
|
||||
if not name.endswith("-dev") and not name.endswith("-dbg") and not name.endswith("-ptest") and not name.startswith("nativesdk-") and path.endswith(".so") and os.path.islink(path):
|
||||
messages.append("non -dev/-dbg/-nativesdk package contains symlink .so: %s path '%s'" % \
|
||||
(name, package_qa_clean_path(path,d)))
|
||||
|
||||
@@ -229,7 +229,7 @@ def package_qa_check_staticdev(path, name, d, elf, messages):
|
||||
libgcc.a, libgcov.a will be skipped in their packages
|
||||
"""
|
||||
|
||||
if not name.endswith("-pic") and not name.endswith("-staticdev") and path.endswith(".a") and not path.endswith("_nonshared.a"):
|
||||
if not name.endswith("-pic") and not name.endswith("-staticdev") and not name.endswith("-ptest") and path.endswith(".a") and not path.endswith("_nonshared.a"):
|
||||
messages.append("non -staticdev package contains static .a library: %s path '%s'" % \
|
||||
(name, package_qa_clean_path(path,d)))
|
||||
|
||||
@@ -273,7 +273,7 @@ def package_qa_check_dbg(path, name, d, elf, messages):
|
||||
Check for ".debug" files or directories outside of the dbg package
|
||||
"""
|
||||
|
||||
if not "-dbg" in name:
|
||||
if not "-dbg" in name and not "-ptest" in name:
|
||||
if '.debug' in path.split(os.path.sep):
|
||||
messages.append("non debug package contains .debug directory: %s path %s" % \
|
||||
(name, package_qa_clean_path(path,d)))
|
||||
|
||||
@@ -88,7 +88,7 @@ do_compile_kernelmodules() {
|
||||
bbnote "no modules to compile"
|
||||
fi
|
||||
}
|
||||
addtask compile_kernelmodules after do_compile before do_install
|
||||
addtask compile_kernelmodules after do_compile before do_strip
|
||||
|
||||
kernel_do_install() {
|
||||
#
|
||||
@@ -289,6 +289,35 @@ python split_kernel_packages () {
|
||||
do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
|
||||
}
|
||||
|
||||
do_strip() {
|
||||
if [ -n "${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}" ]; then
|
||||
if [[ "${KERNEL_IMAGETYPE}" != "vmlinux" ]]; then
|
||||
bbwarn "image type will not be stripped (not supported): ${KERNEL_IMAGETYPE}"
|
||||
return
|
||||
fi
|
||||
|
||||
cd ${B}
|
||||
headers=`"$CROSS_COMPILE"readelf -S ${KERNEL_OUTPUT} | \
|
||||
grep "^ \{1,\}\[[0-9 ]\{1,\}\] [^ ]" | \
|
||||
sed "s/^ \{1,\}\[[0-9 ]\{1,\}\] //" | \
|
||||
gawk '{print $1}'`
|
||||
|
||||
for str in ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}; do {
|
||||
if [[ "$headers" != *"$str"* ]]; then
|
||||
bbwarn "Section not found: $str";
|
||||
fi
|
||||
|
||||
"$CROSS_COMPILE"strip -s -R $str ${KERNEL_OUTPUT}
|
||||
}; done
|
||||
|
||||
bbnote "KERNEL_IMAGE_STRIP_EXTRA_SECTIONS is set, stripping sections:" \
|
||||
"${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}"
|
||||
fi;
|
||||
}
|
||||
do_strip[dirs] = "${B}"
|
||||
|
||||
addtask do_strip before do_sizecheck after do_kernel_link_vmlinux
|
||||
|
||||
# Support checking the kernel size since some kernels need to reside in partitions
|
||||
# with a fixed length or there is a limit in transferring the kernel to memory
|
||||
do_sizecheck() {
|
||||
@@ -302,7 +331,7 @@ do_sizecheck() {
|
||||
}
|
||||
do_sizecheck[dirs] = "${B}"
|
||||
|
||||
addtask sizecheck before do_install after do_kernel_link_vmlinux
|
||||
addtask sizecheck before do_install after do_strip
|
||||
|
||||
KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
|
||||
# Don't include the DATETIME variable in the sstate package signatures
|
||||
|
||||
@@ -50,6 +50,9 @@ TOOLCHAIN_OPTIONS = ""
|
||||
|
||||
DEPENDS_GETTEXT = "gettext-native"
|
||||
|
||||
# Don't build ptest natively
|
||||
PTEST_ENABLED = "0"
|
||||
|
||||
# Don't use site files for native builds
|
||||
export CONFIG_SITE = ""
|
||||
|
||||
|
||||
@@ -7,25 +7,18 @@ DESCRIPTION_${PN}-ptest ?= "${DESCRIPTION} \
|
||||
This package contains a test directory ${PTEST_PATH} for package test purposes."
|
||||
|
||||
PTEST_PATH ?= "${libdir}/${PN}/ptest"
|
||||
FILES_${PN}-ptest = "${PTEST_PATH}/*"
|
||||
FILES_${PN}-ptest = "${PTEST_PATH}"
|
||||
SECTION_${PN}-ptest = "devel"
|
||||
ALLOW_EMPTY_${PN}-ptest = "1"
|
||||
PTEST_ENABLED = "${@base_contains("DISTRO_FEATURES", "ptest", "1", "0", d)}"
|
||||
RDEPENDS_${PN}-ptest_virtclass-native = ""
|
||||
RDEPENDS_${PN}-ptest_virtclass-nativesdk = ""
|
||||
|
||||
PACKAGES += "${@base_contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', '', d)}"
|
||||
|
||||
FILES_${PN}-dbg += "${PTEST_PATH}/.debug \
|
||||
${PTEST_PATH}/*/.debug \
|
||||
${PTEST_PATH}/*/*/.debug \
|
||||
${PTEST_PATH}/*/*/*/.debug \
|
||||
${PTEST_PATH}/*/*/*/*/.debug \
|
||||
"
|
||||
PACKAGES =+ "${@base_contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', '', d)}"
|
||||
|
||||
do_configure_ptest_base() {
|
||||
if [ ${PTEST_ENABLED} = 1 ]; then
|
||||
if [ type -t do_configure_ptest = function ]; then
|
||||
if [ a$(type -t do_configure_ptest) = afunction ]; then
|
||||
do_configure_ptest
|
||||
fi
|
||||
fi
|
||||
@@ -33,7 +26,7 @@ do_configure_ptest_base() {
|
||||
|
||||
do_compile_ptest_base() {
|
||||
if [ ${PTEST_ENABLED} = 1 ]; then
|
||||
if [ type -t do_compile_ptest = function ]; then
|
||||
if [ a$(type -t do_compile_ptest) = afunction ]; then
|
||||
do_compile_ptest
|
||||
fi
|
||||
fi
|
||||
@@ -46,7 +39,7 @@ do_install_ptest_base() {
|
||||
if grep -q install-ptest: Makefile; then
|
||||
oe_runmake DESTDIR=${D}${PTEST_PATH} install-ptest
|
||||
fi
|
||||
if [ type -t do_install_ptest = function ]; then
|
||||
if [ a$(type -t do_install_ptest) = afunction ]; then
|
||||
do_install_ptest
|
||||
fi
|
||||
fi
|
||||
|
||||
@@ -4,16 +4,10 @@
|
||||
|
||||
[ "$ROOTFS_READ_ONLY" = "no" ] && exit 0
|
||||
|
||||
# Make sure unionfs is in /proc/filesystems
|
||||
if ! grep -q unionfs /proc/filesystems; then
|
||||
echo "ERROR: unionfs not supported by kernel!"
|
||||
exit 1
|
||||
if [ "$1" = "start" ] ; then
|
||||
grep -q "tmpfs /var/volatile" /proc/mounts || mount /var/volatile
|
||||
mkdir -p /var/volatile/lib
|
||||
cp -a /var/lib/* /var/volatile/lib
|
||||
mount --bind /var/volatile/lib /var/lib
|
||||
fi
|
||||
|
||||
mkdir -p /var/volatile/lib
|
||||
mount -t unionfs -o dirs=/var/volatile/lib:/var/lib=ro none /var/lib
|
||||
|
||||
if [ $? != 0 ]; then
|
||||
echo "ERROR: Union mount failed!"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
@@ -118,7 +118,7 @@ do_install () {
|
||||
update-rc.d -r ${D} bootmisc.sh start 55 S .
|
||||
update-rc.d -r ${D} sysfs.sh start 02 S .
|
||||
update-rc.d -r ${D} populate-volatile.sh start 37 S .
|
||||
update-rc.d -r ${D} read-only-rootfs-hook.sh start 41 S .
|
||||
update-rc.d -r ${D} read-only-rootfs-hook.sh start 29 S .
|
||||
update-rc.d -r ${D} devpts.sh start 38 S .
|
||||
if [ "${TARGET_ARCH}" = "arm" ]; then
|
||||
update-rc.d -r ${D} alignment.sh start 06 S .
|
||||
|
||||
@@ -39,15 +39,6 @@ POSTLOG ?= "/var/log/postinstall.log"
|
||||
REDIRECT_CMD = "${@base_contains('IMAGE_FEATURES', 'debug-tweaks', '>${POSTLOG} 2>&1', '', d)}"
|
||||
|
||||
DPKG_INIT_POSITION ?= "98"
|
||||
do_install_prepend () {
|
||||
install -d ${D}/${sysconfdir}/rcS.d
|
||||
# this happens at S98 where our good 'ole packages script used to run
|
||||
echo "#!/bin/sh
|
||||
dpkg --configure -a ${REDIRECT_CMD}
|
||||
rm -f ${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
|
||||
" > ${D}/${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
|
||||
chmod 0755 ${D}/${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
|
||||
}
|
||||
|
||||
do_install_append () {
|
||||
if [ "${PN}" = "dpkg-native" ]; then
|
||||
@@ -67,6 +58,20 @@ do_install_append_class-native () {
|
||||
done
|
||||
}
|
||||
|
||||
pkg_postinst_${PN} () {
|
||||
#!/bin/sh
|
||||
if [ "x$D" != "x" ] && [ -f $D/var/lib/dpkg/status ]; then
|
||||
install -d ${D}/${sysconfdir}/rcS.d
|
||||
|
||||
# this happens at S98 where our good 'ole packages script used to run
|
||||
echo "#!/bin/sh
|
||||
dpkg --configure -a ${REDIRECT_CMD}
|
||||
rm -f ${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
|
||||
" > ${D}/${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
|
||||
chmod 0755 ${D}/${sysconfdir}/rcS.d/S${DPKG_INIT_POSITION}run-postinsts
|
||||
fi
|
||||
}
|
||||
|
||||
PROV = "virtual/update-alternatives"
|
||||
PROV_class-native = ""
|
||||
|
||||
|
||||
@@ -62,8 +62,9 @@ REDIRECT_CMD = "${@base_contains('IMAGE_FEATURES', 'debug-tweaks', '>${POSTLOG}
|
||||
|
||||
pkg_postinst_${PN} () {
|
||||
#!/bin/sh
|
||||
if [ "x$D" != "x" ]; then
|
||||
if [ "x$D" != "x" ] && [ -f $D/var/lib/opkg/status ]; then
|
||||
install -d $D${sysconfdir}/rcS.d
|
||||
|
||||
# this happens at S98 where our good 'ole packages script used to run
|
||||
echo "#!/bin/sh
|
||||
opkg-cl configure ${REDIRECT_CMD}
|
||||
|
||||
@@ -5,15 +5,12 @@ LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/LGPL-2.1;md5=1
|
||||
|
||||
RDEPENDS_${PN} = "base-files"
|
||||
|
||||
inherit update-rc.d allarch
|
||||
inherit allarch
|
||||
#
|
||||
# Allow distributions to alter when [postponed] package install scripts are run
|
||||
#
|
||||
POSTINSTALL_INITPOSITION ?= "98"
|
||||
|
||||
INITSCRIPT_NAME = "run-postinsts"
|
||||
INITSCRIPT_PARAMS = "start ${{POSTINSTALL_INITPOSITION} S ."
|
||||
|
||||
POSTLOG ?= "/var/log/postinstall.log"
|
||||
REDIRECT_CMD = "${@base_contains('IMAGE_FEATURES', 'debug-tweaks', '>>${POSTLOG} 2>&1', '', d)}"
|
||||
|
||||
@@ -30,12 +27,17 @@ do_compile() {
|
||||
}
|
||||
|
||||
do_install() {
|
||||
install -d ${D}/${sysconfdir}/rcS.d
|
||||
# Stop $i getting expanded below...
|
||||
i=\$i
|
||||
cat > ${D}${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts << EOF
|
||||
:
|
||||
}
|
||||
|
||||
pkg_postinst_${PN} () {
|
||||
if [ "x$D" != "x" ] && [ -f $D/var/lib/rpm/Packages ]; then
|
||||
install -d $D/${sysconfdir}/rcS.d
|
||||
cat > $D${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts << "EOF"
|
||||
#!/bin/sh
|
||||
for i in \`ls /etc/rpm-postinsts/\`; do
|
||||
. /etc/default/rcS
|
||||
|
||||
[ -d /etc/rpm-postinsts ] && for i in `ls /etc/rpm-postinsts/`; do
|
||||
i=/etc/rpm-postinsts/$i
|
||||
echo "Running postinst $i..."
|
||||
if [ -f $i ] && $i ${REDIRECT_CMD}; then
|
||||
@@ -44,7 +46,10 @@ for i in \`ls /etc/rpm-postinsts/\`; do
|
||||
echo "ERROR: postinst $i failed."
|
||||
fi
|
||||
done
|
||||
rm -f ${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
|
||||
rm -f ${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts 2>/dev/null
|
||||
EOF
|
||||
chmod 0755 ${D}${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
|
||||
chmod 0755 $D${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
|
||||
fi
|
||||
}
|
||||
|
||||
ALLOW_EMPTY_${PN} = "1"
|
||||
|
||||
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
|
||||
|
||||
DEPENDS = "git-native guilt-native"
|
||||
|
||||
SRCREV = "d484e3f731f38f5b4e05e13102c97d06106edfb5"
|
||||
SRCREV = "e3f59062bc594239856549e165c9e373cbbac1d6"
|
||||
PR = "r12"
|
||||
PV = "0.1+git${SRCPV}"
|
||||
|
||||
|
||||
@@ -8,9 +8,9 @@ LINUX_KERNEL_TYPE = "preempt-rt"
|
||||
|
||||
KMETA = "meta"
|
||||
|
||||
SRCREV_machine ?= "abd0728b164f651292374e96251ee197b50e3c02"
|
||||
SRCREV_machine_qemuppc ?= "1619988b773840ec546292a9cd65dda99d55b96c"
|
||||
SRCREV_meta ?= "1b534b2f8bbe9b8a773268cfa30a4850346f6f5f"
|
||||
SRCREV_machine ?= "0f7d294a9d07713059af345188f9cd4f549b4e77"
|
||||
SRCREV_machine_qemuppc ?= "82cdb00523b3f86219706d9f12dc80ff8d1c747a"
|
||||
SRCREV_meta ?= "27b63fdbd25ad1a37bacc05f49a205c150d21779"
|
||||
|
||||
PR = "${INC_PR}.0"
|
||||
PV = "${LINUX_VERSION}+git${SRCPV}"
|
||||
@@ -24,6 +24,7 @@ COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm)"
|
||||
|
||||
# Functionality flags
|
||||
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
|
||||
KERNEL_FEATURES_append_qemux86=" ${KERNEL_EXTRA_FEATURES} cfg/sound.scc cfg/paravirt_kvm.scc"
|
||||
KERNEL_FEATURES_append_qemux86-64=" ${KERNEL_EXTRA_FEATURES} cfg/sound.scc"
|
||||
KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
|
||||
KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
|
||||
KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
|
||||
KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}"
|
||||
|
||||
@@ -12,8 +12,8 @@ LINUX_VERSION ?= "3.8.4"
|
||||
|
||||
KMETA = "meta"
|
||||
|
||||
SRCREV_machine ?= "42ddf06111efe45f3c36012d5a04a1eeb9781f42"
|
||||
SRCREV_meta ?= "f86199dd4c142fae61517a993b3f7162bb6d4f94"
|
||||
SRCREV_machine ?= "11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc"
|
||||
SRCREV_meta ?= "27b63fdbd25ad1a37bacc05f49a205c150d21779"
|
||||
|
||||
PR = "${INC_PR}.0"
|
||||
PV = "${LINUX_VERSION}+git${SRCPV}"
|
||||
|
||||
@@ -3,13 +3,13 @@ require recipes-kernel/linux/linux-yocto.inc
|
||||
KBRANCH_DEFAULT = "standard/base"
|
||||
KBRANCH = "${KBRANCH_DEFAULT}"
|
||||
|
||||
SRCREV_machine_qemuarm ?= "bf458ca0e48f4f57cbb02b52070a000f361eec84"
|
||||
SRCREV_machine_qemumips ?= "c7297b41016919c95a2c779cafc0aad736f6a400"
|
||||
SRCREV_machine_qemuppc ?= "f8848d222d1fcd1ebc517d28f289735621708449"
|
||||
SRCREV_machine_qemux86 ?= "42ddf06111efe45f3c36012d5a04a1eeb9781f42"
|
||||
SRCREV_machine_qemux86-64 ?= "42ddf06111efe45f3c36012d5a04a1eeb9781f42"
|
||||
SRCREV_machine ?= "42ddf06111efe45f3c36012d5a04a1eeb9781f42"
|
||||
SRCREV_meta ?= "1b534b2f8bbe9b8a773268cfa30a4850346f6f5f"
|
||||
SRCREV_machine_qemuarm ?= "ec3299eaa89a7302009e3d46c9570f633ff32e9a"
|
||||
SRCREV_machine_qemumips ?= "0d60789d710808e38690f27216c3ab13753e1055"
|
||||
SRCREV_machine_qemuppc ?= "223428bbc1a355200bd9a8046fd272c1b9b13e67"
|
||||
SRCREV_machine_qemux86 ?= "11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc"
|
||||
SRCREV_machine_qemux86-64 ?= "11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc"
|
||||
SRCREV_machine ?= "11998bd1f44b21cd0b8c0ca11cbd36865f14bfdc"
|
||||
SRCREV_meta ?= "27b63fdbd25ad1a37bacc05f49a205c150d21779"
|
||||
|
||||
SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.8.git;protocol=git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
|
||||
|
||||
@@ -24,6 +24,7 @@ COMPATIBLE_MACHINE = "qemuarm|qemux86|qemuppc|qemumips|qemux86-64"
|
||||
|
||||
# Functionality flags
|
||||
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
|
||||
KERNEL_FEATURES_append_qemux86=" ${KERNEL_EXTRA_FEATURES} cfg/sound.scc cfg/paravirt_kvm.scc"
|
||||
KERNEL_FEATURES_append_qemux86-64=" ${KERNEL_EXTRA_FEATURES} cfg/sound.scc"
|
||||
KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
|
||||
KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
|
||||
KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
|
||||
KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " cfg/x32.scc", "" ,d)}"
|
||||
|
||||
@@ -13,7 +13,6 @@ SRC_URI[md5sum] = "47fd7eca8479c757822bee68a1feef25"
|
||||
SRC_URI[sha256sum] = "c90bfda29605942d08e3e218ef10e3c660506a06651a616bfbb6a6df8392836d"
|
||||
|
||||
do_compile_prepend() {
|
||||
cd ${S}
|
||||
mkdir -p ${S}/libltdl
|
||||
cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user