sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

General edits to the using poky and Extending Poky chapters. 

I completed general edits to the second chapter of the poky reference
manual.  These edits went from section 2.4.5 through the end of the
chapter.  They consist of text rewrites for more active voice and follow
general technical writing principles.

I completed the same types of edits in the third chapter of the manual
from the beginning through section 3.3.2.

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
This commit is contained in:
Scott Rifenbark 2010-10-28 14:29:17 -07:00 committed by Richard Purdie
parent 30e92723e1
commit 4b7f1eee28
2 changed files with 221 additions and 265 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

448
documentation/poky-ref-manual/extendpoky.xml
View File

@ -4,53 +4,50 @@
<chapter id='extendpoky'> <chapter id='extendpoky'>
<title>Extending Poky</title> <title>Extending Poky</title>
<para> <para>
This section gives information about how to extend the functionality This section provides information about how to extend the functionality
already present in Poky, documenting standard tasks such as adding new already present in Poky.
software packages, extending or customising images or porting poky to The section also documents standard tasks such as adding new
new hardware (adding a new machine). It also contains advice about how software packages, extending or customizing images or porting Poky to
to manage the process of making changes to Poky to achieve best results. new hardware (adding a new machine).
Finally, the section contains advice about how
to make changes to Poky to achieve the best results.
</para> </para>
<section id='usingpoky-extend-addpkg'> <section id='usingpoky-extend-addpkg'>
<title>Adding a Package</title> <title>Adding a Package</title>
<para> <para>
To add package into Poky you need to write a recipe for it. To add a package into Poky you need to write a recipe for it.
Writing a recipe means creating a .bb file which sets various Writing a recipe means creating a <filename>.bb</filename> file that sets some
variables. The variables variables.
useful for recipes are detailed in the <link linkend='ref-varlocality-recipe-required'> For information on variables that are useful for recipes and for information about recipe naming
recipe reference</link> section along with more detailed information issues, see <link linkend='ref-varlocality-recipe-required'>Recipe Variables - Required</link>
about issues such as recipe naming. appendix.
</para> </para>
<para> <para>
Before writing a recipe from scratch it is often useful to check Before writing a recipe from scratch it is often useful to check
whether someone else has written one already. OpenEmbedded is a good place whether someone else has written one already.
to look as it has a wider scope and hence a wider range of packages. OpenEmbedded is a good place to look as it has a wider scope and range of packages.
Poky aims to be compatible with OpenEmbedded so most recipes should Because Poky aims to be compatible with OpenEmbedded, most recipes should
just work in Poky. just work in Poky.
</para> </para>
<para> <para>
For new packages, the simplest way to add a recipe is to base it on a similar For new packages, the simplest way to add a recipe is to base it on a similar
pre-existing recipe. There are some examples below of how to add pre-existing recipe.
standard types of packages: Following are some examples showing how to add standard types of packages:
</para> </para>
<section id='usingpoky-extend-addpkg-singlec'> <section id='usingpoky-extend-addpkg-singlec'>
<title>Single .c File Package (Hello World!)</title> <title>Single .c File Package (Hello World!)</title>
<para> <para>
To build an application from a single file stored locally (e.g. under "files/") Building an application from a single file that is stored locally (e.g. under
requires a recipe which has the file listed in the <glossterm><link <filename>files/</filename>) requires a recipe that has the file listed in
linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable. In addition the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable.
the <function>do_compile</function> and <function>do_install</function> Additionally, you need to manually write the <function>do_compile</function> and
tasks need to be manually written. The <glossterm><link linkend='var-S'> <function>do_install</function> tasks.
S</link></glossterm> variable defines the directory containing the source The <glossterm><link linkend='var-S'>S</link></glossterm> variable defines the
code which in this case is set equal to <glossterm><link linkend='var-WORKDIR'> directory containing the source code, which is set to <glossterm><link linkend='var-WORKDIR'>
WORKDIR</link></glossterm>, the directory BitBake uses for the build. WORKDIR</link></glossterm> in this case - the directory BitBake uses for the build.
</para> </para>
<programlisting> <programlisting>
DESCRIPTION = "Simple helloworld application" DESCRIPTION = "Simple helloworld application"
@ -71,32 +68,28 @@ do_install() {
install -m 0755 helloworld ${D}${bindir} install -m 0755 helloworld ${D}${bindir}
} }
</programlisting> </programlisting>
<para> <para>
As a result of the build process "helloworld", "helloworld-dbg" and "hellworld-dev" By default, the "helloworld", "helloworld-dbg" and "hellworld-dev"
packages will be built by default. It is possible to<link linkend='usingpoky-extend-addpkg-files'> packages are built.
customise the packaging process</link>. For information on how to customize the packaging process, see
<link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link>.
</para> </para>
</section> </section>
<section id='usingpoky-extend-addpkg-autotools'> <section id='usingpoky-extend-addpkg-autotools'>
<title>Autotooled Package</title> <title>Autotooled Package</title>
<para> <para>
Applications which use autotools (autoconf, automake) Applications that use autotools such as <filename>autoconf</filename> and
require a recipe which has a source archive listed in <filename>automake</filename> require a recipe that has a source archive listed in
<glossterm><link <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> and
linkend='var-SRC_URI'>SRC_URI</link></glossterm> and <filename>also inherits autotools</filename>, which instructs BitBake to use the
<command>inherit autotools</command> to instruct BitBake to use the <filename>autotools.bbclass</filename> containing the definitions of all the steps
<filename>autotools.bbclass</filename> which has
definitions of all the steps
needed to build an autotooled application. needed to build an autotooled application.
The result of the build will be automatically packaged and if The result of the build is automatically packaged.
the application uses NLS to localise then packages with And, if the application uses NLS for localization, packages with local information are
locale information will be generated (one package per generated (one package per language).
language). Below is one example (hello_2.2.bb) Following is one example (<filename>hello_2.2.bb</filename>)
</para> </para>
<programlisting> <programlisting>
DESCRIPTION = "GNU Helloworld application" DESCRIPTION = "GNU Helloworld application"
SECTION = "examples" SECTION = "examples"
@ -108,50 +101,40 @@ SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools gettext inherit autotools gettext
</programlisting> </programlisting>
<para> <para>
<glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link> <glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
</glossterm> is used to <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'> </glossterm> is used to <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
track source license change</link>. Autotool based recipe can be quickly track source license change</link>.
created this way like above example. You can quickly create autotool-based recipes in a manner similar to the previous example.
</para> </para>
</section> </section>
<section id='usingpoky-extend-addpkg-makefile'> <section id='usingpoky-extend-addpkg-makefile'>
<title>Makefile-Based Package</title> <title>Makefile-Based Package</title>
<para> <para>
Applications which use GNU make require a recipe which has Applications that use GNU <filename>make</filename> also require a recipe that has
the source archive listed in <glossterm><link the source archive listed in <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>.
linkend='var-SRC_URI'>SRC_URI</link></glossterm>. You do not need to add a <function>do_compile</function> step since by default BitBake
Adding a <function>do_compile</function> step starts the <filename>make</filename> command to compile the application.
is not needed as by default BitBake will start the "make" If you need additional <filename>make</filename> options you should store them in the
command to compile the application. If there is a need for <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm> variable.
additional options to make then they should be stored in the Bitbake passes these options into the <filename>make</filename> GNU invocation.
<glossterm><link Note that a <function>do_install</function> task is still required.
linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm> variable - BitBake Otherwise BitBake runs an empty <function>do_install</function> task by default.
will pass them into the GNU
make invocation. A <function>do_install</function> task is required
- otherwise BitBake will run an empty <function>do_install</function>
task by default.
</para> </para>
<para> <para>
Some applications may require extra parameters to be passed to Some applications might require extra parameters to be passed to the compiler.
the compiler, for example an additional header path. This can For example the application might need an additional header path.
be done buy adding to the <glossterm><link You can accomplish this by adding to the <glossterm><link linkend='var-CFLAGS'>CFLAGS</link>
linkend='var-CFLAGS'>CFLAGS</link></glossterm> variable, as in the example below: </glossterm> variable.
The following example shows this:
</para> </para>
<programlisting> <programlisting>
CFLAGS_prepend = "-I ${S}/include " CFLAGS_prepend = "-I ${S}/include "
</programlisting> </programlisting>
<para> <para>
mtd-utils is an example as Makefile-based: In the following example <filename>mtd-utils</filename> is a Makefile-based package:
</para> </para>
<programlisting> <programlisting>
DESCRIPTION = "Tools for managing memory technology devices." DESCRIPTION = "Tools for managing memory technology devices."
SECTION = "base" SECTION = "base"
@ -177,25 +160,19 @@ do_install () {
</programlisting> </programlisting>
</section> </section>
<section id='usingpoky-extend-addpkg-files'> <section id='usingpoky-extend-addpkg-files'>
<title>Controlling packages content</title> <title>Controlling Package Content</title>
<para> <para>
The variables <glossterm><link You can use the variables <glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm> and
linkend='var-PACKAGES'>PACKAGES</link></glossterm> and <glossterm><link linkend='var-FILES'>FILES</link></glossterm> to split an application into
<glossterm><link linkend='var-FILES'>FILES</link></glossterm> are used to split an multiple packages.
application into multiple packages.
</para> </para>
<para> <para>
Below the "libXpm" recipe (libxpm_3.5.7.bb) is used as an example. By Following is an example that uses the "libXpm" recipe (<filename>libxpm_3.5.7.bb</filename>).
default the "libXpm" recipe generates one package By default, the "libXpm" recipe generates a single package containing the library, along
which contains the library with a few binaries.
and also a few binaries. The recipe can be adapted to You can modify the recipe to split the binaries into separate packages:
split the binaries into separate packages.
</para> </para>
<programlisting> <programlisting>
require xorg-lib-common.inc require xorg-lib-common.inc
@ -211,20 +188,19 @@ PACKAGES =+ "sxpm cxpm"
FILES_cxpm = "${bindir}/cxpm" FILES_cxpm = "${bindir}/cxpm"
FILES_sxpm = "${bindir}/sxpm" FILES_sxpm = "${bindir}/sxpm"
</programlisting> </programlisting>
<para> <para>
In this example we want to ship the "sxpm" and "cxpm" binaries In the previous example we want to ship the "sxpm" and "cxpm" binaries
in separate packages. Since "bindir" would be packaged into the in separate packages.
main <glossterm><link linkend='var-PN'>PN</link></glossterm> Since "bindir" would be packaged into the main
package as standard we prepend the <glossterm><link <glossterm><link linkend='var-PN'>PN</link></glossterm>
linkend='var-PACKAGES'>PACKAGES</link></glossterm> variable so package by default, we prepend the <glossterm><link linkend='var-PACKAGES'>PACKAGES</link>
additional package names are added to the start of list. The </glossterm> variable so additional package names are added to the start of list.
extra <glossterm><link linkend='var-FILES'>FILES</link></glossterm>_* This results in the extra <glossterm><link linkend='var-FILES'>FILES</link></glossterm>_*
variables then contain information to specify which files and variables then containing information defining which files and
directories goes into which package. Files included by earlier directories go into which package.
package are skipped by latter packages, and thus main <glossterm> Files included by earlier packages are skipped by latter packages.
<link linkend='var-PN'>PN</link></glossterm> will not include Thus, the main <glossterm><link linkend='var-PN'>PN</link></glossterm> package does not include
above listed files the above listed files.
</para> </para>
</section> </section>
@ -232,14 +208,13 @@ FILES_sxpm = "${bindir}/sxpm"
<title>Post Install Scripts</title> <title>Post Install Scripts</title>
<para> <para>
To add a post-installation script to a package, add To add a post-installation script to a package, add a <function>pkg_postinst_PACKAGENAME()
a <function>pkg_postinst_PACKAGENAME()</function> </function> function to the <filename>.bb</filename> file and use
function to the .bb file <filename>PACKAGENAME</filename> as the name of the package you want to attach to the
where PACKAGENAME is the name of the package to attach <filename>postinst</filename> script.
the postinst script to. Normally <glossterm><link Normally <glossterm><link linkend='var-PN'>PN</link></glossterm> can be used, which
linkend='var-PN'>PN</link></glossterm> can be used which expands automatically expands to PACKAGENAME.
to PACKAGENAME automatically. A post-installation function has the A post-installation function has the following structure:
following structure:
</para> </para>
<programlisting> <programlisting>
pkg_postinst_PACKAGENAME () { pkg_postinst_PACKAGENAME () {
@ -248,21 +223,18 @@ pkg_postinst_PACKAGENAME () {
} }
</programlisting> </programlisting>
<para> <para>
The script defined in the post installation function The script defined in the post-installation function is called when the rootfs is made.
gets called when the rootfs is made. If the script succeeds, If the script succeeds, the package is marked as installed.
the package is marked as installed. If the script fails, If the script fails, the package is marked as unpacked and the script is
the package is marked as unpacked and the script will be executed when the image boots again.
executed again on the first boot of the image.
</para> </para>
<para> <para>
Sometimes it is necessary that the execution of a post-installation Sometimes it is necessary for the execution of a post-installation
script is delayed until the first boot, because the script script to be delayed until the first boot.
needs to be executed on the device itself. To delay script execution For example, the script might need to be executed on the device itself.
until boot time, the post-installation function should have the To delay script execution until boot time, use the following structure for the
following structure: post-installation script:
</para> </para>
<programlisting> <programlisting>
pkg_postinst_PACKAGENAME () { pkg_postinst_PACKAGENAME () {
#!/bin/sh -e #!/bin/sh -e
@ -273,83 +245,69 @@ else
fi fi
} }
</programlisting> </programlisting>
<para> <para>
The structure above delays execution until first boot The previous example delays execution until the image boots again because the
because the <glossterm><link <glossterm><link linkend='var-D'>D</link></glossterm> variable points
linkend='var-D'>D</link></glossterm> variable points to the 'image' directory when the rootfs is being made at build time but
to the 'image'
directory when the rootfs is being made at build time but
is unset when executed on the first boot. is unset when executed on the first boot.
</para> </para>
</section> </section>
</section> </section>
<section id='usingpoky-extend-customimage'> <section id='usingpoky-extend-customimage'>
<title>Customising Images</title> <title>Customising Images</title>
<para> <para>
Poky images can be customised to satisfy You can customize Poky images to satisfy particular requirements.
particular requirements. Several methods are detailed below This section describes several methods and provides guidelines for each.
along with guidelines of when to use them.
</para> </para>
<section id='usingpoky-extend-customimage-custombb'> <section id='usingpoky-extend-customimage-custombb'>
<title>Customising Images through a custom image .bb files</title> <title>Customising Images Using Custom .bb Files</title>
<para> <para>
One way to get additional software into an image is by creating a One way to get additional software into an image is to create a custom image.
custom image. The recipe will contain two lines: The following example shows the form for the two lines you need:
</para> </para>
<programlisting> <programlisting>
IMAGE_INSTALL = "task-poky-x11-base package1 package2" IMAGE_INSTALL = "task-poky-x11-base package1 package2"
inherit poky-image inherit poky-image
</programlisting> </programlisting>
<para> <para>
By creating a custom image, a developer has total control By creating a custom image, a developer has total control
over the contents of the image. It is important to use over the contents of the image.
the correct names of packages in the <glossterm><link It is important to use the correct names of packages in the
linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm> variable. <glossterm><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm> variable.
The names must be in You must use the OpenEmbedded notation and not the Debian notation for the names
the OpenEmbedded notation instead of Debian notation, for example (e.g. "glibc-dev" instead of "libc6-dev").
"glibc-dev" instead of "libc6-dev" etc.
</para> </para>
<para> <para>
The other method of creating a new image is by modifying The other method for creating a custom image is to modify an existing image.
an existing image. For example if a developer wants to add For example, if a developer wants to add "strace" into "poky-image-sato", they can use
"strace" into "poky-image-sato" the following recipe can the following recipe:
be used:
</para> </para>
<programlisting> <programlisting>
require poky-image-sato.bb require poky-image-sato.bb
IMAGE_INSTALL += "strace" IMAGE_INSTALL += "strace"
</programlisting> </programlisting>
</section> </section>
<section id='usingpoky-extend-customimage-customtasks'> <section id='usingpoky-extend-customimage-customtasks'>
<title>Customising Images through custom tasks</title> <title>Customising Images Using Custom Tasks</title>
<para> <para>
For complex custom images, the best approach is to create a custom For complex custom images, the best approach is to create a custom task package
task package which is then used to build the image (or images). A good that is used to build the image or images.
example of a tasks package is <filename>meta/packages/tasks/task-poky.bb A good example of a tasks package is <filename>meta/recipes-sato/tasks/task-poky.bb
</filename>. The <glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm> </filename>.
variable lists the task packages to build (along with the complementary The <glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm>
-dbg and -dev packages). For each package added, variable lists the task packages to build along with the complementary
<glossterm><link linkend='var-PACKAGES'>RDEPENDS</link></glossterm> and -dbg and -dev packages.
<glossterm><link linkend='var-PACKAGES'>RRECOMMENDS</link></glossterm> For each package added, you can use
entries can then be added each containing a list of packages the parent <glossterm><link linkend='var-PACKAGES'>RDEPENDS</link></glossterm>
task package should contain. An example would be: and <glossterm><link linkend='var-PACKAGES'>RRECOMMENDS</link></glossterm>
entries to provide a list of packages the parent task package should contain.
Following is an example:
</para> </para>
<para> <para>
<programlisting> <programlisting>
DESCRIPTION = "My Custom Tasks" DESCRIPTION = "My Custom Tasks"
@ -378,11 +336,11 @@ RRECOMMENDS_task-custom-tools = "\
kernel-module-oprofile" kernel-module-oprofile"
</programlisting> </programlisting>
</para> </para>
<para> <para>
In this example, two task packages are created, task-custom-apps and In the previous example, two task packages are created with their dependencies and their
task-custom-tools with the dependencies and recommended package dependencies recommended package dependencies listed: <filename>task-custom-apps</filename>, and
listed. To build an image using these task packages, you would then add <filename>task-custom-tools</filename>.
To build an image using these task packages, you need to add
"task-custom-apps" and/or "task-custom-tools" to <glossterm><link "task-custom-apps" and/or "task-custom-tools" to <glossterm><link
linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm> or other forms linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm> or other forms
of image dependencies as described in other areas of this section. of image dependencies as described in other areas of this section.
@ -390,131 +348,133 @@ RRECOMMENDS_task-custom-tools = "\
</section> </section>
<section id='usingpoky-extend-customimage-imagefeatures'> <section id='usingpoky-extend-customimage-imagefeatures'>
<title>Customising Images through custom <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm></title> <title>Customising Images Using Custom <glossterm>
<link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm></title>
<para> <para>
Ultimately users may want to add extra image "features" as used by Poky with the Ultimately users might want to add extra image "features" as used by Poky with the
<glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
variable. To create these, the best reference is <filename>meta/classes/poky-image.bbclass</filename> variable.
which illustrates how poky achieves this. In summary, the file looks at the contents of the To create these features, the best reference is
<filename>meta/classes/poky-image.bbclass</filename>, which shows how poky achieves this.
In summary, the file looks at the contents of the
<glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
variable and then maps this into a set of tasks or packages. Based on this then the variable and then maps them into a set of tasks or packages.
<glossterm><link linkend='var-IMAGE_INSTALL'> IMAGE_INSTALL</link></glossterm> Based on this information the <glossterm><link linkend='var-IMAGE_INSTALL'> IMAGE_INSTALL</link>
variable is generated automatically. Extra features can be added by </glossterm> variable is generated automatically.
extending the class or creating a custom class for use with specialised image .bb files. Users can add extra features by extending the class or creating a custom class for use
with specialized image <filename>.bb</filename> files.
</para> </para>
</section> </section>
<section id='usingpoky-extend-customimage-localconf'> <section id='usingpoky-extend-customimage-localconf'>
<title>Customising Images through local.conf</title> <title>Customising Images Using local.conf</title>
<para> <para>
It is possible to customise image contents by abusing It is possible to customise image contents by abusing variables used by distribution
variables used by distribution maintainers in local.conf. maintainers in local.conf.
This method only allows the addition of packages and This method only allows the addition of packages and is not recommended.
is not recommended.
</para> </para>
<para> <para>
To add an "strace" package into the image the following is For example, to add the "strace" package into the image the you would add this to the
added to local.conf: <filename>local.conf</filename> file:
</para> </para>
<programlisting> <programlisting>
DISTRO_EXTRA_RDEPENDS += "strace" DISTRO_EXTRA_RDEPENDS += "strace"
</programlisting> </programlisting>
<para> <para>
However, since the <glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'> However, since the <glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'>
DISTRO_EXTRA_RDEPENDS</link></glossterm> variable is for DISTRO_EXTRA_RDEPENDS</link></glossterm> variable is for
distribution maintainers this method does not make distribution maintainers, adding packages using this method is not as simple as adding
adding packages as simple as a custom .bb file. Using them using a custom <filename>.bb</filename> file.
this method, a few packages will need to be recreated if they have been Using the <filename>local.conf</filename> file method could result in some packages
created before and then the image is rebuilt. requiring recreation.
For example, if packages were previously created and the image was rebuilt then the packages
would need to be recreated.
</para>
<para>
Cleaning task-* packages is required because they use the
<glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'>
DISTRO_EXTRA_RDEPENDS</link></glossterm> variable.
You do not have to build them by hand because Poky images depend on the packages they contain.
This means dependencies are automatically built when the image builds.
For this reason we don't use the "rebuild" task.
In this case the "rebuild" task does does not care about
dependencies - it only rebuilds the specified package.
</para> </para>
<programlisting> <programlisting>
bitbake -c clean task-boot task-base task-poky bitbake -c clean task-boot task-base task-poky
bitbake poky-image-sato bitbake poky-image-sato
</programlisting> </programlisting>
<para>
Cleaning task-* packages is required because they use the
<glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'>
DISTRO_EXTRA_RDEPENDS</link></glossterm> variable. There is no need to
build them by hand as Poky images depend on the packages they contain so
dependencies will be built automatically when building the image. For this reason we don't use the
"rebuild" task in this case since "rebuild" does not care about
dependencies - it only rebuilds the specified package.
</para>
</section> </section>
</section> </section>
<section id="platdev-newmachine"> <section id="platdev-newmachine">
<title>Porting Poky to a new machine</title> <title>Porting Poky to a New Machine</title>
<para> <para>
Adding a new machine to Poky is a straightforward process and Adding a new machine to Poky is a straightforward process.
this section gives an idea of the changes that are needed. This guide is This section provides information that gives you an idea of the changes you must make.
meant to cover adding machines similar to those Poky already supports. The information covers adding machines similar to those Poky already supports.
Adding a totally new architecture might require gcc/glibc changes as Although well within the capabilities of Poky, adding a totally new architecture might require
well as updates to the site information and, whilst well within Poky's changes to <filename>gcc/glibc</filename> and to the site information.
capabilities, is outside the scope of this section. Consequently, the information is beyond the scope of this manual.
</para> </para>
<section id="platdev-newmachine-conffile"> <section id="platdev-newmachine-conffile">
<title>Adding the machine configuration file</title> <title>Adding the Machine Configuration File</title>
<para> <para>
A .conf file needs to be added to conf/machine/ with details of the To add a machine configuration you need to add a <filename>.conf</filename> file
device being added. The name of the file determines the name Poky will with details of the device being added to <filename>conf/machine/</filename>.
use to reference this machine. The name of the file determines the name Poky uses to reference the new machine.
</para> </para>
<para> <para>
The most important variables to set in this file are <glossterm> The most important variables to set in this file are <glossterm>
<link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></glossterm> <link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></glossterm>
(e.g. "arm"), <glossterm><link linkend='var-PREFERRED_PROVIDER'> (e.g. "arm"), <glossterm><link linkend='var-PREFERRED_PROVIDER'>
PREFERRED_PROVIDER</link></glossterm>_virtual/kernel (see below) and PREFERRED_PROVIDER</link></glossterm>_virtual/kernel (see below) and
<glossterm><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES <glossterm><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES
</link></glossterm> (e.g. "kernel26 apm screen wifi"). Other variables </link></glossterm> (e.g. "kernel26 apm screen wifi").
like <glossterm><link linkend='var-SERIAL_CONSOLE'>SERIAL_CONSOLE You might also need other variables like <glossterm><link linkend='var-SERIAL_CONSOLE'>SERIAL_CONSOLE
</link></glossterm> (e.g. "115200 ttyS0"), <glossterm> </link></glossterm> (e.g. "115200 ttyS0"), <glossterm>
<link linkend='var-KERNEL_IMAGETYPE'>KERNEL_IMAGETYPE</link> <link linkend='var-KERNEL_IMAGETYPE'>KERNEL_IMAGETYPE</link>
</glossterm> (e.g. "zImage") and <glossterm><link linkend='var-IMAGE_FSTYPES'> </glossterm> (e.g. "zImage") and <glossterm><link linkend='var-IMAGE_FSTYPES'>
IMAGE_FSTYPES</link></glossterm> (e.g. "tar.gz jffs2") might also be IMAGE_FSTYPES</link></glossterm> (e.g. "tar.gz jffs2").
needed. Full details on what these variables do and the meaning of You can find full details on these variables in the reference section.
their contents is available through the links. There're lots of existing You can leverage many existing machine <filename>.conf</filename> files from
machine .conf files which can be easily leveraged from meta/conf/machine/. <filename>meta/conf/machine/</filename>.
</para> </para>
</section> </section>
<section id="platdev-newmachine-kernel"> <section id="platdev-newmachine-kernel">
<title>Adding a kernel for the machine</title> <title>Adding a Kernel for the Machine</title>
<para> <para>
Poky needs to be able to build a kernel for the machine. You need Poky needs to be able to build a kernel for the machine.
to either create a new kernel recipe for this machine or extend an You need to either create a new kernel recipe for this machine, or extend an
existing recipe. There are plenty of kernel examples in the existing recipe.
meta/recipes-kernel/linux directory which can be used as references. You can find several kernel examples in the <filename>meta/recipes-kernel/linux</filename>
directory that can be used as references.
</para> </para>
<para> <para>
If creating a new recipe the "normal" recipe writing rules apply If you are creating a new recipe, the "normal" recipe-writing rules apply for setting
for setting up a <glossterm><link linkend='var-SRC_URI'>SRC_URI up a <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>.
</link></glossterm> including any patches and setting <glossterm> This means specifying any necessary patches and setting <glossterm>
<link linkend='var-S'>S</link></glossterm> to point at the source <link linkend='var-S'>S</link></glossterm> to point at the source code.
code. You will need to create a configure task which configures the You need to create a "configure" task that configures the unpacked kernel with a defconfig.
unpacked kernel with a defconfig be that through a "make defconfig" You can do this by using a <filename>make defconfig</filename> command or
command or more usually though copying in a suitable defconfig and more commonly by copying in a suitable defconfig and and then running
running "make oldconfig". By making use of "inherit kernel" and also <filename>make oldconfig</filename>.
maybe some of the linux-*.inc files, most other functionality is By making use of "inherit kernel" and potentially some of the
centralised and the the defaults of the class normally work well. <filename>linux-*.inc</filename> files, most other functionality is
centralized and the the defaults of the class normally work well.
</para> </para>
<para> <para>
If extending an existing kernel it is usually a case of adding a If you are extending an existing kernel, it is usually a matter of adding a
suitable defconfig file in a location similar to that used by other suitable <filename>defconfig</filename> file.
machine's defconfig files in a given kernel, possibly listing it in The file needs to be added into a location similar to <filename>defconfig</filename> files
the SRC_URI and adding the machine to the expression in <glossterm> used for other machines in a given kernel.
<link linkend='var-COMPATIBLE_MACHINE'>COMPATIBLE_MACHINE</link> A possible way to do this is by listing the file in the
</glossterm>: <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>
and adding the machine to the expression in
<glossterm><link linkend='var-COMPATIBLE_MACHINE'>COMPATIBLE_MACHINE</link></glossterm>:
</para> </para>
<programlisting> <programlisting>
COMPATIBLE_MACHINE = '(qemux86|qemumips)' COMPATIBLE_MACHINE = '(qemux86|qemumips)'
@ -522,7 +482,7 @@ COMPATIBLE_MACHINE = '(qemux86|qemumips)'
</section> </section>
<section id="platdev-newmachine-formfactor"> <section id="platdev-newmachine-formfactor">
<title>Adding a formfactor configuration file</title> <title>Adding a Formfactor Configuration File</title>
<para> <para>
A formfactor configuration file provides information about the A formfactor configuration file provides information about the
target hardware on which Poky is running, and that Poky cannot target hardware on which Poky is running, and that Poky cannot

38
documentation/poky-ref-manual/usingpoky.xml
View File

@ -205,7 +205,7 @@ $ bitbake &lt;target&gt;
</section> </section>
<section id='usingpoky-debugging-taskrunning'> <section id='usingpoky-debugging-taskrunning'>
<title>Running specific tasks</title> <title>Running Specific Tasks</title>
<para> Any given package consists of a set of tasks. <para> Any given package consists of a set of tasks.
In most cases the series is: fetch, unpack, patch, configure, In most cases the series is: fetch, unpack, patch, configure,
@ -287,24 +287,20 @@ $ bitbake matchbox-desktop -c
</section> </section>
<section id='usingpoky-debugging-buildfile'> <section id='usingpoky-debugging-buildfile'>
<title>Building with no dependencies</title> <title>Building with No Dependencies</title>
<para> <para>
If you really want to build a specific .bb file, you can use If you really want to build a specific <filename>.bb</filename> file, you can use
the form <command>bitbake -b somepath/somefile.bb</command>. Note that this the command form <filename>bitbake -b somepath/somefile.bb</filename>.
will not check the dependencies so this option should only This command form does not check for dependencies so you should use it
be used when you know its dependencies already exist. You only when you know its dependencies already exist.
can specify fragments of the filename and bitbake will see You can also specify fragments of the filename and bitbake checks for a unique match.
if it can find a unique match.
</para> </para>
</section> </section>
<section id='usingpoky-debugging-variables'> <section id='usingpoky-debugging-variables'>
<title>Variables</title> <title>Variables</title>
<para> <para>
The "-e" option will dump the resulting environment for The "-e" option dumps the resulting environment for
either the configuration (no package specified) or for a either the configuration (no package specified) or for a
specific package when specified with the "-b" option. specific package when specified with the "-b" option.
</para> </para>
@ -312,23 +308,23 @@ $ bitbake matchbox-desktop -c
<section id='usingpoky-debugging-others'> <section id='usingpoky-debugging-others'>
<title>Other Tips</title> <title>Other Tips</title>
<tip> <tip>
<para>When adding new packages it is worth keeping an eye open for bad <para>
things creeping into compiler commandlines such as references to local When adding new packages it is worth watching for undesireable items making their way
system files (<filename>/usr/lib/</filename> or <filename>/usr/include/</filename> etc.). into compiler command lines.
For example, you do not want references to local system files like
<filename>/usr/lib/</filename> or <filename>/usr/include/</filename>.
</para> </para>
</tip> </tip>
<tip> <tip>
<para> <para>
If you want to remove the psplash boot splashscreen, add "psplash=false" If you want to remove the psplash boot splashscreen, add "psplash=false"
to the kernel commandline and psplash won't load allowing you to see to the kernel command line.
the console. It's also possible to switch out of the splashscreen by Doing so prevents psplash from loading thus allowing you to see the console.
switching virtual console (Fn+Left or Fn+Right on a Zaurus). It is also possible to switch out of the splashscreen by
switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
</para> </para>
</tip> </tip>
</section> </section>
</section> </section>