sphinx: remove DocBook files

The Yocto Project documentation was migrated to Sphinx. Let's remove
the deprecated DocBook files.

(From yocto-docs rev: 28fb0e63b2fbfd6426b00498bf2682bb53fdd862)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Nicolas Dechesne 2020-10-05 16:30:32 +02:00 committed by Richard Purdie
parent 1fd9c4b2c0
commit 43d07a2851
208 changed files with 0 additions and 100194 deletions

View File

@ -1,390 +0,0 @@
#
# SPDX-License-Identifier: CC-BY-2.0-UK
#
# This is a single Makefile to handle all generated Yocto Project documents,
# which includes the BitBake User Manual and the Toaster User Manual.
# The Makefile needs to live in the documents directory and all figures used
# in any manuals must be .PNG files and live in the individual book's figures
# directory as well as in the figures directory for the mega-manual.
#
# Note that the figures for the Yocto Project Development Tasks Manual
# differ depending on the BRANCH being built.
#
# The Makefile has these targets:
# all: If you leave off the target then "all" is implied.
# You will generate HTML and a tarball of files.
#
# pdf: generates a PDF version of a manual. Not valid for the
# Quick Start or the mega-manual (single, large HTML file
# comprised of all Yocto Project manuals).
# html: generates an HTML version of a manual.
# tarball: creates a tarball for the doc files.
# validate: validates
# publish: pushes generated files to the Yocto Project website
# clean: removes files
#
# The Makefile can generate an HTML and PDF version of every document except the
# Yocto Project Quick Start and the single, HTML mega-manual, which is comprised
# of all the individual Yocto Project manuals. You can generate these two manuals
# in HTML form only. The variable DOC indicates the folder name for a given manual.
# The variable VER represents the distro version of the Yocto Release for which the
# manuals are being generated. The variable BRANCH is used to indicate the
# branch (edison or denzil) and is used only when DOC=dev-manual or
# DOC=mega-manual. If you do not specify a BRANCH, the default branch used
# will be for the latest Yocto Project release. If you build for either
# edison or denzil, you must use BRANCH. You do not need to use BRANCH for
# any release beyond denzil.
#
# To build a manual, you must invoke Makefile with the DOC argument. If you
# are going to publish the manual, then you must invoke Makefile with both the
# DOC and the VER argument. Furthermore, if you are building or publishing
# the edison or denzil versions of the Yocto Project Development Tasks Manual or
# the mega-manual, you must also use the BRANCH argument.
#
# Examples:
#
# make DOC=bsp-guide
# make html DOC=brief-yoctoprojectqs
# make pdf DOC=ref-manual
# make DOC=dev-manual BRANCH=edison
# make DOC=mega-manual BRANCH=denzil
#
# The first example generates the HTML version of the BSP Guide.
# The second example generates the HTML version only of the Quick Start. Note
# that the Quick Start only has an HTML version available. So, the
# 'make DOC=brief-yoctoprojectqs' command would be equivalent. The third example
# generates just the PDF version of the Yocto Project Reference Manual.
# The fourth example generates the HTML 'edison' version of the YP Development
# Tasks Manual. The last example
# generates the HTML version of the mega-manual and uses the 'denzil'
# branch when choosing figures for the tarball of figures. Any example that does
# not use the BRANCH argument builds the current version of the manual set.
#
# The publish target pushes the generated manuals to the Yocto Project
# website. Unless you are a developer on the YP team, you will not succeed in
# pushing manuals to this server. All files needed for the manual's HTML form are
# pushed.
#
# Examples:
#
# make publish DOC=bsp-guide VER=1.7
# make publish DOC=adt-manual VER=1.6
# make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
# make publish DOC=dev-manual VER=1.2 BRANCH=denzil
#
# The first example publishes the 1.7 version of both the PDF and HTML versions of
# the BSP Guide. The second example publishes the 1.6 version of both the PDF and
# HTML versions of the ADT Manual. The third example publishes the 1.1.1 version of
# the PDF and HTML YP Development Tasks Manual for the 'edison' branch. The fourth
# example publishes the 1.2 version of the PDF and HTML YP Development Tasks Manual
# for the 'denzil' branch.
#
# IN MEMORIAM: This comment is to remember Scott Rifenbark (scottrif), whom we lost
# in January, 2020. Scott was the primary technical writer for the Yocto Project for
# over 9 years. In that time, he contributed many thousands of patches, built this
# documentation tree, and enabled tens of thousands of developers to succeed with
# embedded Linux. He ran this Makefile many thousands of times. Godspeed, Dude.
ifeq ($(DOC),brief-yoctoprojectqs)
XSLTOPTS = --stringparam html.stylesheet brief-yoctoprojectqs-style.css \
--stringparam chapter.autolabel 0 \
--stringparam section.autolabel 0 \
--stringparam section.label.includes.component.label 0 \
--xinclude
ALLPREQ = html tarball
TARFILES = brief-yoctoprojectqs-style.css brief-yoctoprojectqs.html figures/bypqs-title.png \
figures/yocto-project-transp.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),overview-manual)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = overview-manual-style.css overview-manual.html figures/overview-manual-title.png \
figures/git-workflow.png figures/source-repos.png figures/index-downloads.png \
figures/yp-download.png figures/YP-flow-diagram.png figures/key-dev-elements.png \
figures/poky-reference-distribution.png figures/cross-development-toolchains.png \
figures/user-configuration.png figures/layer-input.png figures/source-input.png \
figures/package-feeds.png figures/patching.png figures/source-fetching.png \
figures/configuration-compile-autoreconf.png figures/analysis-for-package-splitting.png \
figures/image-generation.png figures/sdk-generation.png figures/images.png \
figures/sdk.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),bsp-guide)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = bsp-style.css bsp-guide.html figures/bsp-title.png \
figures/bsp-dev-flow.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),dev-manual)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
#
# Note that the tarfile might produce the "Cannot stat: No such file or
# directory" error message for .PNG files that are not present when building
# a particular branch. The list of files is all-inclusive for all branches.
# Note, if you don't provide a BRANCH option, it defaults to the latest stuff.
# This would be appropriate for "master" branch.
#
TARFILES = dev-style.css dev-manual.html figures/buildhistory-web.png \
figures/dev-title.png figures/buildhistory.png \
figures/recipe-workflow.png figures/bitbake-build-flow.png \
figures/multiconfig_files.png figures/cute-files-npm-example.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),mega-manual)
XSLTOPTS = --stringparam html.stylesheet mega-style.css \
--stringparam chapter.autolabel 1 \
--stringparam section.autolabel 1 \
--stringparam section.label.includes.component.label 1 \
--xinclude
ALLPREQ = html tarball
TARFILES = mega-manual.html mega-style.css \
figures/YP-flow-diagram.png \
figures/using-a-pre-built-image.png \
figures/poky-title.png figures/buildhistory.png \
figures/buildhistory-web.png \
figures/sdk-title.png figures/bsp-title.png \
figures/kernel-dev-title.png figures/kernel-architecture-overview.png \
figures/bsp-dev-flow.png \
figures/dev-title.png \
figures/git-workflow.png figures/index-downloads.png \
figures/kernel-dev-flow.png \
figures/kernel-overview-2-generic.png \
figures/source-repos.png figures/yp-download.png \
figures/profile-title.png figures/kernelshark-all.png \
figures/kernelshark-choose-events.png \
figures/kernelshark-i915-display.png \
figures/kernelshark-output-display.png \
figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
figures/oprofileui-downloading.png figures/oprofileui-processes.png \
figures/perf-probe-do_fork-profile.png \
figures/perf-report-cycles-u.png \
figures/perf-systemwide.png figures/perf-systemwide-libc.png \
figures/perf-wget-busybox-annotate-menu.png \
figures/perf-wget-busybox-annotate-udhcpc.png \
figures/perf-wget-busybox-debuginfo.png \
figures/perf-wget-busybox-dso-zoom.png \
figures/perf-wget-busybox-dso-zoom-menu.png \
figures/perf-wget-busybox-expanded-stripped.png \
figures/perf-wget-flat-stripped.png \
figures/perf-wget-g-copy-from-user-expanded-stripped.png \
figures/perf-wget-g-copy-to-user-expanded-debuginfo.png \
figures/perf-wget-g-copy-to-user-expanded-stripped.png \
figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png \
figures/pybootchartgui-linux-yocto.png \
figures/pychart-linux-yocto-rpm.png \
figures/pychart-linux-yocto-rpm-nostrip.png \
figures/sched-wakeup-profile.png figures/sysprof-callers.png \
figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png \
figures/cross-development-toolchains.png \
figures/user-configuration.png \
figures/source-input.png figures/package-feeds.png \
figures/layer-input.png figures/images.png figures/sdk.png \
figures/source-fetching.png figures/patching.png \
figures/configuration-compile-autoreconf.png \
figures/analysis-for-package-splitting.png \
figures/image-generation.png figures/key-dev-elements.png\
figures/sdk-generation.png figures/recipe-workflow.png \
figures/build-workspace-directory.png figures/mega-title.png \
figures/toaster-title.png figures/hosted-service.png figures/multiconfig_files.png \
figures/simple-configuration.png figures/poky-reference-distribution.png \
figures/compatible-layers.png figures/import-layer.png figures/new-project.png \
figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
figures/sdk-devtool-add-flow.png figures/sdk-installed-extensible-sdk-directory.png \
figures/sdk-devtool-modify-flow.png \
figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/bypqs-title.png \
figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \
figures/bb_multiconfig_files.png figures/bitbake-title.png figures/cute-files-npm-example.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),ref-manual)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = ref-manual.html ref-style.css figures/poky-title.png \
figures/build-workspace-directory.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),sdk-manual)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = sdk-manual.html sdk-style.css figures/sdk-title.png \
figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
figures/sdk-installed-extensible-sdk-directory.png figures/sdk-devtool-add-flow.png \
figures/sdk-devtool-modify-flow.png \
figures/sdk-devtool-upgrade-flow.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),profile-manual)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = profile-manual.html profile-manual-style.css \
figures/profile-title.png figures/kernelshark-all.png \
figures/kernelshark-choose-events.png \
figures/kernelshark-i915-display.png \
figures/kernelshark-output-display.png \
figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
figures/oprofileui-downloading.png figures/oprofileui-processes.png \
figures/perf-probe-do_fork-profile.png \
figures/perf-report-cycles-u.png \
figures/perf-systemwide.png figures/perf-systemwide-libc.png \
figures/perf-wget-busybox-annotate-menu.png \
figures/perf-wget-busybox-annotate-udhcpc.png \
figures/perf-wget-busybox-debuginfo.png \
figures/perf-wget-busybox-dso-zoom.png \
figures/perf-wget-busybox-dso-zoom-menu.png \
figures/perf-wget-busybox-expanded-stripped.png \
figures/perf-wget-flat-stripped.png \
figures/perf-wget-g-copy-from-user-expanded-stripped.png \
figures/perf-wget-g-copy-to-user-expanded-debuginfo.png \
figures/perf-wget-g-copy-to-user-expanded-stripped.png \
figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png \
figures/pybootchartgui-linux-yocto.png \
figures/pychart-linux-yocto-rpm.png \
figures/pychart-linux-yocto-rpm-nostrip.png \
figures/sched-wakeup-profile.png figures/sysprof-callers.png \
figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),kernel-dev)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = kernel-dev.html kernel-dev-style.css \
figures/kernel-dev-title.png figures/kernel-overview-2-generic.png \
figures/kernel-architecture-overview.png figures/kernel-dev-flow.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),toaster-manual)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = toaster-manual.html toaster-manual-style.css \
figures/toaster-title.png figures/simple-configuration.png \
figures/hosted-service.png \
figures/compatible-layers.png figures/import-layer.png figures/new-project.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
ifeq ($(DOC),test-manual)
XSLTOPTS = --xinclude
ALLPREQ = html tarball
TARFILES = test-manual.html test-manual-style.css \
figures/test-manual-title.png figures/ab-test-cluster.png
MANUALS = $(DOC)/$(DOC).html
FIGURES = figures
STYLESHEET = $(DOC)/*.css
endif
##
# These URI should be rewritten by your distribution's xml catalog to
# match your locally installed XSL stylesheets.
XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/1.76.1
XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
all: $(ALLPREQ)
pdf:
ifeq ($(DOC),brief-yoctoprojectqs)
@echo " "
@echo "ERROR: You cannot generate a PDF file for brief-yoctoprojectqs."
@echo " "
else ifeq ($(DOC),mega-manual)
@echo " "
@echo "ERROR: You cannot generate a mega-manual PDF file."
@echo " "
else
cd $(DOC); ../tools/poky-docbook-to-pdf $(DOC).xml ../template; cd ..
endif
html:
ifeq ($(DOC),mega-manual)
# See http://www.sagehill.net/docbookxsl/HtmlOutput.html
@echo " "
@echo "******** Building "$(DOC)
@echo " "
cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
@echo " "
@echo "******** Using mega-manual.sed to process external links"
@echo " "
cd $(DOC); sed -f ../tools/mega-manual.sed < mega-manual.html > mega-output.html; cd ..
@echo " "
@echo "******** Cleaning up transient file mega-output.html"
@echo " "
cd $(DOC); rm mega-manual.html; mv mega-output.html mega-manual.html; cd ..
else
# See http://www.sagehill.net/docbookxsl/HtmlOutput.html
@echo " "
@echo "******** Building "$(DOC)
@echo " "
cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
endif
tarball: html
@echo " "
@echo "******** Creating Tarball of document files"
@echo " "
cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd ..
validate:
cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd ..
publish:
@if test -f $(DOC)/$(DOC).html; \
then \
echo " "; \
echo "******** Publishing "$(DOC)".html"; \
echo " "; \
scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
else \
echo " "; \
echo $(DOC)".html missing. Generate the file first then try again."; \
echo " "; \
fi
clean:
rm -rf $(MANUALS); rm $(DOC)/$(DOC).tgz;

View File

@ -1,266 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='using-the-command-line'>
<title>Using the Command Line</title>
<para>
Recall that earlier the manual discussed how to use an existing toolchain
tarball that had been installed into the default installation
directory, <filename>/opt/poky/&DISTRO;</filename>, which is outside of the
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
(see the section "<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball)</link>".
And, that sourcing your architecture-specific environment setup script
initializes a suitable cross-toolchain development environment.
</para>
<para>
During this setup, locations for the compiler, QEMU scripts, QEMU binary,
a special version of <filename>pkgconfig</filename> and other useful
utilities are added to the <filename>PATH</filename> variable.
Also, variables to assist
<filename>pkgconfig</filename> and <filename>autotools</filename>
are also defined so that, for example, <filename>configure.sh</filename>
can find pre-generated test results for tests that need target hardware
on which to run.
You can see the
"<link linkend='setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</link>"
section for the list of cross-toolchain environment variables
established by the script.
</para>
<para>
Collectively, these conditions allow you to easily use the toolchain
outside of the OpenEmbedded build environment on both Autotools-based
projects and Makefile-based projects.
This chapter provides information for both these types of projects.
</para>
<section id='autotools-based-projects'>
<title>Autotools-Based Projects</title>
<para>
Once you have a suitable cross-toolchain installed, it is very easy to
develop a project outside of the OpenEmbedded build system.
This section presents a simple "Helloworld" example that shows how
to set up, compile, and run the project.
</para>
<section id='creating-and-running-a-project-based-on-gnu-autotools'>
<title>Creating and Running a Project Based on GNU Autotools</title>
<para>
Follow these steps to create a simple Autotools-based project:
<orderedlist>
<listitem><para><emphasis>Create your directory:</emphasis>
Create a clean directory for your project and then make
that directory your working location:
<literallayout class='monospaced'>
$ mkdir $HOME/helloworld
$ cd $HOME/helloworld
</literallayout></para></listitem>
<listitem><para><emphasis>Populate the directory:</emphasis>
Create <filename>hello.c</filename>, <filename>Makefile.am</filename>,
and <filename>configure.in</filename> files as follows:
<itemizedlist>
<listitem><para>For <filename>hello.c</filename>, include
these lines:
<literallayout class='monospaced'>
#include &lt;stdio.h&gt;
main()
{
printf("Hello World!\n");
}
</literallayout></para></listitem>
<listitem><para>For <filename>Makefile.am</filename>,
include these lines:
<literallayout class='monospaced'>
bin_PROGRAMS = hello
hello_SOURCES = hello.c
</literallayout></para></listitem>
<listitem><para>For <filename>configure.in</filename>,
include these lines:
<literallayout class='monospaced'>
AC_INIT(hello.c)
AM_INIT_AUTOMAKE(hello,0.1)
AC_PROG_CC
AC_PROG_INSTALL
AC_OUTPUT(Makefile)
</literallayout></para></listitem>
</itemizedlist></para></listitem>
<listitem><para><emphasis>Source the cross-toolchain
environment setup file:</emphasis>
Installation of the cross-toolchain creates a cross-toolchain
environment setup script in the directory that the ADT
was installed.
Before you can use the tools to develop your project, you must
source this setup script.
The script begins with the string "environment-setup" and contains
the machine architecture, which is followed by the string
"poky-linux".
Here is an example that sources a script from the
default ADT installation directory that uses the
32-bit Intel x86 Architecture and the
&DISTRO_NAME; Yocto Project release:
<literallayout class='monospaced'>
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
</literallayout></para></listitem>
<listitem><para><emphasis>Generate the local aclocal.m4
files and create the configure script:</emphasis>
The following GNU Autotools generate the local
<filename>aclocal.m4</filename> files and create the
configure script:
<literallayout class='monospaced'>
$ aclocal
$ autoconf
</literallayout></para></listitem>
<listitem><para><emphasis>Generate files needed by GNU
coding standards:</emphasis>
GNU coding standards require certain files in order for the
project to be compliant.
This command creates those files:
<literallayout class='monospaced'>
$ touch NEWS README AUTHORS ChangeLog
</literallayout></para></listitem>
<listitem><para><emphasis>Generate the configure
file:</emphasis>
This command generates the <filename>configure</filename>:
<literallayout class='monospaced'>
$ automake -a
</literallayout></para></listitem>
<listitem><para><emphasis>Cross-compile the project:</emphasis>
This command compiles the project using the cross-compiler.
The
<ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink>
environment variable provides the minimal arguments for
GNU configure:
<literallayout class='monospaced'>
$ ./configure ${CONFIGURE_FLAGS}
</literallayout></para></listitem>
<listitem><para><emphasis>Make and install the project:</emphasis>
These two commands generate and install the project into the
destination directory:
<literallayout class='monospaced'>
$ make
$ make install DESTDIR=./tmp
</literallayout></para></listitem>
<listitem><para><emphasis>Verify the installation:</emphasis>
This command is a simple way to verify the installation
of your project.
Running the command prints the architecture on which
the binary file can run.
This architecture should be the same architecture that
the installed cross-toolchain supports.
<literallayout class='monospaced'>
$ file ./tmp/usr/local/bin/hello
</literallayout></para></listitem>
<listitem><para><emphasis>Execute your project:</emphasis>
To execute the project in the shell, simply enter the name.
You could also copy the binary to the actual target hardware
and run the project there as well:
<literallayout class='monospaced'>
$ ./hello
</literallayout>
As expected, the project displays the "Hello World!" message.
</para></listitem>
</orderedlist>
</para>
</section>
<section id='passing-host-options'>
<title>Passing Host Options</title>
<para>
For an Autotools-based project, you can use the cross-toolchain by just
passing the appropriate host option to <filename>configure.sh</filename>.
The host option you use is derived from the name of the environment setup
script found in the directory in which you installed the cross-toolchain.
For example, the host option for an ARM-based target that uses the GNU EABI
is <filename>armv5te-poky-linux-gnueabi</filename>.
You will notice that the name of the script is
<filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
Thus, the following command works to update your project and
rebuild it using the appropriate cross-toolchain tools:
<literallayout class='monospaced'>
$ ./configure --host=armv5te-poky-linux-gnueabi \
--with-libtool-sysroot=<replaceable>sysroot_dir</replaceable>
</literallayout>
<note>
If the <filename>configure</filename> script results in problems recognizing the
<filename>--with-libtool-sysroot=</filename><replaceable>sysroot-dir</replaceable> option,
regenerate the script to enable the support by doing the following and then
run the script again:
<literallayout class='monospaced'>
$ libtoolize --automake
$ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
[-I <replaceable>dir_containing_your_project-specific_m4_macros</replaceable>]
$ autoconf
$ autoheader
$ automake -a
</literallayout>
</note>
</para>
</section>
</section>
<section id='makefile-based-projects'>
<title>Makefile-Based Projects</title>
<para>
For Makefile-based projects, the cross-toolchain environment variables
established by running the cross-toolchain environment setup script
are subject to general <filename>make</filename> rules.
</para>
<para>
To illustrate this, consider the following four cross-toolchain
environment variables:
<literallayout class='monospaced'>
<ulink url='&YOCTO_DOCS_REF_URL;#var-CC'>CC</ulink>=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
<ulink url='&YOCTO_DOCS_REF_URL;#var-LD'>LD</ulink>=i586-poky-linux-ld --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
<ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'>CFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
<ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'>CXXFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
</literallayout>
Now, consider the following three cases:
<itemizedlist>
<listitem><para><emphasis>Case 1 - No Variables Set in the <filename>Makefile</filename>:</emphasis>
Because these variables are not specifically set in the
<filename>Makefile</filename>, the variables retain their
values based on the environment.
</para></listitem>
<listitem><para><emphasis>Case 2 - Variables Set in the <filename>Makefile</filename>:</emphasis>
Specifically setting variables in the
<filename>Makefile</filename> during the build results in the
environment settings of the variables being overwritten.
</para></listitem>
<listitem><para><emphasis>Case 3 - Variables Set when the <filename>Makefile</filename> is Executed from the Command Line:</emphasis>
Executing the <filename>Makefile</filename> from the command
line results in the variables being overwritten with
command-line content regardless of what is being set in the
<filename>Makefile</filename>.
In this case, environment variables are not considered unless
you use the "-e" flag during the build:
<literallayout class='monospaced'>
$ make -e <replaceable>file</replaceable>
</literallayout>
If you use this flag, then the environment values of the
variables override any variables specifically set in the
<filename>Makefile</filename>.
</para></listitem>
</itemizedlist>
<note>
For the list of variables set up by the cross-toolchain environment
setup script, see the
"<link linkend='setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</link>"
section.
</note>
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,181 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='adt-intro'>
<title>The Application Development Toolkit (ADT)</title>
<para>
Part of the Yocto Project development solution is an Application Development
Toolkit (ADT).
The ADT provides you with a custom-built, cross-development
platform suited for developing a user-targeted product application.
</para>
<para>
Fundamentally, the ADT consists of the following:
<itemizedlist>
<listitem><para>An architecture-specific cross-toolchain and matching
sysroot both built by the
<ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded build system</ulink>.
The toolchain and sysroot are based on a
<ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
configuration and extensions,
which allows you to cross-develop on the host machine for the target hardware.
</para></listitem>
<listitem><para>The Eclipse IDE Yocto Plug-in.</para></listitem>
<listitem><para>The Quick EMUlator (QEMU), which lets you simulate target hardware.
</para></listitem>
<listitem><para>Various user-space tools that greatly enhance your application
development experience.</para></listitem>
</itemizedlist>
</para>
<section id='the-cross-development-toolchain'>
<title>The Cross-Development Toolchain</title>
<para>
The
<ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>Cross-Development Toolchain</ulink>
consists of a cross-compiler, cross-linker, and cross-debugger
that are used to develop user-space applications for targeted
hardware.
This toolchain is created either by running the ADT Installer
script, a toolchain installer script, or through a
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
that is based on your Metadata configuration or extension for
your targeted device.
The cross-toolchain works with a matching target sysroot.
</para>
</section>
<section id='sysroot'>
<title>Sysroot</title>
<para>
The matching target sysroot contains needed headers and libraries for generating
binaries that run on the target architecture.
The sysroot is based on the target root filesystem image that is built by
the OpenEmbedded build system and uses the same Metadata configuration
used to build the cross-toolchain.
</para>
</section>
<section id='eclipse-overview'>
<title>Eclipse Yocto Plug-in</title>
<para>
The Eclipse IDE is a popular development environment and it fully supports
development using the Yocto Project.
When you install and configure the Eclipse Yocto Project Plug-in into
the Eclipse IDE, you maximize your Yocto Project experience.
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.
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
latency data, and collection of performance data.
</para>
<para>
For information about the application development workflow that uses the Eclipse
IDE and for a detailed example of how to install and configure the Eclipse
Yocto Project Plug-in, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working Within Eclipse</ulink>" section
of the Yocto Project Development Manual.
</para>
</section>
<section id='the-qemu-emulator'>
<title>The QEMU Emulator</title>
<para>
The QEMU emulator allows you to simulate your hardware while running your
application or image.
QEMU is made available a number of ways:
<itemizedlist>
<listitem><para>
If you use the ADT Installer script to install ADT, you can
specify whether or not to install QEMU.
</para></listitem>
<listitem><para>
If you have cloned the <filename>poky</filename> Git
repository to create a
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
and you have sourced the environment setup script, QEMU is
installed and automatically available.
</para></listitem>
<listitem><para>
If you have downloaded a Yocto Project release and unpacked
it to create a
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
and you have sourced the environment setup script, QEMU is
installed and automatically available.
</para></listitem>
<listitem><para>
If you have installed the cross-toolchain tarball and you
have sourced the toolchain's setup environment script, QEMU
is also installed and automatically available.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='user-space-tools'>
<title>User-Space Tools</title>
<para>
User-space tools are included as part of the Yocto Project.
You will find these tools helpful during development.
The tools include LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust.
These tools are common development tools for the Linux platform.
<itemizedlist>
<listitem><para><emphasis>LatencyTOP:</emphasis> LatencyTOP focuses on latency
that causes skips in audio,
stutters in your desktop experience, or situations that overload your server
even when you have plenty of CPU power left.
</para></listitem>
<listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what
software is using the most power.
You can find out more about PowerTOP at
<ulink url='https://01.org/powertop/'></ulink>.</para></listitem>
<listitem><para><emphasis>OProfile:</emphasis> A system-wide profiler for Linux
systems that is capable of profiling all running code at low overhead.
You can find out more about OProfile at
<ulink url='http://oprofile.sourceforge.net/about/'></ulink>.
For examples on how to setup and use this tool, see the
"<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
section in the Yocto Project Profiling and Tracing Manual.
</para></listitem>
<listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used
to keep track of certain types of hardware and software events.
For more information on these types of counters see
<ulink url='https://perf.wiki.kernel.org/'></ulink>.
For examples on how to setup and use this tool, see the
"<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
section in the Yocto Project Profiling and Tracing Manual.
</para></listitem>
<listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure
that simplifies information gathering about a running Linux system.
This information helps you diagnose performance or functional problems.
SystemTap is not available as a user-space tool through the Eclipse IDE Yocto Plug-in.
See <ulink url='http://sourceware.org/systemtap'></ulink> for more information
on SystemTap.
For examples on how to setup and use this tool, see the
"<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-systemtap'>SystemTap</ulink>"
section in the Yocto Project Profiling and Tracing Manual.</para></listitem>
<listitem><para><emphasis>Lttng-ust:</emphasis> A User-space Tracer designed to
provide detailed information on user-space activity.
See <ulink url='http://lttng.org/ust'></ulink> for more information on Lttng-ust.
</para></listitem>
</itemizedlist>
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,28 +0,0 @@
<?xml version='1.0'?>
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<!--
<xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-->
<xsl:include href="../template/permalinks.xsl"/>
<xsl:include href="../template/section.title.xsl"/>
<xsl:include href="../template/component.title.xsl"/>
<xsl:include href="../template/division.title.xsl"/>
<xsl:include href="../template/formal.object.heading.xsl"/>
<xsl:param name="html.stylesheet" select="'adt-style.css'" />
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel" select="A" />
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
<xsl:param name="generate.id.attributes" select="1" />
</xsl:stylesheet>

View File

@ -1,37 +0,0 @@
<?xml version='1.0'?>
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
version="1.0">
<xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
<!--
<xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
<xsl:import
href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" />
-->
<xsl:param name="chunker.output.indent" select="'yes'"/>
<xsl:param name="chunk.quietly" select="1"/>
<xsl:param name="chunk.first.sections" select="1"/>
<xsl:param name="chunk.section.depth" select="10"/>
<xsl:param name="use.id.as.filename" select="1"/>
<xsl:param name="ulink.target" select="'_self'" />
<xsl:param name="base.dir" select="'html/adt-manual/'"/>
<xsl:param name="html.stylesheet" select="'../book.css'"/>
<xsl:param name="eclipse.manifest" select="0"/>
<xsl:param name="create.plugin.xml" select="0"/>
<xsl:param name="suppress.navigation" select="1"/>
<xsl:param name="generate.index" select="0"/>
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel" select="1" />
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
</xsl:stylesheet>

View File

@ -1,34 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='adt-manual-intro'>
<title>Introduction</title>
<para>
Welcome to the Yocto Project Application Developer's Guide.
This manual provides information that lets you begin developing applications
using the Yocto Project.
</para>
<para>
The Yocto Project provides an application development environment based on
an Application Development Toolkit (ADT) and the availability of stand-alone
cross-development toolchains and other tools.
This manual describes the ADT and how you can configure and install it,
how to access and use the cross-development toolchains, how to
customize the development packages installation,
how to use command-line development for both Autotools-based and
Makefile-based projects, and an introduction to the
<trademark class='trade'>Eclipse</trademark> IDE Yocto Plug-in.
<note>
The ADT is distribution-neutral and does not require the Yocto
Project reference distribution, which is called Poky.
This manual, however, uses examples that use the Poky distribution.
</note>
</para>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,141 +0,0 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<book id='adt-manual' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
<bookinfo>
<mediaobject>
<imageobject>
<imagedata fileref='figures/adt-title.png'
format='SVG'
align='left' scalefit='1' width='100%'/>
</imageobject>
</mediaobject>
<title>
Yocto Project Application Developer's Guide
</title>
<authorgroup>
<author>
<firstname>Jessica</firstname> <surname>Zhang</surname>
<affiliation>
<orgname>Intel Corporation</orgname>
</affiliation>
<email>jessica.zhang@intel.com</email>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>1.0</revnumber>
<date>6 April 2011</date>
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
</revision>
<revision>
<revnumber>1.0.1</revnumber>
<date>23 May 2011</date>
<revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>6 October 2011</date>
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.2</revnumber>
<date>April 2012</date>
<revremark>Released with the Yocto Project 1.2 Release.</revremark>
</revision>
<revision>
<revnumber>1.3</revnumber>
<date>October 2012</date>
<revremark>Released with the Yocto Project 1.3 Release.</revremark>
</revision>
<revision>
<revnumber>1.4</revnumber>
<date>April 2013</date>
<revremark>Released with the Yocto Project 1.4 Release.</revremark>
</revision>
<revision>
<revnumber>1.5</revnumber>
<date>October 2013</date>
<revremark>Released with the Yocto Project 1.5 Release.</revremark>
</revision>
<revision>
<revnumber>1.5.1</revnumber>
<date>January 2014</date>
<revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.6</revnumber>
<date>April 2014</date>
<revremark>Released with the Yocto Project 1.6 Release.</revremark>
</revision>
<revision>
<revnumber>1.7</revnumber>
<date>October 2014</date>
<revremark>Released with the Yocto Project 1.7 Release.</revremark>
</revision>
<revision>
<revnumber>1.8</revnumber>
<date>April 2015</date>
<revremark>Released with the Yocto Project 1.8 Release.</revremark>
</revision>
<revision>
<revnumber>2.0</revnumber>
<date>October 2015</date>
<revremark>Released with the Yocto Project 2.0 Release.</revremark>
</revision>
<revision>
<revnumber>2.1</revnumber>
<date>Sometime in 2016</date>
<revremark>Released with the future Yocto Project 2.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>&COPYRIGHT_YEAR;</year>
<holder>Linux Foundation</holder>
</copyright>
<legalnotice>
<para>
Permission is granted to copy, distribute and/or modify this document under
the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
</para>
<note>
For the latest version of this manual associated with this
Yocto Project release, see the
<ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>
from the Yocto Project website.
</note>
</legalnotice>
</bookinfo>
<xi:include href="adt-manual-intro.xml"/>
<xi:include href="adt-intro.xml"/>
<xi:include href="adt-prepare.xml"/>
<xi:include href="adt-package.xml"/>
<xi:include href="adt-command.xml"/>
<!-- <index id='index'>
<title>Index</title>
</index>
-->
</book>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,103 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='adt-package'>
<title>Optionally Customizing the Development Packages Installation</title>
<para>
Because the Yocto Project is suited for embedded Linux development, it is
likely that you will need to customize your development packages installation.
For example, if you are developing a minimal image, then you might not need
certain packages (e.g. graphics support packages).
Thus, you would like to be able to remove those packages from your target sysroot.
</para>
<section id='package-management-systems'>
<title>Package Management Systems</title>
<para>
The OpenEmbedded build system supports the generation of sysroot files using
three different Package Management Systems (PMS):
<itemizedlist>
<listitem><para><emphasis>OPKG:</emphasis> A less well known PMS whose use
originated in the OpenEmbedded and OpenWrt embedded Linux projects.
This PMS works with files packaged in an <filename>.ipk</filename> format.
See <ulink url='http://en.wikipedia.org/wiki/Opkg'></ulink> for more
information about OPKG.</para></listitem>
<listitem><para><emphasis>RPM:</emphasis> A more widely known PMS intended for GNU/Linux
distributions.
This PMS works with files packaged in an <filename>.rpm</filename> format.
The build system currently installs through this PMS by default.
See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
for more information about RPM.</para></listitem>
<listitem><para><emphasis>Debian:</emphasis> The PMS for Debian-based systems
is built on many PMS tools.
The lower-level PMS tool <filename>dpkg</filename> forms the base of the Debian PMS.
For information on dpkg see
<ulink url='http://en.wikipedia.org/wiki/Dpkg'></ulink>.</para></listitem>
</itemizedlist>
</para>
</section>
<section id='configuring-the-pms'>
<title>Configuring the PMS</title>
<para>
Whichever PMS you are using, you need to be sure that the
<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink>
variable in the <filename>conf/local.conf</filename>
file is set to reflect that system.
The first value you choose for the variable specifies the package file format for the root
filesystem at sysroot.
Additional values specify additional formats for convenience or testing.
See the <filename>conf/local.conf</filename> configuration file for
details.
</para>
<note>
For build performance information related to the PMS, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package.bbclass</filename></ulink>"
section in the Yocto Project Reference Manual.
</note>
<para>
As an example, consider a scenario where you are using OPKG and you want to add
the <filename>libglade</filename> package to the target sysroot.
</para>
<para>
First, you should generate the IPK file for the
<filename>libglade</filename> package and add it
into a working <filename>opkg</filename> repository.
Use these commands:
<literallayout class='monospaced'>
$ bitbake libglade
$ bitbake package-index
</literallayout>
</para>
<para>
Next, source the cross-toolchain environment setup script found in the
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
Follow that by setting up the installation destination to point to your
sysroot as <replaceable>sysroot_dir</replaceable>.
Finally, have an OPKG configuration file <replaceable>conf_file</replaceable>
that corresponds to the <filename>opkg</filename> repository you have just created.
The following command forms should now work:
<literallayout class='monospaced'>
$ opkg-cl f <replaceable>conf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> update
$ opkg-cl f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
--force-overwrite install libglade
$ opkg-cl f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
--force-overwrite install libglade-dbg
$ opkg-cl f <replaceable>conf_file&gt; -o </replaceable>sysroot_dir&gt; \
--force-overwrite install libglade-dev
</literallayout>
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

File diff suppressed because it is too large Load Diff

View File

@ -1,986 +0,0 @@
/*
SPDX-License-Identifier: CC-BY-2.0-UK
Generic XHTML / DocBook XHTML CSS Stylesheet.
Browser wrangling and typographic design by
Oyvind Kolas / pippin@gimp.org
Customised for Poky by
Matthew Allum / mallum@o-hand.com
Thanks to:
Liam R. E. Quin
William Skaggs
Jakub Steiner
Structure
---------
The stylesheet is divided into the following sections:
Positioning
Margins, paddings, width, font-size, clearing.
Decorations
Borders, style
Colors
Colors
Graphics
Graphical backgrounds
Nasty IE tweaks
Workarounds needed to make it work in internet explorer,
currently makes the stylesheet non validating, but up until
this point it is validating.
Mozilla extensions
Transparency for footer
Rounded corners on boxes
*/
/*************** /
/ Positioning /
/ ***************/
body {
font-family: Verdana, Sans, sans-serif;
min-width: 640px;
width: 80%;
margin: 0em auto;
padding: 2em 5em 5em 5em;
color: #333;
}
h1,h2,h3,h4,h5,h6,h7 {
font-family: Arial, Sans;
color: #00557D;
clear: both;
}
h1 {
font-size: 2em;
text-align: left;
padding: 0em 0em 0em 0em;
margin: 2em 0em 0em 0em;
}
h2.subtitle {
margin: 0.10em 0em 3.0em 0em;
padding: 0em 0em 0em 0em;
font-size: 1.8em;
padding-left: 20%;
font-weight: normal;
font-style: italic;
}
h2 {
margin: 2em 0em 0.66em 0em;
padding: 0.5em 0em 0em 0em;
font-size: 1.5em;
font-weight: bold;
}
h3.subtitle {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
font-size: 142.14%;
text-align: right;
}
h3 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 140%;
font-weight: bold;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: bold;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("figures/adt-title.png");
background-position: left top;
margin-top: -256px;
padding-right: 50px;
margin-left: 0px;
text-align: right;
width: 740px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
color: #333;
clear: both;
}
.author tt.email {
font-size: 66%;
}
.titlepage hr {
width: 0em;
clear: both;
}
.revhistory {
padding-top: 2em;
clear: both;
}
.toc,
.list-of-tables,
.list-of-examples,
.list-of-figures {
padding: 1.33em 0em 2.5em 0em;
color: #00557D;
}
.toc p,
.list-of-tables p,
.list-of-figures p,
.list-of-examples p {
padding: 0em 0em 0em 0em;
padding: 0em 0em 0.3em;
margin: 1.5em 0em 0em 0em;
}
.toc p b,
.list-of-tables p b,
.list-of-figures p b,
.list-of-examples p b{
font-size: 100.0%;
font-weight: bold;
}
.toc dl,
.list-of-tables dl,
.list-of-figures dl,
.list-of-examples dl {
margin: 0em 0em 0.5em 0em;
padding: 0em 0em 0em 0em;
}
.toc dt {
margin: 0em 0em 0em 0em;
padding: 0em 0em 0em 0em;
}
.toc dd {
margin: 0em 0em 0em 2.6em;
padding: 0em 0em 0em 0em;
}
div.glossary dl,
div.variablelist dl {
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
font-weight: normal;
width: 20em;
text-align: right;
}
.variablelist dl dt {
margin-top: 0.5em;
}
.glossary dl dd,
.variablelist dl dd {
margin-top: -1em;
margin-left: 25.5em;
}
.glossary dd p,
.variablelist dd p {
margin-top: 0em;
margin-bottom: 1em;
}
div.calloutlist table td {
padding: 0em 0em 0em 0em;
margin: 0em 0em 0em 0em;
}
div.calloutlist table td p {
margin-top: 0em;
margin-bottom: 1em;
}
div p.copyright {
text-align: left;
}
div.legalnotice p.legalnotice-title {
margin-bottom: 0em;
}
p {
line-height: 1.5em;
margin-top: 0em;
}
dl {
padding-top: 0em;
}
hr {
border: solid 1px;
}
.mediaobject,
.mediaobjectco {
text-align: center;
}
img {
border: none;
}
ul {
padding: 0em 0em 0em 1.5em;
}
ul li {
padding: 0em 0em 0em 0em;
}
ul li p {
text-align: left;
}
table {
width :100%;
}
th {
padding: 0.25em;
text-align: left;
font-weight: normal;
vertical-align: top;
}
td {
padding: 0.25em;
vertical-align: top;
}
p a[id] {
margin: 0px;
padding: 0px;
display: inline;
background-image: none;
}
a {
text-decoration: underline;
color: #444;
}
pre {
overflow: auto;
}
a:hover {
text-decoration: underline;
/*font-weight: bold;*/
}
/* This style defines how the permalink character
appears by itself and when hovered over with
the mouse. */
[alt='Permalink'] { color: #eee; }
[alt='Permalink']:hover { color: black; }
div.informalfigure,
div.informalexample,
div.informaltable,
div.figure,
div.table,
div.example {
margin: 1em 0em;
padding: 1em;
page-break-inside: avoid;
}
div.informalfigure p.title b,
div.informalexample p.title b,
div.informaltable p.title b,
div.figure p.title b,
div.example p.title b,
div.table p.title b{
padding-top: 0em;
margin-top: 0em;
font-size: 100%;
font-weight: normal;
}
.mediaobject .caption,
.mediaobject .caption p {
text-align: center;
font-size: 80%;
padding-top: 0.5em;
padding-bottom: 0.5em;
}
.epigraph {
padding-left: 55%;
margin-bottom: 1em;
}
.epigraph p {
text-align: left;
}
.epigraph .quote {
font-style: italic;
}
.epigraph .attribution {
font-style: normal;
text-align: right;
}
span.application {
font-style: italic;
}
.programlisting {
font-family: monospace;
font-size: 80%;
white-space: pre;
margin: 1.33em 0em;
padding: 1.33em;
}
.tip,
.warning,
.caution,
.note {
margin-top: 1em;
margin-bottom: 1em;
}
/* force full width of table within div */
.tip table,
.warning table,
.caution table,
.note table {
border: none;
width: 100%;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
padding: 0.8em 0.0em 0.0em 0.0em;
margin : 0em 0em 0em 0em;
}
.tip p,
.warning p,
.caution p,
.note p {
margin-top: 0.5em;
margin-bottom: 0.5em;
padding-right: 1em;
text-align: left;
}
.acronym {
text-transform: uppercase;
}
b.keycap,
.keycap {
padding: 0.09em 0.3em;
margin: 0em;
}
.itemizedlist li {
clear: none;
}
.filename {
font-size: medium;
font-family: Courier, monospace;
}
div.navheader, div.heading{
position: absolute;
left: 0em;
top: 0em;
width: 100%;
background-color: #cdf;
width: 100%;
}
div.navfooter, div.footing{
position: fixed;
left: 0em;
bottom: 0em;
background-color: #eee;
width: 100%;
}
div.navheader td,
div.navfooter td {
font-size: 66%;
}
div.navheader table th {
/*font-family: Georgia, Times, serif;*/
/*font-size: x-large;*/
font-size: 80%;
}
div.navheader table {
border-left: 0em;
border-right: 0em;
border-top: 0em;
width: 100%;
}
div.navfooter table {
border-left: 0em;
border-right: 0em;
border-bottom: 0em;
width: 100%;
}
div.navheader table td a,
div.navfooter table td a {
color: #777;
text-decoration: none;
}
/* normal text in the footer */
div.navfooter table td {
color: black;
}
div.navheader table td a:visited,
div.navfooter table td a:visited {
color: #444;
}
/* links in header and footer */
div.navheader table td a:hover,
div.navfooter table td a:hover {
text-decoration: underline;
background-color: transparent;
color: #33a;
}
div.navheader hr,
div.navfooter hr {
display: none;
}
.qandaset tr.question td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.qandaset tr.answer td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.answer td {
padding-bottom: 1.5em;
}
.emphasis {
font-weight: bold;
}
/************* /
/ decorations /
/ *************/
.titlepage {
}
.part .title {
}
.subtitle {
border: none;
}
/*
h1 {
border: none;
}
h2 {
border-top: solid 0.2em;
border-bottom: solid 0.06em;
}
h3 {
border-top: 0em;
border-bottom: solid 0.06em;
}
h4 {
border: 0em;
border-bottom: solid 0.06em;
}
h5 {
border: 0em;
}
*/
.programlisting {
border: solid 1px;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example {
border: 1px solid;
}
.tip,
.warning,
.caution,
.note {
border: 1px solid;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom: 1px solid;
}
.question td {
border-top: 1px solid black;
}
.answer {
}
b.keycap,
.keycap {
border: 1px solid;
}
div.navheader, div.heading{
border-bottom: 1px solid;
}
div.navfooter, div.footing{
border-top: 1px solid;
}
/********* /
/ colors /
/ *********/
body {
color: #333;
background: white;
}
a {
background: transparent;
}
a:hover {
background-color: #dedede;
}
h1,
h2,
h3,
h4,
h5,
h6,
h7,
h8 {
background-color: transparent;
}
hr {
border-color: #aaa;
}
.tip, .warning, .caution, .note {
border-color: #fff;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #fff;
}
.warning {
background-color: #f0f0f2;
}
.caution {
background-color: #f0f0f2;
}
.tip {
background-color: #f0f0f2;
}
.note {
background-color: #f0f0f2;
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
color: #044;
}
div.figure,
div.table,
div.example,
div.informalfigure,
div.informaltable,
div.informalexample {
border-color: #aaa;
}
pre.programlisting {
color: black;
background-color: #fff;
border-color: #aaa;
border-width: 2px;
}
.guimenu,
.guilabel,
.guimenuitem {
background-color: #eee;
}
b.keycap,
.keycap {
background-color: #eee;
border-color: #999;
}
div.navheader {
border-color: black;
}
div.navfooter {
border-color: black;
}
/*********** /
/ graphics /
/ ***********/
/*
body {
background-image: url("images/body_bg.jpg");
background-attachment: fixed;
}
.navheader,
.note,
.tip {
background-image: url("images/note_bg.jpg");
background-attachment: fixed;
}
.warning,
.caution {
background-image: url("images/warning_bg.jpg");
background-attachment: fixed;
}
.figure,
.informalfigure,
.example,
.informalexample,
.table,
.informaltable {
background-image: url("images/figure_bg.jpg");
background-attachment: fixed;
}
*/
h1,
h2,
h3,
h4,
h5,
h6,
h7{
}
/*
Example of how to stick an image as part of the title.
div.article .titlepage .title
{
background-image: url("figures/white-on-black.png");
background-position: center;
background-repeat: repeat-x;
}
*/
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title,
div.article .titlepage .title
{
}
div.section div.section .titlepage .title,
div.sect2 .titlepage .title {
background: none;
}
h1.title {
background-color: transparent;
background-repeat: no-repeat;
height: 256px;
text-indent: -9000px;
overflow:hidden;
}
h2.subtitle {
background-color: transparent;
text-indent: -9000px;
overflow:hidden;
width: 0px;
display: none;
}
/*************************************** /
/ pippin.gimp.org specific alterations /
/ ***************************************/
/*
div.heading, div.navheader {
color: #777;
font-size: 80%;
padding: 0;
margin: 0;
text-align: left;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 50px;
background: url('/gfx/heading_bg.png') transparent;
background-repeat: repeat-x;
background-attachment: fixed;
border: none;
}
div.heading a {
color: #444;
}
div.footing, div.navfooter {
border: none;
color: #ddd;
font-size: 80%;
text-align:right;
width: 100%;
padding-top: 10px;
position: absolute;
bottom: 0px;
left: 0px;
background: url('/gfx/footing_bg.png') transparent;
}
*/
/****************** /
/ nasty ie tweaks /
/ ******************/
/*
div.heading, div.navheader {
width:expression(document.body.clientWidth + "px");
}
div.footing, div.navfooter {
width:expression(document.body.clientWidth + "px");
margin-left:expression("-5em");
}
body {
padding:expression("4em 5em 0em 5em");
}
*/
/**************************************** /
/ mozilla vendor specific css extensions /
/ ****************************************/
/*
div.navfooter, div.footing{
-moz-opacity: 0.8em;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example,
.tip,
.warning,
.caution,
.note {
-moz-border-radius: 0.5em;
}
b.keycap,
.keycap {
-moz-border-radius: 0.3em;
}
*/
table tr td table tr td {
display: none;
}
hr {
display: none;
}
table {
border: 0em;
}
.photo {
float: right;
margin-left: 1.5em;
margin-bottom: 1.5em;
margin-top: 0em;
max-width: 17em;
border: 1px solid gray;
padding: 3px;
background: white;
}
.seperator {
padding-top: 2em;
clear: both;
}
#validators {
margin-top: 5em;
text-align: right;
color: #777;
}
@media print {
body {
font-size: 8pt;
}
.noprint {
display: none;
}
}
.tip,
.note {
background: #f0f0f2;
color: #333;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #333;
}
.tip a,
.note a {
color: #333;
text-decoration: underline;
}
.footnote {
font-size: small;
color: #333;
}
/* Changes the announcement text */
.tip h3,
.warning h3,
.caution h3,
.note h3 {
font-size:large;
color: #00557D;
}

View File

@ -1,26 +0,0 @@
<?xml version='1.0'?>
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<!--
<xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-->
<xsl:import href="brief-yoctoprojectqs-titlepage.xsl"/>
<xsl:include href="../template/permalinks.xsl"/>
<xsl:include href="../template/section.title.xsl"/>
<xsl:include href="../template/component.title.xsl"/>
<xsl:include href="../template/division.title.xsl"/>
<xsl:include href="../template/formal.object.heading.xsl"/>
<xsl:param name="generate.toc" select="'article nop'"></xsl:param>
<xsl:param name="html.stylesheet" select="'brief-yoctoprojectqs-style.css'" />
</xsl:stylesheet>

View File

@ -1,992 +0,0 @@
/*
SPDX-License-Identifier: CC-BY-2.0-UK
Generic XHTML / DocBook XHTML CSS Stylesheet.
Browser wrangling and typographic design by
Oyvind Kolas / pippin@gimp.org
Customised for Poky by
Matthew Allum / mallum@o-hand.com
Thanks to:
Liam R. E. Quin
William Skaggs
Jakub Steiner
Structure
---------
The stylesheet is divided into the following sections:
Positioning
Margins, paddings, width, font-size, clearing.
Decorations
Borders, style
Colors
Colors
Graphics
Graphical backgrounds
Nasty IE tweaks
Workarounds needed to make it work in internet explorer,
currently makes the stylesheet non validating, but up until
this point it is validating.
Mozilla extensions
Transparency for footer
Rounded corners on boxes
*/
/*************** /
/ Positioning /
/ ***************/
body {
font-family: Verdana, Sans, sans-serif;
min-width: 640px;
width: 80%;
margin: 0em auto;
padding: 2em 5em 5em 5em;
color: #333;
}
h1,h2,h3,h4,h5,h6,h7 {
font-family: Arial, Sans;
color: #00557D;
clear: both;
}
h1 {
font-size: 2em;
text-align: left;
padding: 0em 0em 0em 0em;
margin: 2em 0em 0em 0em;
}
h2.subtitle {
margin: 0.10em 0em 3.0em 0em;
padding: 0em 0em 0em 0em;
font-size: 1.8em;
padding-left: 20%;
font-weight: normal;
font-style: italic;
}
h2 {
margin: 2em 0em 0.66em 0em;
padding: 0.5em 0em 0em 0em;
font-size: 1.5em;
font-weight: bold;
}
h3.subtitle {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
font-size: 142.14%;
text-align: right;
}
h3 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 140%;
font-weight: bold;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: bold;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("figures/bypqs-title.png");
background-position: left top;
margin-top: -256px;
padding-right: 50px;
margin-left: 0px;
text-align: right;
width: 740px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
color: #333;
clear: both;
}
.author tt.email {
font-size: 66%;
}
.titlepage hr {
width: 0em;
clear: both;
}
.revhistory {
padding-top: 2em;
clear: both;
}
.toc,
.list-of-tables,
.list-of-examples,
.list-of-figures {
padding: 1.33em 0em 2.5em 0em;
color: #00557D;
}
.toc p,
.list-of-tables p,
.list-of-figures p,
.list-of-examples p {
padding: 0em 0em 0em 0em;
padding: 0em 0em 0.3em;
margin: 1.5em 0em 0em 0em;
}
.toc p b,
.list-of-tables p b,
.list-of-figures p b,
.list-of-examples p b{
font-size: 100.0%;
font-weight: bold;
}
.toc dl,
.list-of-tables dl,
.list-of-figures dl,
.list-of-examples dl {
margin: 0em 0em 0.5em 0em;
padding: 0em 0em 0em 0em;
}
.toc dt {
margin: 0em 0em 0em 0em;
padding: 0em 0em 0em 0em;
}
.toc dd {
margin: 0em 0em 0em 2.6em;
padding: 0em 0em 0em 0em;
}
div.glossary dl,
div.variablelist dl {
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
font-weight: normal;
width: 20em;
text-align: right;
}
.variablelist dl dt {
margin-top: 0.5em;
}
.glossary dl dd,
.variablelist dl dd {
margin-top: -1em;
margin-left: 25.5em;
}
.glossary dd p,
.variablelist dd p {
margin-top: 0em;
margin-bottom: 1em;
}
div.calloutlist table td {
padding: 0em 0em 0em 0em;
margin: 0em 0em 0em 0em;
}
div.calloutlist table td p {
margin-top: 0em;
margin-bottom: 1em;
}
div p.copyright {
text-align: left;
}
div.legalnotice p.legalnotice-title {
margin-bottom: 0em;
}
p {
line-height: 1.5em;
margin-top: 0em;
}
dl {
padding-top: 0em;
}
hr {
border: solid 1px;
}
.mediaobject,
.mediaobjectco {
text-align: center;
}
img {
border: none;
}
ul {
padding: 0em 0em 0em 1.5em;
}
ul li {
padding: 0em 0em 0em 0em;
}
ul li p {
text-align: left;
}
table {
width :100%;
}
th {
padding: 0.25em;
text-align: left;
font-weight: normal;
vertical-align: top;
}
td {
padding: 0.25em;
vertical-align: top;
}
p a[id] {
margin: 0px;
padding: 0px;
display: inline;
background-image: none;
}
a {
text-decoration: underline;
color: #444;
}
pre {
overflow: auto;
}
a:hover {
text-decoration: underline;
/*font-weight: bold;*/
}
/* This style defines how the permalink character
appears by itself and when hovered over with
the mouse. */
[alt='Permalink'] { color: #eee; }
[alt='Permalink']:hover { color: black; }
div.informalfigure,
div.informalexample,
div.informaltable,
div.figure,
div.table,
div.example {
margin: 1em 0em;
padding: 1em;
page-break-inside: avoid;
}
div.informalfigure p.title b,
div.informalexample p.title b,
div.informaltable p.title b,
div.figure p.title b,
div.example p.title b,
div.table p.title b{
padding-top: 0em;
margin-top: 0em;
font-size: 100%;
font-weight: normal;
}
.mediaobject .caption,
.mediaobject .caption p {
text-align: center;
font-size: 80%;
padding-top: 0.5em;
padding-bottom: 0.5em;
}
.epigraph {
padding-left: 55%;
margin-bottom: 1em;
}
.epigraph p {
text-align: left;
}
.epigraph .quote {
font-style: italic;
}
.epigraph .attribution {
font-style: normal;
text-align: right;
}
span.application {
font-style: italic;
}
.programlisting {
font-family: monospace;
font-size: 80%;
white-space: pre;
margin: 1.33em 0em;
padding: 1.33em;
}
.tip,
.warning,
.caution,
.note {
margin-top: 1em;
margin-bottom: 1em;
}
/* force full width of table within div */
.tip table,
.warning table,
.caution table,
.note table {
border: none;
width: 100%;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
padding: 0.8em 0.0em 0.0em 0.0em;
margin : 0em 0em 0em 0em;
}
.tip p,
.warning p,
.caution p,
.note p {
margin-top: 0.5em;
margin-bottom: 0.5em;
padding-right: 1em;
text-align: left;
}
.acronym {
text-transform: uppercase;
}
b.keycap,
.keycap {
padding: 0.09em 0.3em;
margin: 0em;
}
.itemizedlist li {
clear: none;
}
.filename {
font-size: medium;
font-family: Courier, monospace;
}
div.navheader, div.heading{
position: absolute;
left: 0em;
top: 0em;
width: 100%;
background-color: #cdf;
width: 100%;
}
div.navfooter, div.footing{
position: fixed;
left: 0em;
bottom: 0em;
background-color: #eee;
width: 100%;
}
div.navheader td,
div.navfooter td {
font-size: 66%;
}
div.navheader table th {
/*font-family: Georgia, Times, serif;*/
/*font-size: x-large;*/
font-size: 80%;
}
div.navheader table {
border-left: 0em;
border-right: 0em;
border-top: 0em;
width: 100%;
}
div.navfooter table {
border-left: 0em;
border-right: 0em;
border-bottom: 0em;
width: 100%;
}
div.navheader table td a,
div.navfooter table td a {
color: #777;
text-decoration: none;
}
/* normal text in the footer */
div.navfooter table td {
color: black;
}
div.navheader table td a:visited,
div.navfooter table td a:visited {
color: #444;
}
/* links in header and footer */
div.navheader table td a:hover,
div.navfooter table td a:hover {
text-decoration: underline;
background-color: transparent;
color: #33a;
}
div.navheader hr,
div.navfooter hr {
display: none;
}
.qandaset tr.question td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.qandaset tr.answer td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.answer td {
padding-bottom: 1.5em;
}
.emphasis {
font-weight: bold;
}
/************* /
/ decorations /
/ *************/
.titlepage {
}
.part .title {
}
.subtitle {
border: none;
}
/*
h1 {
border: none;
}
h2 {
border-top: solid 0.2em;
border-bottom: solid 0.06em;
}
h3 {
border-top: 0em;
border-bottom: solid 0.06em;
}
h4 {
border: 0em;
border-bottom: solid 0.06em;
}
h5 {
border: 0em;
}
*/
.programlisting {
border: solid 1px;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example {
border: 1px solid;
}
.tip,
.warning,
.caution,
.note {
border: 1px solid;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom: 1px solid;
}
.question td {
border-top: 1px solid black;
}
.answer {
}
b.keycap,
.keycap {
border: 1px solid;
}
div.navheader, div.heading{
border-bottom: 1px solid;
}
div.navfooter, div.footing{
border-top: 1px solid;
}
/********* /
/ colors /
/ *********/
body {
color: #333;
background: white;
}
a {
background: transparent;
}
a:hover {
background-color: #dedede;
}
h1,
h2,
h3,
h4,
h5,
h6,
h7,
h8 {
background-color: transparent;
}
hr {
border-color: #aaa;
}
.tip, .warning, .caution, .note {
border-color: #fff;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #fff;
}
.warning {
background-color: #f0f0f2;
}
.caution {
background-color: #f0f0f2;
}
.tip {
background-color: #f0f0f2;
}
.note {
background-color: #f0f0f2;
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
color: #044;
}
div.figure,
div.table,
div.example,
div.informalfigure,
div.informaltable,
div.informalexample {
border-color: #aaa;
}
pre.programlisting {
color: black;
background-color: #fff;
border-color: #aaa;
border-width: 2px;
}
.guimenu,
.guilabel,
.guimenuitem {
background-color: #eee;
}
b.keycap,
.keycap {
background-color: #eee;
border-color: #999;
}
div.navheader {
border-color: black;
}
div.navfooter {
border-color: black;
}
.writernotes {
color: red;
}
/*********** /
/ graphics /
/ ***********/
/*
body {
background-image: url("images/body_bg.jpg");
background-attachment: fixed;
}
.navheader,
.note,
.tip {
background-image: url("images/note_bg.jpg");
background-attachment: fixed;
}
.warning,
.caution {
background-image: url("images/warning_bg.jpg");
background-attachment: fixed;
}
.figure,
.informalfigure,
.example,
.informalexample,
.table,
.informaltable {
background-image: url("images/figure_bg.jpg");
background-attachment: fixed;
}
*/
h1,
h2,
h3,
h4,
h5,
h6,
h7{
}
/*
Example of how to stick an image as part of the title.
div.article .titlepage .title
{
background-image: url("figures/white-on-black.png");
background-position: center;
background-repeat: repeat-x;
}
*/
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title {
background-position: bottom;
background-repeat: repeat-x;
}
div.section div.section .titlepage .title,
div.sect2 .titlepage .title {
background: none;
}
h1.title {
background-color: transparent;
background-repeat: no-repeat;
height: 256px;
text-indent: -9000px;
overflow:hidden;
}
h2.subtitle {
background-color: transparent;
text-indent: -9000px;
overflow:hidden;
width: 0px;
display: none;
}
/*************************************** /
/ pippin.gimp.org specific alterations /
/ ***************************************/
/*
div.heading, div.navheader {
color: #777;
font-size: 80%;
padding: 0;
margin: 0;
text-align: left;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 50px;
background: url('/gfx/heading_bg.png') transparent;
background-repeat: repeat-x;
background-attachment: fixed;
border: none;
}
div.heading a {
color: #444;
}
div.footing, div.navfooter {
border: none;
color: #ddd;
font-size: 80%;
text-align:right;
width: 100%;
padding-top: 10px;
position: absolute;
bottom: 0px;
left: 0px;
background: url('/gfx/footing_bg.png') transparent;
}
*/
/****************** /
/ nasty ie tweaks /
/ ******************/
/*
div.heading, div.navheader {
width:expression(document.body.clientWidth + "px");
}
div.footing, div.navfooter {
width:expression(document.body.clientWidth + "px");
margin-left:expression("-5em");
}
body {
padding:expression("4em 5em 0em 5em");
}
*/
/**************************************** /
/ mozilla vendor specific css extensions /
/ ****************************************/
/*
div.navfooter, div.footing{
-moz-opacity: 0.8em;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example,
.tip,
.warning,
.caution,
.note {
-moz-border-radius: 0.5em;
}
b.keycap,
.keycap {
-moz-border-radius: 0.3em;
}
*/
table tr td table tr td {
display: none;
}
hr {
display: none;
}
table {
border: 0em;
}
.photo {
float: right;
margin-left: 1.5em;
margin-bottom: 1.5em;
margin-top: 0em;
max-width: 17em;
border: 1px solid gray;
padding: 3px;
background: white;
}
.seperator {
padding-top: 2em;
clear: both;
}
#validators {
margin-top: 5em;
text-align: right;
color: #777;
}
@media print {
body {
font-size: 8pt;
}
.noprint {
display: none;
}
}
.tip,
.note {
background: #f0f0f2;
color: #333;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #333;
}
.tip a,
.note a {
color: #333;
text-decoration: underline;
}
.footnote {
font-size: small;
color: #333;
}
/* Changes the announcement text */
.tip h3,
.warning h3,
.caution h3,
.note h3 {
font-size:large;
color: #00557D;
}

View File

@ -1,577 +0,0 @@
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<article id='brief-yocto-project-qs-intro'>
<articleinfo>
<title>Yocto Project Quick Build</title>
<copyright>
<year>&COPYRIGHT_YEAR;</year>
<holder>Linux Foundation</holder>
</copyright>
<legalnotice>
<para>
Permission is granted to copy, distribute and/or modify this document under
the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
</para>
</legalnotice>
<abstract>
<imagedata fileref="figures/yocto-project-transp.png"
width="6in" depth="1in"
align="right" scale="25" />
</abstract>
</articleinfo>
<section id='brief-welcome'>
<title>Welcome!</title>
<para>
Welcome!
This short document steps you through the process for a typical
image build using the Yocto Project.
The document also introduces how to configure a build for specific
hardware.
You will use Yocto Project to build a reference embedded OS
called Poky.
<note><title>Notes</title>
<itemizedlist>
<listitem><para>
The examples in this paper assume you are using a
native Linux system running a recent Ubuntu Linux
distribution.
If the machine you want to use Yocto Project on to
build an image
(<ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>)
is not a native Linux system, you can
still perform these steps by using CROss PlatformS
(CROPS) and setting up a Poky container.
See the
<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>"
section in the Yocto Project Development Tasks Manual for more
information.
</para></listitem>
<listitem><para>
You may use Windows Subsystem For Linux v2 to set up a build
host using Windows 10.
<note>
The Yocto Project is not compatible with WSLv1, it is
compatible but not officially supported nor validated
with WSLv2, if you still decide to use WSL please upgrade
to WSLv2.
</note>
See the
<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>"
section in the Yocto Project Development Tasks Manual for more
information.
</para></listitem>
</itemizedlist>
</note>
</para>
<para>
If you want more conceptual or background information on the
Yocto Project, see the
<ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>.
</para>
</section>
<section id='brief-compatible-distro'>
<title>Compatible Linux Distribution</title>
<para>
Make sure your
<ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
meets the following requirements:
<itemizedlist>
<listitem><para>
50 Gbytes of free disk space
</para></listitem>
<listitem><para>
Runs a supported Linux distribution (i.e. recent releases of
Fedora, openSUSE, CentOS, Debian, or Ubuntu). For a list of
Linux distributions that support the Yocto Project, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
section in the Yocto Project Reference Manual.
For detailed information on preparing your build host, see
the
"<ulink url='&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host'>Preparing the Build Host</ulink>"
section in the Yocto Project Development Tasks Manual.
</para></listitem>
<listitem><para>
<itemizedlist>
<listitem><para>
Git 1.8.3.1 or greater
</para></listitem>
<listitem><para>
tar 1.28 or greater
</para></listitem>
<listitem><para>
Python 3.5.0 or greater.
</para></listitem>
<listitem><para>
gcc 5.0 or greater.
</para></listitem>
</itemizedlist>
If your build host does not meet any of these three listed
version requirements, you can take steps to prepare the
system so that you can still use the Yocto Project.
See the
"<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</ulink>"
section in the Yocto Project Reference Manual for information.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='brief-build-system-packages'>
<title>Build Host Packages</title>
<para>
You must install essential host packages on your
build host.
The following command installs the host packages based on an
Ubuntu distribution:
<note>
For host package requirements on all supported Linux
distributions, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-build-host'>Required Packages for the Build Host</ulink>"
section in the Yocto Project Reference Manual.
</note>
<literallayout class='monospaced'>
$ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
</literallayout>
</para>
</section>
<section id='brief-use-git-to-clone-poky'>
<title>Use Git to Clone Poky</title>
<para>
Once you complete the setup instructions for your machine,
you need to get a copy of the Poky repository on your build
host.
Use the following commands to clone the Poky
repository.
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/poky
Cloning into 'poky'...
remote: Counting objects: 432160, done.
remote: Compressing objects: 100% (102056/102056), done.
remote: Total 432160 (delta 323116), reused 432037 (delta 323000)
Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done.
Resolving deltas: 100% (323116/323116), done.
Checking connectivity... done.
</literallayout>
Move to the <filename>poky</filename> directory and take a look
at the tags:
<literallayout class='monospaced'>
$ cd poky
$ git fetch --tags
$ git tag
1.1_M1.final
1.1_M1.rc1
1.1_M1.rc2
1.1_M2.final
1.1_M2.rc1
.
.
.
yocto-2.5
yocto-2.5.1
yocto-2.5.2
yocto-2.6
yocto-2.6.1
yocto-2.6.2
yocto-2.7
yocto_1.5_M5.rc8
</literallayout>
For this example, check out the branch based on the
&DISTRO_REL_TAG; release:
<literallayout class='monospaced'>
$ git checkout tags/&DISTRO_REL_TAG; -b my-&DISTRO_REL_TAG;
Switched to a new branch 'my-&DISTRO_REL_TAG;'
</literallayout>
The previous Git checkout command creates a local branch
named my-&DISTRO_REL_TAG;. The files available to you in that
branch exactly match the repository's files in the
"&DISTRO_NAME_NO_CAP;" development branch at the time of the
Yocto Project &DISTRO_REL_TAG; release.
</para>
<para>
For more options and information about accessing Yocto
Project related repositories, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files'>Locating Yocto Project Source Files</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</section>
<section id='brief-building-your-image'>
<title>Building Your Image</title>
<para>
Use the following steps to build your image.
The build process creates an entire Linux distribution, including
the toolchain, from source.
<note>
<itemizedlist>
<listitem><para>
If you are working behind a firewall and your build
host is not set up for proxies, you could encounter
problems with the build process when fetching source
code (e.g. fetcher failures or Git failures).
</para></listitem>
<listitem><para>
If you do not know your proxy settings, consult your
local network infrastructure resources and get that
information.
A good starting point could also be to check your
web browser settings.
Finally, you can find more information on the
"<ulink url='https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
page of the Yocto Project Wiki.
</para></listitem>
</itemizedlist>
</note>
</para>
<para>
<orderedlist>
<listitem><para>
<emphasis>Initialize the Build Environment:</emphasis>
From within the <filename>poky</filename> directory, run the
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
environment setup script to define Yocto Project's
build environment on your build host.
<literallayout class='monospaced'>
$ cd ~/poky
$ source &OE_INIT_FILE;
You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to, for
example, select a different MACHINE (target hardware). See conf/local.conf
for more information as common configuration options are commented.
You had no conf/bblayers.conf file. This configuration file has therefore been
created for you with some default values. To add additional metadata layers
into your configuration please add entries to conf/bblayers.conf.
The Yocto Project has extensive documentation about OE including a reference
manual which can be found at:
http://yoctoproject.org/documentation
For more information about OpenEmbedded see their website:
http://www.openembedded.org/
### Shell environment set up for builds. ###
You can now run 'bitbake &lt;target&gt;'
Common targets are:
core-image-minimal
core-image-sato
meta-toolchain
meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86-64'
</literallayout>
Among other things, the script creates the
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
which is <filename>build</filename> in this case
and is located in the
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
After the script runs, your current working directory
is set to the Build Directory.
Later, when the build completes, the Build Directory
contains all the files created during the build.
</para></listitem>
<listitem><para id='conf-file-step'>
<emphasis>Examine Your Local Configuration File:</emphasis>
When you set up the build environment, a local
configuration file named
<filename>local.conf</filename> becomes available in
a <filename>conf</filename> subdirectory of the
Build Directory.
For this example, the defaults are set to build
for a <filename>qemux86</filename> target, which is
suitable for emulation.
The package manager used is set to the RPM package
manager.
<tip>
You can significantly speed up your build and guard
against fetcher failures by using mirrors.
To use mirrors, add these lines to your
<filename>local.conf</filename> file in the Build
directory:
<literallayout class='monospaced'>
SSTATE_MIRRORS = "\
file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH \n \
file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION_MINUS_ONE;/PATH;downloadfilename=PATH \n \
file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH \n \
"
</literallayout>
The previous examples showed how to add sstate
paths for Yocto Project &YOCTO_DOC_VERSION_MINUS_ONE;,
&YOCTO_DOC_VERSION;, and a development area.
For a complete index of sstate locations, see
<ulink url='http://sstate.yoctoproject.org/'></ulink>.
</tip>
</para></listitem>
<listitem><para>
<emphasis>Start the Build:</emphasis>
Continue with the following command to build an OS image
for the target, which is
<filename>core-image-sato</filename> in this example:
<literallayout class='monospaced'>
$ bitbake core-image-sato
</literallayout>
For information on using the
<filename>bitbake</filename> command, see the
"<ulink url='&YOCTO_DOCS_OM_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
section in the Yocto Project Overview and Concepts Manual,
or see the
"<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
section in the BitBake User Manual.
</para></listitem>
<listitem><para>
<emphasis>Simulate Your Image Using QEMU:</emphasis>
Once this particular image is built, you can start
QEMU, which is a Quick EMUlator that ships with
the Yocto Project:
<literallayout class='monospaced'>
$ runqemu qemux86-64
</literallayout>
If you want to learn more about running QEMU, see the
"<ulink url="&YOCTO_DOCS_DEV_URL;#dev-manual-qemu">Using the Quick EMUlator (QEMU)</ulink>"
chapter in the Yocto Project Development Tasks Manual.
</para></listitem>
<listitem><para>
<emphasis>Exit QEMU:</emphasis>
Exit QEMU by either clicking on the shutdown icon or by
typing <filename>Ctrl-C</filename> in the QEMU
transcript window from which you evoked QEMU.
</para></listitem>
</orderedlist>
</para>
</section>
<section id='customizing-your-build-for-specific-hardware'>
<title>Customizing Your Build for Specific Hardware</title>
<para>
So far, all you have done is quickly built an image suitable
for emulation only.
This section shows you how to customize your build for specific
hardware by adding a hardware layer into the Yocto Project
development environment.
</para>
<para>
In general, layers are repositories that contain related sets of
instructions and configurations that tell the Yocto Project what
to do.
Isolating related metadata into functionally specific layers
facilitates modular development and makes it easier to reuse the
layer metadata.
<note>
By convention, layer names start with the string "meta-".
</note>
</para>
<para>
Follow these steps to add a hardware layer:
<orderedlist>
<listitem><para>
<emphasis>Find a Layer:</emphasis>
Lots of hardware layers exist.
The Yocto Project
<ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
has many hardware layers.
This example adds the
<ulink url='https://github.com/kraj/meta-altera'>meta-altera</ulink>
hardware layer.
</para></listitem>
<listitem><para>
<emphasis>Clone the Layer</emphasis>
Use Git to make a local copy of the layer on your machine.
You can put the copy in the top level of the copy of the
Poky repository created earlier:
<literallayout class='monospaced'>
$ cd ~/poky
$ git clone https://github.com/kraj/meta-altera.git
Cloning into 'meta-altera'...
remote: Counting objects: 25170, done.
remote: Compressing objects: 100% (350/350), done.
remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219
Receiving objects: 100% (25170/25170), 41.02 MiB | 1.64 MiB/s, done.
Resolving deltas: 100% (13385/13385), done.
Checking connectivity... done.
</literallayout>
The hardware layer now exists with other layers inside
the Poky reference repository on your build host as
<filename>meta-altera</filename> and contains all the
metadata needed to support hardware from Altera, which
is owned by Intel.
</para></listitem>
<listitem><para>
<emphasis>Change the Configuration to Build for a Specific Machine:</emphasis>
The
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
variable in the <filename>local.conf</filename> file
specifies the machine for the build.
For this example, set the <filename>MACHINE</filename>
variable to "cyclone5".
These configurations are used:
<ulink url='https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf'></ulink>.
<note>
See the
"<link linkend='conf-file-step'>Examine Your Local Configuration File</link>"
step earlier for more information on configuring the
build.
</note>
</para></listitem>
<listitem><para>
<emphasis>Add Your Layer to the Layer Configuration File:</emphasis>
Before you can use a layer during a build, you must add it
to your <filename>bblayers.conf</filename> file, which
is found in the
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory's</ulink>
<filename>conf</filename> directory.</para>
<para>Use the <filename>bitbake-layers add-layer</filename>
command to add the layer to the configuration file:
<literallayout class='monospaced'>
$ cd ~/poky/build
$ bitbake-layers add-layer ../meta-altera
NOTE: Starting bitbake server...
Parsing recipes: 100% |##################################################################| Time: 0:00:32
Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets, 123 skipped, 0 masked, 0 errors.
</literallayout>
You can find more information on adding layers in the
"<ulink url='&YOCTO_DOCS_DEV_URL;#adding-a-layer-using-the-bitbake-layers-script'>Adding a Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
section.
</para></listitem>
</orderedlist>
Completing these steps has added the
<filename>meta-altera</filename> layer to your Yocto Project
development environment and configured it to build for the
"cyclone5" machine.
<note>
The previous steps are for demonstration purposes only.
If you were to attempt to build an image for the
"cyclone5" build, you should read the Altera
<filename>README</filename>.
</note>
</para>
</section>
<section id='creating-your-own-general-layer'>
<title>Creating Your Own General Layer</title>
<para>
Maybe you have an application or specific set of behaviors you
need to isolate.
You can create your own general layer using the
<filename>bitbake-layers create-layer</filename> command.
The tool automates layer creation by setting up a
subdirectory with a <filename>layer.conf</filename>
configuration file, a <filename>recipes-example</filename>
subdirectory that contains an <filename>example.bb</filename>
recipe, a licensing file, and a <filename>README</filename>.
</para>
<para>
The following commands run the tool to create a layer named
<filename>meta-mylayer</filename> in the
<filename>poky</filename> directory:
<literallayout class='monospaced'>
$ cd ~/poky
$ bitbake-layers create-layer meta-mylayer
NOTE: Starting bitbake server...
Add your new layer with 'bitbake-layers add-layer meta-mylayer'
</literallayout>
For more information on layers and how to create them, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</section>
<section id='brief-where-to-go-next'>
<title>Where To Go Next</title>
<para>
Now that you have experienced using the Yocto Project, you might
be asking yourself "What now?"
The Yocto Project has many sources of information including
the website, wiki pages, and user manuals:
<itemizedlist>
<listitem><para>
<emphasis>Website:</emphasis>
The
<ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
provides background information, the latest builds,
breaking news, full development documentation, and
access to a rich Yocto Project Development Community
into which you can tap.
</para></listitem>
<listitem><para>
<emphasis>Developer Screencast:</emphasis>
The
<ulink url='http://vimeo.com/36450321'>Getting Started with the Yocto Project - New Developer Screencast Tutorial</ulink>
provides a 30-minute video created for users unfamiliar
with the Yocto Project but familiar with Linux build
hosts.
While this screencast is somewhat dated, the
introductory and fundamental concepts are useful for
the beginner.
</para></listitem>
<listitem><para>
<emphasis>Yocto Project Overview and Concepts Manual:</emphasis>
The
<ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>
is a great place to start to learn about the
Yocto Project.
This manual introduces you to the Yocto Project and its
development environment.
The manual also provides conceptual information for
various aspects of the Yocto Project.
</para></listitem>
<listitem><para>
<emphasis>Yocto Project Wiki:</emphasis>
The
<ulink url='&YOCTO_WIKI_URL;'>Yocto Project Wiki</ulink>
provides additional information on where to go next
when ramping up with the Yocto Project, release
information, project planning, and QA information.
</para></listitem>
<listitem><para>
<emphasis>Yocto Project Mailing Lists:</emphasis>
Related mailing lists provide a forum for discussion,
patch submission and announcements.
Several mailing lists exist and are grouped according
to areas of concern.
See the
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>"
section in the Yocto Project Reference Manual for a
complete list of Yocto Project mailing lists.
</para></listitem>
<listitem><para>
<emphasis>Comprehensive List of Links and Other Documentation:</emphasis>
The
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-links-and-related-documentation'>Links and Related Documentation</ulink>"
section in the Yocto Project Reference Manual provides a
comprehensive list of all related links and other
user documentation.
</para></listitem>
</itemizedlist>
</para>
</section>
</article>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,29 +0,0 @@
<?xml version='1.0'?>
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<!--
<xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-->
<xsl:include href="../template/permalinks.xsl"/>
<xsl:include href="../template/section.title.xsl"/>
<xsl:include href="../template/component.title.xsl"/>
<xsl:include href="../template/division.title.xsl"/>
<xsl:include href="../template/formal.object.heading.xsl"/>
<xsl:param name="html.stylesheet" select="'bsp-style.css'" />
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel" select="A" />
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
<xsl:param name="generate.id.attributes" select="1" />
</xsl:stylesheet>

View File

@ -1,202 +0,0 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<book id='bsp-guide' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
<bookinfo>
<mediaobject>
<imageobject>
<imagedata fileref='figures/bsp-title.png'
format='SVG'
align='center' scalefit='1' width='100%'/>
</imageobject>
</mediaobject>
<title>
Yocto Project Board Support Package Developer's Guide
</title>
<authorgroup>
<author>
<affiliation>
<orgname>&ORGNAME;</orgname>
</affiliation>
<email>&ORGEMAIL;</email>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>0.9</revnumber>
<date>November 2010</date>
<revremark>The initial document released with the Yocto Project 0.9 Release.</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>April 2011</date>
<revremark>Released with the Yocto Project 1.0 Release.</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>October 2011</date>
<revremark>Released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.2</revnumber>
<date>April 2012</date>
<revremark>Released with the Yocto Project 1.2 Release.</revremark>
</revision>
<revision>
<revnumber>1.3</revnumber>
<date>October 2012</date>
<revremark>Released with the Yocto Project 1.3 Release.</revremark>
</revision>
<revision>
<revnumber>1.4</revnumber>
<date>April 2013</date>
<revremark>Released with the Yocto Project 1.4 Release.</revremark>
</revision>
<revision>
<revnumber>1.5</revnumber>
<date>October 2013</date>
<revremark>Released with the Yocto Project 1.5 Release.</revremark>
</revision>
<revision>
<revnumber>1.6</revnumber>
<date>April 2014</date>
<revremark>Released with the Yocto Project 1.6 Release.</revremark>
</revision>
<revision>
<revnumber>1.7</revnumber>
<date>October 2014</date>
<revremark>Released with the Yocto Project 1.7 Release.</revremark>
</revision>
<revision>
<revnumber>1.8</revnumber>
<date>April 2015</date>
<revremark>Released with the Yocto Project 1.8 Release.</revremark>
</revision>
<revision>
<revnumber>2.0</revnumber>
<date>October 2015</date>
<revremark>Released with the Yocto Project 2.0 Release.</revremark>
</revision>
<revision>
<revnumber>2.1</revnumber>
<date>April 2016</date>
<revremark>Released with the Yocto Project 2.1 Release.</revremark>
</revision>
<revision>
<revnumber>2.2</revnumber>
<date>October 2016</date>
<revremark>Released with the Yocto Project 2.2 Release.</revremark>
</revision>
<revision>
<revnumber>2.3</revnumber>
<date>May 2017</date>
<revremark>Released with the Yocto Project 2.3 Release.</revremark>
</revision>
<revision>
<revnumber>2.4</revnumber>
<date>October 2017</date>
<revremark>Released with the Yocto Project 2.4 Release.</revremark>
</revision>
<revision>
<revnumber>2.5</revnumber>
<date>May 2018</date>
<revremark>Released with the Yocto Project 2.5 Release.</revremark>
</revision>
<revision>
<revnumber>2.6</revnumber>
<date>November 2018</date>
<revremark>Released with the Yocto Project 2.6 Release.</revremark>
</revision>
<revision>
<revnumber>2.7</revnumber>
<date>May 2019</date>
<revremark>Released with the Yocto Project 2.7 Release.</revremark>
</revision>
<revision>
<revnumber>3.0</revnumber>
<date>October 2019</date>
<revremark>Released with the Yocto Project 3.0 Release.</revremark>
</revision>
<revision>
<revnumber>3.1</revnumber>
<date>&REL_MONTH_YEAR;</date>
<revremark>Released with the Yocto Project 3.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>&COPYRIGHT_YEAR;</year>
<holder>Linux Foundation</holder>
</copyright>
<legalnotice>
<para>
Permission is granted to copy, distribute and/or modify this document under
the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-nc-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
</para>
<note><title>Manual Notes</title>
<itemizedlist>
<listitem><para>
This version of the
<emphasis>Yocto Project Board Support Package (BSP) Developer's Guide</emphasis>
is for the &YOCTO_DOC_VERSION; release of the
Yocto Project.
To be sure you have the latest version of the manual
for this release, go to the
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
and select the manual from that site.
Manuals from the site are more up-to-date than manuals
derived from the Yocto Project released TAR files.
</para></listitem>
<listitem><para>
If you located this manual through a web search, the
version of the manual might not be the one you want
(e.g. the search might have returned a manual much
older than the Yocto Project version with which you
are working).
You can see all Yocto Project major releases by
visiting the
<ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
page.
If you need a version of this manual for a different
Yocto Project release, visit the
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
and select the manual set by using the
"ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
pull-down menus.
</para></listitem>
<listitem>
<para>
To report any inaccuracies or problems with this
(or any other Yocto Project) manual, send an email to
the Yocto Project documentation mailing list at
<filename>docs@lists.yoctoproject.org</filename> or
log into the freenode <filename>#yocto</filename> channel.
</para>
</listitem>
</itemizedlist>
</note>
</legalnotice>
</bookinfo>
<xi:include href="bsp.xml"/>
<!-- <index id='index'>
<title>Index</title>
</index>
-->
</book>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,989 +0,0 @@
/*
SPDX-License-Identifier: CC-BY-2.0-UK
Generic XHTML / DocBook XHTML CSS Stylesheet.
Browser wrangling and typographic design by
Oyvind Kolas / pippin@gimp.org
Customised for Poky by
Matthew Allum / mallum@o-hand.com
Thanks to:
Liam R. E. Quin
William Skaggs
Jakub Steiner
Structure
---------
The stylesheet is divided into the following sections:
Positioning
Margins, paddings, width, font-size, clearing.
Decorations
Borders, style
Colors
Colors
Graphics
Graphical backgrounds
Nasty IE tweaks
Workarounds needed to make it work in internet explorer,
currently makes the stylesheet non validating, but up until
this point it is validating.
Mozilla extensions
Transparency for footer
Rounded corners on boxes
*/
/*************** /
/ Positioning /
/ ***************/
body {
font-family: Verdana, Sans, sans-serif;
min-width: 640px;
width: 80%;
margin: 0em auto;
padding: 2em 5em 5em 5em;
color: #333;
}
h1,h2,h3,h4,h5,h6,h7 {
font-family: Arial, Sans;
color: #00557D;
clear: both;
}
h1 {
font-size: 2em;
text-align: left;
padding: 0em 0em 0em 0em;
margin: 2em 0em 0em 0em;
}
h2.subtitle {
margin: 0.10em 0em 3.0em 0em;
padding: 0em 0em 0em 0em;
font-size: 1.8em;
padding-left: 20%;
font-weight: normal;
font-style: italic;
}
h2 {
margin: 2em 0em 0.66em 0em;
padding: 0.5em 0em 0em 0em;
font-size: 1.5em;
font-weight: bold;
}
h3.subtitle {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
font-size: 142.14%;
text-align: right;
}
h3 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 140%;
font-weight: bold;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: bold;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("figures/bsp-title.png");
background-position: left top;
margin-top: -256px;
padding-right: 50px;
margin-left: 0px;
text-align: right;
width: 740px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
color: #333;
clear: both;
}
.author tt.email {
font-size: 66%;
}
.titlepage hr {
width: 0em;
clear: both;
}
.revhistory {
padding-top: 2em;
clear: both;
}
.toc,
.list-of-tables,
.list-of-examples,
.list-of-figures {
padding: 1.33em 0em 2.5em 0em;
color: #00557D;
}
.toc p,
.list-of-tables p,
.list-of-figures p,
.list-of-examples p {
padding: 0em 0em 0em 0em;
padding: 0em 0em 0.3em;
margin: 1.5em 0em 0em 0em;
}
.toc p b,
.list-of-tables p b,
.list-of-figures p b,
.list-of-examples p b{
font-size: 100.0%;
font-weight: bold;
}
.toc dl,
.list-of-tables dl,
.list-of-figures dl,
.list-of-examples dl {
margin: 0em 0em 0.5em 0em;
padding: 0em 0em 0em 0em;
}
.toc dt {
margin: 0em 0em 0em 0em;
padding: 0em 0em 0em 0em;
}
.toc dd {
margin: 0em 0em 0em 2.6em;
padding: 0em 0em 0em 0em;
}
div.glossary dl,
div.variablelist dl {
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
font-weight: normal;
width: 20em;
text-align: right;
}
.variablelist dl dt {
margin-top: 0.5em;
}
.glossary dl dd,
.variablelist dl dd {
margin-top: -1em;
margin-left: 25.5em;
}
.glossary dd p,
.variablelist dd p {
margin-top: 0em;
margin-bottom: 1em;
}
div.calloutlist table td {
padding: 0em 0em 0em 0em;
margin: 0em 0em 0em 0em;
}
div.calloutlist table td p {
margin-top: 0em;
margin-bottom: 1em;
}
div p.copyright {
text-align: left;
}
div.legalnotice p.legalnotice-title {
margin-bottom: 0em;
}
p {
line-height: 1.5em;
margin-top: 0em;
}
dl {
padding-top: 0em;
}
hr {
border: solid 1px;
}
.mediaobject,
.mediaobjectco {
text-align: center;
}
img {
border: none;
}
ul {
padding: 0em 0em 0em 1.5em;
}
ul li {
padding: 0em 0em 0em 0em;
}
ul li p {
text-align: left;
}
table {
width :100%;
}
th {
padding: 0.25em;
text-align: left;
font-weight: normal;
vertical-align: top;
}
td {
padding: 0.25em;
vertical-align: top;
}
p a[id] {
margin: 0px;
padding: 0px;
display: inline;
background-image: none;
}
a {
text-decoration: underline;
color: #444;
}
pre {
overflow: auto;
}
a:hover {
text-decoration: underline;
/*font-weight: bold;*/
}
/* This style defines how the permalink character
appears by itself and when hovered over with
the mouse. */
[alt='Permalink'] { color: #eee; }
[alt='Permalink']:hover { color: black; }
div.informalfigure,
div.informalexample,
div.informaltable,
div.figure,
div.table,
div.example {
margin: 1em 0em;
padding: 1em;
page-break-inside: avoid;
}
div.informalfigure p.title b,
div.informalexample p.title b,
div.informaltable p.title b,
div.figure p.title b,
div.example p.title b,
div.table p.title b{
padding-top: 0em;
margin-top: 0em;
font-size: 100%;
font-weight: normal;
}
.mediaobject .caption,
.mediaobject .caption p {
text-align: center;
font-size: 80%;
padding-top: 0.5em;
padding-bottom: 0.5em;
}
.epigraph {
padding-left: 55%;
margin-bottom: 1em;
}
.epigraph p {
text-align: left;
}
.epigraph .quote {
font-style: italic;
}
.epigraph .attribution {
font-style: normal;
text-align: right;
}
span.application {
font-style: italic;
}
.programlisting {
font-family: monospace;
font-size: 80%;
white-space: pre;
margin: 1.33em 0em;
padding: 1.33em;
}
.tip,
.warning,
.caution,
.note {
margin-top: 1em;
margin-bottom: 1em;
}
/* force full width of table within div */
.tip table,
.warning table,
.caution table,
.note table {
border: none;
width: 100%;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
padding: 0.8em 0.0em 0.0em 0.0em;
margin : 0em 0em 0em 0em;
}
.tip p,
.warning p,
.caution p,
.note p {
margin-top: 0.5em;
margin-bottom: 0.5em;
padding-right: 1em;
text-align: left;
}
.acronym {
text-transform: uppercase;
}
b.keycap,
.keycap {
padding: 0.09em 0.3em;
margin: 0em;
}
.itemizedlist li {
clear: none;
}
.filename {
font-size: medium;
font-family: Courier, monospace;
}
div.navheader, div.heading{
position: absolute;
left: 0em;
top: 0em;
width: 100%;
background-color: #cdf;
width: 100%;
}
div.navfooter, div.footing{
position: fixed;
left: 0em;
bottom: 0em;
background-color: #eee;
width: 100%;
}
div.navheader td,
div.navfooter td {
font-size: 66%;
}
div.navheader table th {
/*font-family: Georgia, Times, serif;*/
/*font-size: x-large;*/
font-size: 80%;
}
div.navheader table {
border-left: 0em;
border-right: 0em;
border-top: 0em;
width: 100%;
}
div.navfooter table {
border-left: 0em;
border-right: 0em;
border-bottom: 0em;
width: 100%;
}
div.navheader table td a,
div.navfooter table td a {
color: #777;
text-decoration: none;
}
/* normal text in the footer */
div.navfooter table td {
color: black;
}
div.navheader table td a:visited,
div.navfooter table td a:visited {
color: #444;
}
/* links in header and footer */
div.navheader table td a:hover,
div.navfooter table td a:hover {
text-decoration: underline;
background-color: transparent;
color: #33a;
}
div.navheader hr,
div.navfooter hr {
display: none;
}
.qandaset tr.question td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.qandaset tr.answer td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.answer td {
padding-bottom: 1.5em;
}
.emphasis {
font-weight: bold;
}
/************* /
/ decorations /
/ *************/
.titlepage {
}
.part .title {
}
.subtitle {
border: none;
}
/*
h1 {
border: none;
}
h2 {
border-top: solid 0.2em;
border-bottom: solid 0.06em;
}
h3 {
border-top: 0em;
border-bottom: solid 0.06em;
}
h4 {
border: 0em;
border-bottom: solid 0.06em;
}
h5 {
border: 0em;
}
*/
.programlisting {
border: solid 1px;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example {
border: 1px solid;
}
.tip,
.warning,
.caution,
.note {
border: 1px solid;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom: 1px solid;
}
.question td {
border-top: 1px solid black;
}
.answer {
}
b.keycap,
.keycap {
border: 1px solid;
}
div.navheader, div.heading{
border-bottom: 1px solid;
}
div.navfooter, div.footing{
border-top: 1px solid;
}
/********* /
/ colors /
/ *********/
body {
color: #333;
background: white;
}
a {
background: transparent;
}
a:hover {
background-color: #dedede;
}
h1,
h2,
h3,
h4,
h5,
h6,
h7,
h8 {
background-color: transparent;
}
hr {
border-color: #aaa;
}
.tip, .warning, .caution, .note {
border-color: #fff;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #fff;
}
.warning {
background-color: #f0f0f2;
}
.caution {
background-color: #f0f0f2;
}
.tip {
background-color: #f0f0f2;
}
.note {
background-color: #f0f0f2;
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
color: #044;
}
div.figure,
div.table,
div.example,
div.informalfigure,
div.informaltable,
div.informalexample {
border-color: #aaa;
}
pre.programlisting {
color: black;
background-color: #fff;
border-color: #aaa;
border-width: 2px;
}
.guimenu,
.guilabel,
.guimenuitem {
background-color: #eee;
}
b.keycap,
.keycap {
background-color: #eee;
border-color: #999;
}
div.navheader {
border-color: black;
}
div.navfooter {
border-color: black;
}
.writernotes {
color: red;
}
/*********** /
/ graphics /
/ ***********/
/*
body {
background-image: url("images/body_bg.jpg");
background-attachment: fixed;
}
.navheader,
.note,
.tip {
background-image: url("images/note_bg.jpg");
background-attachment: fixed;
}
.warning,
.caution {
background-image: url("images/warning_bg.jpg");
background-attachment: fixed;
}
.figure,
.informalfigure,
.example,
.informalexample,
.table,
.informaltable {
background-image: url("images/figure_bg.jpg");
background-attachment: fixed;
}
*/
h1,
h2,
h3,
h4,
h5,
h6,
h7{
}
/*
Example of how to stick an image as part of the title.
div.article .titlepage .title
{
background-image: url("figures/white-on-black.png");
background-position: center;
background-repeat: repeat-x;
}
*/
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title {
background-position: bottom;
background-repeat: repeat-x;
}
div.section div.section .titlepage .title,
div.sect2 .titlepage .title {
background: none;
}
h1.title {
background-color: transparent;
background-repeat: no-repeat;
height: 256px;
text-indent: -9000px;
overflow:hidden;
}
h2.subtitle {
background-color: transparent;
text-indent: -9000px;
overflow:hidden;
width: 0px;
display: none;
}
/*************************************** /
/ pippin.gimp.org specific alterations /
/ ***************************************/
/*
div.heading, div.navheader {
color: #777;
font-size: 80%;
padding: 0;
margin: 0;
text-align: left;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 50px;
background: url('/gfx/heading_bg.png') transparent;
background-repeat: repeat-x;
background-attachment: fixed;
border: none;
}
div.heading a {
color: #444;
}
div.footing, div.navfooter {
border: none;
color: #ddd;
font-size: 80%;
text-align:right;
width: 100%;
padding-top: 10px;
position: absolute;
bottom: 0px;
left: 0px;
background: url('/gfx/footing_bg.png') transparent;
}
*/
/****************** /
/ nasty ie tweaks /
/ ******************/
/*
div.heading, div.navheader {
width:expression(document.body.clientWidth + "px");
}
div.footing, div.navfooter {
width:expression(document.body.clientWidth + "px");
margin-left:expression("-5em");
}
body {
padding:expression("4em 5em 0em 5em");
}
*/
/**************************************** /
/ mozilla vendor specific css extensions /
/ ****************************************/
/*
div.navfooter, div.footing{
-moz-opacity: 0.8em;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example,
.tip,
.warning,
.caution,
.note {
-moz-border-radius: 0.5em;
}
b.keycap,
.keycap {
-moz-border-radius: 0.3em;
}
*/
table tr td table tr td {
display: none;
}
hr {
display: none;
}
table {
border: 0em;
}
.photo {
float: right;
margin-left: 1.5em;
margin-bottom: 1.5em;
margin-top: 0em;
max-width: 17em;
border: 1px solid gray;
padding: 3px;
background: white;
}
.seperator {
padding-top: 2em;
clear: both;
}
#validators {
margin-top: 5em;
text-align: right;
color: #777;
}
@media print {
body {
font-size: 8pt;
}
.noprint {
display: none;
}
}
.tip,
.note {
background: #f0f0f2;
color: #333;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #333;
}
.tip a,
.note a {
color: #333;
text-decoration: underline;
}
.footnote {
font-size: small;
color: #333;
}
/* Changes the announcement text */
.tip h3,
.warning h3,
.caution h3,
.note h3 {
font-size:large;
color: #00557D;
}

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@ -1,29 +0,0 @@
<?xml version='1.0'?>
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<!--
<xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-->
<xsl:include href="../template/permalinks.xsl"/>
<xsl:include href="../template/section.title.xsl"/>
<xsl:include href="../template/component.title.xsl"/>
<xsl:include href="../template/division.title.xsl"/>
<xsl:include href="../template/formal.object.heading.xsl"/>
<xsl:param name="html.stylesheet" select="'dev-style.css'" />
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel" select="A" />
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
<xsl:param name="generate.id.attributes" select="1" />
</xsl:stylesheet>

View File

@ -1,104 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='dev-manual-intro'>
<title>The Yocto Project Development Tasks Manual</title>
<section id='dev-welcome'>
<title>Welcome</title>
<para>
Welcome to the Yocto Project Development Tasks Manual!
This manual provides relevant procedures necessary for developing
in the Yocto Project environment (i.e. developing embedded Linux
images and user-space applications that run on targeted devices).
The manual groups related procedures into higher-level sections.
Procedures can consist of high-level steps or low-level steps
depending on the topic.
</para>
<para>
This manual provides the following:
<itemizedlist>
<listitem><para>
Procedures that help you get going with the Yocto Project.
For example, procedures that show you how to set up
a build host and work with the Yocto Project
source repositories.
</para></listitem>
<listitem><para>
Procedures that show you how to submit changes to the
Yocto Project.
Changes can be improvements, new features, or bug
fixes.
</para></listitem>
<listitem><para>
Procedures related to "everyday" tasks you perform while
developing images and applications using the Yocto
Project.
For example, procedures to create a layer, customize an
image, write a new recipe, and so forth.
</para></listitem>
</itemizedlist>
</para>
<para>
This manual does not provide the following:
<itemizedlist>
<listitem><para>
Redundant Step-by-step Instructions:
For example, the
<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
manual contains detailed instructions on how to install an
SDK, which is used to develop applications for target
hardware.
</para></listitem>
<listitem><para>
Reference or Conceptual Material:
This type of material resides in an appropriate reference
manual.
For example, system variables are documented in the
<ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.
</para></listitem>
<listitem><para>
Detailed Public Information Not Specific to the
Yocto Project:
For example, exhaustive information on how to use the
Source Control Manager Git is better covered with Internet
searches and official Git Documentation than through the
Yocto Project documentation.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='other-information'>
<title>Other Information</title>
<para>
Because this manual presents information for many different
topics, supplemental information is recommended for full
comprehension.
For introductory information on the Yocto Project, see the
<ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>.
If you want to build an image with no knowledge of Yocto Project
as a way of quickly testing it out, see the
<ulink url='&YOCTO_DOCS_BRIEF_URL;'>Yocto Project Quick Build</ulink>
document.
</para>
<para>
For a comprehensive list of links and other documentation, see the
"<ulink url='&YOCTO_DOCS_REF_URL;#resources-links-and-related-documentation'>Links and Related Documentation</ulink>"
section in the Yocto Project Reference Manual.
</para>
<para>
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,691 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='dev-manual-qemu'>
<title>Using the Quick EMUlator (QEMU)</title>
<para>
The Yocto Project uses an implementation of the Quick EMUlator (QEMU)
Open Source project as part of the Yocto Project development "tool
set".
This chapter provides both procedures that show you how to use the
Quick EMUlator (QEMU) and other QEMU information helpful for
development purposes.
</para>
<section id='qemu-dev-overview'>
<title>Overview</title>
<para>
Within the context of the Yocto Project, QEMU is an
emulator and virtualization machine that allows you to run a
complete image you have built using the Yocto Project as just
another task on your build system.
QEMU is useful for running and testing images and applications on
supported Yocto Project architectures without having actual
hardware.
Among other things, the Yocto Project uses QEMU to run automated
Quality Assurance (QA) tests on final images shipped with each
release.
<note>
This implementation is not the same as QEMU in general.
</note>
This section provides a brief reference for the Yocto Project
implementation of QEMU.
</para>
<para>
For official information and documentation on QEMU in general, see
the following references:
<itemizedlist>
<listitem><para>
<emphasis><ulink url='http://wiki.qemu.org/Main_Page'>QEMU Website</ulink>:</emphasis>
The official website for the QEMU Open Source project.
</para></listitem>
<listitem><para>
<emphasis><ulink url='http://wiki.qemu.org/Manual'>Documentation</ulink>:</emphasis>
The QEMU user manual.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='qemu-running-qemu'>
<title>Running QEMU</title>
<para>
To use QEMU, you need to have QEMU installed and initialized as
well as have the proper artifacts (i.e. image files and root
filesystems) available.
Follow these general steps to run QEMU:
<orderedlist>
<listitem><para>
<emphasis>Install QEMU:</emphasis>
QEMU is made available with the Yocto Project a number of
ways.
One method is to install a Software Development Kit (SDK).
See
"<ulink url='&YOCTO_DOCS_SDK_URL;#the-qemu-emulator'>The QEMU Emulator</ulink>"
section in the Yocto Project Application Development and
the Extensible Software Development Kit (eSDK) manual
for information on how to install QEMU.
</para></listitem>
<listitem><para>
<emphasis>Setting Up the Environment:</emphasis>
How you set up the QEMU environment depends on how you
installed QEMU:
<itemizedlist>
<listitem><para>
If you cloned the <filename>poky</filename>
repository or you downloaded and unpacked a
Yocto Project release tarball, you can source
the build environment script (i.e.
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>):
<literallayout class='monospaced'>
$ cd ~/poky
$ source oe-init-build-env
</literallayout>
</para></listitem>
<listitem><para>
If you installed a cross-toolchain, you can
run the script that initializes the toolchain.
For example, the following commands run the
initialization script from the default
<filename>poky_sdk</filename> directory:
<literallayout class='monospaced'>
. ~/poky_sdk/environment-setup-core2-64-poky-linux
</literallayout>
</para></listitem>
</itemizedlist>
</para></listitem>
<listitem><para>
<emphasis>Ensure the Artifacts are in Place:</emphasis>
You need to be sure you have a pre-built kernel that
will boot in QEMU.
You also need the target root filesystem for your target
machine's architecture:
<itemizedlist>
<listitem><para>
If you have previously built an image for QEMU
(e.g. <filename>qemux86</filename>,
<filename>qemuarm</filename>, and so forth),
then the artifacts are in place in your
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
</para></listitem>
<listitem><para>
If you have not built an image, you can go to the
<ulink url='&YOCTO_MACHINES_DL_URL;'>machines/qemu</ulink>
area and download a pre-built image that matches
your architecture and can be run on QEMU.
</para></listitem>
</itemizedlist></para>
<para>See the
"<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>"
section in the Yocto Project Application Development and
the Extensible Software Development Kit (eSDK) manual
for information on how to extract a root filesystem.
</para></listitem>
<listitem><para>
<emphasis>Run QEMU:</emphasis>
The basic <filename>runqemu</filename> command syntax is as
follows:
<literallayout class='monospaced'>
$ runqemu [<replaceable>option</replaceable> ] [...]
</literallayout>
Based on what you provide on the command line,
<filename>runqemu</filename> does a good job of figuring
out what you are trying to do.
For example, by default, QEMU looks for the most recently
built image according to the timestamp when it needs to
look for an image.
Minimally, through the use of options, you must provide
either a machine name, a virtual machine image
(<filename>*wic.vmdk</filename>), or a kernel image
(<filename>*.bin</filename>).</para>
<para>Here are some additional examples to help illustrate
further QEMU:
<itemizedlist>
<listitem><para>
This example starts QEMU with
<replaceable>MACHINE</replaceable> set to "qemux86-64".
Assuming a standard
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
<filename>runqemu</filename> automatically finds the
<filename>bzImage-qemux86-64.bin</filename> image file and
the
<filename>core-image-minimal-qemux86-64-20200218002850.rootfs.ext4</filename>
(assuming the current build created a
<filename>core-image-minimal</filename> image).
<note>
When more than one image with the same name exists, QEMU finds
and uses the most recently built image according to the
timestamp.
</note>
<literallayout class='monospaced'>
$ runqemu qemux86-64
</literallayout>
</para></listitem>
<listitem><para>
This example produces the exact same results as the
previous example.
This command, however, specifically provides the image
and root filesystem type.
<literallayout class='monospaced'>
$ runqemu qemux86-64 core-image-minimal ext4
</literallayout>
</para></listitem>
<listitem><para>
This example specifies to boot an initial RAM disk image
and to enable audio in QEMU.
For this case, <filename>runqemu</filename> set the
internal variable <filename>FSTYPE</filename> to
"cpio.gz".
Also, for audio to be enabled, an appropriate driver must
be installed (see the previous description for the
<filename>audio</filename> option for more information).
<literallayout class='monospaced'>
$ runqemu qemux86-64 ramfs audio
</literallayout>
</para></listitem>
<listitem><para>
This example does not provide enough information for
QEMU to launch.
While the command does provide a root filesystem type, it
must also minimally provide a
<replaceable>MACHINE</replaceable>,
<replaceable>KERNEL</replaceable>, or
<replaceable>VM</replaceable> option.
<literallayout class='monospaced'>
$ runqemu ext4
</literallayout>
</para></listitem>
<listitem><para>
This example specifies to boot a virtual machine
image (<filename>.wic.vmdk</filename> file).
From the <filename>.wic.vmdk</filename>,
<filename>runqemu</filename> determines the QEMU
architecture (<replaceable>MACHINE</replaceable>) to be
"qemux86-64" and the root filesystem type to be "vmdk".
<literallayout class='monospaced'>
$ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk
</literallayout>
</para></listitem>
</itemizedlist>
</para></listitem>
</orderedlist>
</para>
</section>
<section id='switching-between-consoles'>
<title>Switching Between Consoles</title>
<para>
When booting or running QEMU, you can switch between
supported consoles by using
Ctrl+Alt+<replaceable>number</replaceable>.
For example, Ctrl+Alt+3 switches you to the serial console
as long as that console is enabled.
Being able to switch consoles is helpful, for example, if
the main QEMU console breaks for some reason.
<note>
Usually, "2" gets you to the main console and "3"
gets you to the serial console.
</note>
</para>
</section>
<section id='removing-the-splash-screen'>
<title>Removing the Splash Screen</title>
<para>
You can remove the splash screen when QEMU is booting by
using Alt+left.
Removing the splash screen allows you to see what is
happening in the background.
</para>
</section>
<section id='disabling-the-cursor-grab'>
<title>Disabling the Cursor Grab</title>
<para>
The default QEMU integration captures the cursor within the
main window.
It does this since standard mouse devices only provide
relative input and not absolute coordinates.
You then have to break out of the grab using the "Ctrl+Alt"
key combination.
However, the Yocto Project's integration of QEMU enables
the wacom USB touch pad driver by default to allow input
of absolute coordinates.
This default means that the mouse can enter and leave the
main window without the grab taking effect leading to a
better user experience.
</para>
</section>
<section id='qemu-running-under-a-network-file-system-nfs-server'>
<title>Running Under a Network File System (NFS) Server</title>
<para>
One method for running QEMU is to run it on an NFS server.
This is useful when you need to access the same file system
from both the build and the emulated system at the same time.
It is also worth noting that the system does not need root
privileges to run.
It uses a user space NFS server to avoid that.
Follow these steps to set up for running QEMU using an NFS
server.
<orderedlist>
<listitem><para>
<emphasis>Extract a Root Filesystem:</emphasis>
Once you are able to run QEMU in your environment, you can
use the <filename>runqemu-extract-sdk</filename> script,
which is located in the <filename>scripts</filename>
directory along with the <filename>runqemu</filename>
script.</para>
<para>The <filename>runqemu-extract-sdk</filename> takes a
root filesystem tarball and extracts it into a location
that you specify.
Here is an example that takes a file system and
extracts it to a directory named
<filename>test-nfs</filename>:
<literallayout class='monospaced'>
runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs
</literallayout>
</para></listitem>
<listitem><para>
<emphasis>Start QEMU:</emphasis>
Once you have extracted the file system, you can run
<filename>runqemu</filename> normally with the additional
location of the file system.
You can then also make changes to the files within
<filename>./test-nfs</filename> and see those changes
appear in the image in real time.
Here is an example using the <filename>qemux86</filename>
image:
<literallayout class='monospaced'>
runqemu qemux86-64 ./test-nfs
</literallayout>
</para></listitem>
</orderedlist>
<note>
<para>
Should you need to start, stop, or restart the NFS share,
you can use the following commands:
<itemizedlist>
<listitem><para>
The following command starts the NFS share:
<literallayout class='monospaced'>
runqemu-export-rootfs start <replaceable>file-system-location</replaceable>
</literallayout>
</para></listitem>
<listitem><para>
The following command stops the NFS share:
<literallayout class='monospaced'>
runqemu-export-rootfs stop <replaceable>file-system-location</replaceable>
</literallayout>
</para></listitem>
<listitem><para>
The following command restarts the NFS share:
<literallayout class='monospaced'>
runqemu-export-rootfs restart <replaceable>file-system-location</replaceable>
</literallayout>
</para></listitem>
</itemizedlist>
</para>
</note>
</para>
</section>
<section id='qemu-kvm-cpu-compatibility'>
<title>QEMU CPU Compatibility Under KVM</title>
<para>
By default, the QEMU build compiles for and targets 64-bit and x86
<trademark class='registered'>Intel</trademark> <trademark class='trademark'>Core</trademark>2
Duo processors and 32-bit x86
<trademark class='registered'>Intel</trademark> <trademark class='registered'>Pentium</trademark>
II processors.
QEMU builds for and targets these CPU types because they display
a broad range of CPU feature compatibility with many commonly
used CPUs.
</para>
<para>
Despite this broad range of compatibility, the CPUs could support
a feature that your host CPU does not support.
Although this situation is not a problem when QEMU uses software
emulation of the feature, it can be a problem when QEMU is
running with KVM enabled.
Specifically, software compiled with a certain CPU feature crashes
when run on a CPU under KVM that does not support that feature.
To work around this problem, you can override QEMU's runtime CPU
setting by changing the <filename>QB_CPU_KVM</filename>
variable in <filename>qemuboot.conf</filename> in the
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory's</ulink>
<filename>deploy/image</filename> directory.
This setting specifies a <filename>-cpu</filename> option
passed into QEMU in the <filename>runqemu</filename> script.
Running <filename>qemu -cpu help</filename> returns a list of
available supported CPU types.
</para>
</section>
<section id='qemu-dev-performance'>
<title>QEMU Performance</title>
<para>
Using QEMU to emulate your hardware can result in speed issues
depending on the target and host architecture mix.
For example, using the <filename>qemux86</filename> image in the
emulator on an Intel-based 32-bit (x86) host machine is fast
because the target and host architectures match.
On the other hand, using the <filename>qemuarm</filename> image
on the same Intel-based host can be slower.
But, you still achieve faithful emulation of ARM-specific issues.
</para>
<para>
To speed things up, the QEMU images support using
<filename>distcc</filename> to call a cross-compiler outside the
emulated system.
If you used <filename>runqemu</filename> to start QEMU, and the
<filename>distccd</filename> application is present on the host
system, any BitBake cross-compiling toolchain available from the
build system is automatically used from within QEMU simply by
calling <filename>distcc</filename>.
You can accomplish this by defining the cross-compiler variable
(e.g. <filename>export CC="distcc"</filename>).
Alternatively, if you are using a suitable SDK image or the
appropriate stand-alone toolchain is present, the toolchain is
also automatically used.
<note>
Several mechanisms exist that let you connect to the system
running on the QEMU emulator:
<itemizedlist>
<listitem><para>
QEMU provides a framebuffer interface that makes
standard consoles available.
</para></listitem>
<listitem><para>
Generally, headless embedded devices have a serial port.
If so, you can configure the operating system of the
running image to use that port to run a console.
The connection uses standard IP networking.
</para></listitem>
<listitem><para>
SSH servers exist in some QEMU images.
The <filename>core-image-sato</filename> QEMU image
has a Dropbear secure shell (SSH) server that runs
with the root password disabled.
The <filename>core-image-full-cmdline</filename> and
<filename>core-image-lsb</filename> QEMU images
have OpenSSH instead of Dropbear.
Including these SSH servers allow you to use standard
<filename>ssh</filename> and <filename>scp</filename>
commands.
The <filename>core-image-minimal</filename> QEMU image,
however, contains no SSH server.
</para></listitem>
<listitem><para>
You can use a provided, user-space NFS server to boot
the QEMU session using a local copy of the root
filesystem on the host.
In order to make this connection, you must extract a
root filesystem tarball by using the
<filename>runqemu-extract-sdk</filename> command.
After running the command, you must then point the
<filename>runqemu</filename>
script to the extracted directory instead of a root
filesystem image file.
See the
"<link linkend='qemu-running-under-a-network-file-system-nfs-server'>Running Under a Network File System (NFS) Server</link>"
section for more information.
</para></listitem>
</itemizedlist>
</note>
</para>
</section>
<section id='qemu-dev-command-line-syntax'>
<title>QEMU Command-Line Syntax</title>
<para>
The basic <filename>runqemu</filename> command syntax is as
follows:
<literallayout class='monospaced'>
$ runqemu [<replaceable>option</replaceable> ] [...]
</literallayout>
Based on what you provide on the command line,
<filename>runqemu</filename> does a good job of figuring out what
you are trying to do.
For example, by default, QEMU looks for the most recently built
image according to the timestamp when it needs to look for an
image.
Minimally, through the use of options, you must provide either
a machine name, a virtual machine image
(<filename>*wic.vmdk</filename>), or a kernel image
(<filename>*.bin</filename>).
</para>
<para>
Following is the command-line help output for the
<filename>runqemu</filename> command:
<literallayout class='monospaced'>
$ runqemu --help
Usage: you can run this script with any valid combination
of the following environment variables (in any order):
KERNEL - the kernel image file to use
ROOTFS - the rootfs image file or nfsroot directory to use
MACHINE - the machine name (optional, autodetected from KERNEL filename if unspecified)
Simplified QEMU command-line options can be passed with:
nographic - disable video console
serial - enable a serial console on /dev/ttyS0
slirp - enable user networking, no root privileges is required
kvm - enable KVM when running x86/x86_64 (VT-capable CPU required)
kvm-vhost - enable KVM with vhost when running x86/x86_64 (VT-capable CPU required)
publicvnc - enable a VNC server open to all hosts
audio - enable audio
[*/]ovmf* - OVMF firmware file or base name for booting with UEFI
tcpserial=&lt;port&gt; - specify tcp serial port number
biosdir=&lt;dir&gt; - specify custom bios dir
biosfilename=&lt;filename&gt; - specify bios filename
qemuparams=&lt;xyz&gt; - specify custom parameters to QEMU
bootparams=&lt;xyz&gt; - specify custom kernel parameters during boot
help, -h, --help: print this text
Examples:
runqemu
runqemu qemuarm
runqemu tmp/deploy/images/qemuarm
runqemu tmp/deploy/images/qemux86/&lt;qemuboot.conf&gt;
runqemu qemux86-64 core-image-sato ext4
runqemu qemux86-64 wic-image-minimal wic
runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial
runqemu qemux86 iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz...
runqemu qemux86 qemuparams="-m 256"
runqemu qemux86 bootparams="psplash=false"
runqemu path/to/&lt;image&gt;-&lt;machine&gt;.wic
runqemu path/to/&lt;image&gt;-&lt;machine&gt;.wic.vmdk
</literallayout>
</para>
</section>
<section id='qemu-dev-runqemu-command-line-options'>
<title><filename>runqemu</filename> Command-Line Options</title>
<para>
Following is a description of <filename>runqemu</filename>
options you can provide on the command line:
<note><title>Tip</title>
If you do provide some "illegal" option combination or perhaps
you do not provide enough in the way of options,
<filename>runqemu</filename> provides appropriate error
messaging to help you correct the problem.
</note>
<itemizedlist>
<listitem><para>
<replaceable>QEMUARCH</replaceable>:
The QEMU machine architecture, which must be "qemuarm",
"qemuarm64", "qemumips", "qemumips64", "qemuppc",
"qemux86", or "qemux86-64".
</para></listitem>
<listitem><para>
<filename><replaceable>VM</replaceable></filename>:
The virtual machine image, which must be a
<filename>.wic.vmdk</filename> file.
Use this option when you want to boot a
<filename>.wic.vmdk</filename> image.
The image filename you provide must contain one of the
following strings: "qemux86-64", "qemux86", "qemuarm",
"qemumips64", "qemumips", "qemuppc", or "qemush4".
</para></listitem>
<listitem><para>
<replaceable>ROOTFS</replaceable>:
A root filesystem that has one of the following
filetype extensions: "ext2", "ext3", "ext4", "jffs2",
"nfs", or "btrfs".
If the filename you provide for this option uses "nfs", it
must provide an explicit root filesystem path.
</para></listitem>
<listitem><para>
<replaceable>KERNEL</replaceable>:
A kernel image, which is a <filename>.bin</filename> file.
When you provide a <filename>.bin</filename> file,
<filename>runqemu</filename> detects it and assumes the
file is a kernel image.
</para></listitem>
<listitem><para>
<replaceable>MACHINE</replaceable>:
The architecture of the QEMU machine, which must be one
of the following: "qemux86", "qemux86-64", "qemuarm",
"qemuarm64", "qemumips", "qemumips64", or "qemuppc".
The <replaceable>MACHINE</replaceable> and
<replaceable>QEMUARCH</replaceable> options are basically
identical.
If you do not provide a <replaceable>MACHINE</replaceable>
option, <filename>runqemu</filename> tries to determine
it based on other options.
</para></listitem>
<listitem><para>
<filename>ramfs</filename>:
Indicates you are booting an initial RAM disk (initramfs)
image, which means the <filename>FSTYPE</filename> is
<filename>cpio.gz</filename>.
</para></listitem>
<listitem><para>
<filename>iso</filename>:
Indicates you are booting an ISO image, which means the
<filename>FSTYPE</filename> is
<filename>.iso</filename>.
</para></listitem>
<listitem><para>
<filename>nographic</filename>:
Disables the video console, which sets the console to
"ttys0".
This option is useful when you have logged into a server
and you do not want to disable forwarding from the
X Window System (X11) to your workstation or laptop.
</para></listitem>
<listitem><para>
<filename>serial</filename>:
Enables a serial console on
<filename>/dev/ttyS0</filename>.
</para></listitem>
<listitem><para>
<filename>biosdir</filename>:
Establishes a custom directory for BIOS, VGA BIOS and
keymaps.
</para></listitem>
<listitem><para>
<filename>biosfilename</filename>:
Establishes a custom BIOS name.
</para></listitem>
<listitem><para>
<filename>qemuparams=\"<replaceable>xyz</replaceable>\"</filename>:
Specifies custom QEMU parameters.
Use this option to pass options other than the simple
"kvm" and "serial" options.
</para></listitem>
<listitem><para><filename>bootparams=\"<replaceable>xyz</replaceable>\"</filename>:
Specifies custom boot parameters for the kernel.
</para></listitem>
<listitem><para>
<filename>audio</filename>:
Enables audio in QEMU.
The <replaceable>MACHINE</replaceable> option must be
either "qemux86" or "qemux86-64" in order for audio to be
enabled.
Additionally, the <filename>snd_intel8x0</filename>
or <filename>snd_ens1370</filename> driver must be
installed in linux guest.
</para></listitem>
<listitem><para>
<filename>slirp</filename>:
Enables "slirp" networking, which is a different way
of networking that does not need root access
but also is not as easy to use or comprehensive
as the default.
</para></listitem>
<listitem><para id='kvm-cond'>
<filename>kvm</filename>:
Enables KVM when running "qemux86" or "qemux86-64"
QEMU architectures.
For KVM to work, all the following conditions must be met:
<itemizedlist>
<listitem><para>
Your <replaceable>MACHINE</replaceable> must be either
qemux86" or "qemux86-64".
</para></listitem>
<listitem><para>
Your build host has to have the KVM modules
installed, which are
<filename>/dev/kvm</filename>.
</para></listitem>
<listitem><para>
The build host <filename>/dev/kvm</filename>
directory has to be both writable and readable.
</para></listitem>
</itemizedlist>
</para></listitem>
<listitem><para>
<filename>kvm-vhost</filename>:
Enables KVM with VHOST support when running "qemux86"
or "qemux86-64" QEMU architectures.
For KVM with VHOST to work, the following conditions must
be met:
<itemizedlist>
<listitem><para>
<link linkend='kvm-cond'>kvm</link> option
conditions must be met.
</para></listitem>
<listitem><para>
Your build host has to have virtio net device, which
are <filename>/dev/vhost-net</filename>.
</para></listitem>
<listitem><para>
The build host <filename>/dev/vhost-net</filename>
directory has to be either readable or writable
and "slirp-enabled".
</para></listitem>
</itemizedlist>
</para></listitem>
<listitem><para>
<filename>publicvnc</filename>:
Enables a VNC server open to all hosts.
</para></listitem>
</itemizedlist>
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

File diff suppressed because it is too large Load Diff

View File

@ -1,195 +0,0 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<book id='dev-manual' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
<bookinfo>
<mediaobject>
<imageobject>
<imagedata fileref='figures/dev-title.png'
format='SVG'
align='left' scalefit='1' width='100%'/>
</imageobject>
</mediaobject>
<title>
Yocto Project Development Tasks Manual
</title>
<authorgroup>
<author>
<affiliation>
<orgname>&ORGNAME;</orgname>
</affiliation>
<email>&ORGEMAIL;</email>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>1.1</revnumber>
<date>October 2011</date>
<revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
</revision>
<revision>
<revnumber>1.2</revnumber>
<date>April 2012</date>
<revremark>Released with the Yocto Project 1.2 Release.</revremark>
</revision>
<revision>
<revnumber>1.3</revnumber>
<date>October 2012</date>
<revremark>Released with the Yocto Project 1.3 Release.</revremark>
</revision>
<revision>
<revnumber>1.4</revnumber>
<date>April 2013</date>
<revremark>Released with the Yocto Project 1.4 Release.</revremark>
</revision>
<revision>
<revnumber>1.5</revnumber>
<date>October 2013</date>
<revremark>Released with the Yocto Project 1.5 Release.</revremark>
</revision>
<revision>
<revnumber>1.6</revnumber>
<date>April 2014</date>
<revremark>Released with the Yocto Project 1.6 Release.</revremark>
</revision>
<revision>
<revnumber>1.7</revnumber>
<date>October 2014</date>
<revremark>Released with the Yocto Project 1.7 Release.</revremark>
</revision>
<revision>
<revnumber>1.8</revnumber>
<date>April 2015</date>
<revremark>Released with the Yocto Project 1.8 Release.</revremark>
</revision>
<revision>
<revnumber>2.0</revnumber>
<date>October 2015</date>
<revremark>Released with the Yocto Project 2.0 Release.</revremark>
</revision>
<revision>
<revnumber>2.1</revnumber>
<date>April 2016</date>
<revremark>Released with the Yocto Project 2.1 Release.</revremark>
</revision>
<revision>
<revnumber>2.2</revnumber>
<date>October 2016</date>
<revremark>Released with the Yocto Project 2.2 Release.</revremark>
</revision>
<revision>
<revnumber>2.3</revnumber>
<date>May 2017</date>
<revremark>Released with the Yocto Project 2.3 Release.</revremark>
</revision>
<revision>
<revnumber>2.4</revnumber>
<date>October 2017</date>
<revremark>Released with the Yocto Project 2.4 Release.</revremark>
</revision>
<revision>
<revnumber>2.5</revnumber>
<date>May 2018</date>
<revremark>Released with the Yocto Project 2.5 Release.</revremark>
</revision>
<revision>
<revnumber>2.6</revnumber>
<date>November 2018</date>
<revremark>Released with the Yocto Project 2.6 Release.</revremark>
</revision>
<revision>
<revnumber>2.7</revnumber>
<date>May 2019</date>
<revremark>Released with the Yocto Project 2.7 Release.</revremark>
</revision>
<revision>
<revnumber>3.0</revnumber>
<date>October 2019</date>
<revremark>Released with the Yocto Project 3.0 Release.</revremark>
</revision>
<revision>
<revnumber>3.1</revnumber>
<date>&REL_MONTH_YEAR;</date>
<revremark>Released with the Yocto Project 3.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>&COPYRIGHT_YEAR;</year>
<holder>Linux Foundation</holder>
</copyright>
<legalnotice>
<para>
Permission is granted to copy, distribute and/or modify this document under
the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">
Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by
Creative Commons.
</para>
<note><title>Manual Notes</title>
<itemizedlist>
<listitem><para>
This version of the
<emphasis>Yocto Project Development Tasks Manual</emphasis>
is for the &YOCTO_DOC_VERSION; release of the
Yocto Project.
To be sure you have the latest version of the manual
for this release, go to the
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
and select the manual from that site.
Manuals from the site are more up-to-date than manuals
derived from the Yocto Project released TAR files.
</para></listitem>
<listitem><para>
If you located this manual through a web search, the
version of the manual might not be the one you want
(e.g. the search might have returned a manual much
older than the Yocto Project version with which you
are working).
You can see all Yocto Project major releases by
visiting the
<ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
page.
If you need a version of this manual for a different
Yocto Project release, visit the
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
and select the manual set by using the
"ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
pull-down menus.
</para></listitem>
<listitem>
<para>
To report any inaccuracies or problems with this
(or any other Yocto Project) manual, send an email to
the Yocto Project documentation mailing list at
<filename>docs@lists.yoctoproject.org</filename> or
log into the freenode <filename>#yocto</filename> channel.
</para>
</listitem>
</itemizedlist>
</note>
</legalnotice>
</bookinfo>
<xi:include href="dev-manual-intro.xml"/>
<xi:include href="dev-manual-start.xml"/>
<xi:include href="dev-manual-common-tasks.xml"/>
<xi:include href="dev-manual-qemu.xml"/>
</book>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,991 +0,0 @@
/*
SPDX-License-Identifier: CC-BY-2.0-UK
Generic XHTML / DocBook XHTML CSS Stylesheet.
Browser wrangling and typographic design by
Oyvind Kolas / pippin@gimp.org
Customised for Poky by
Matthew Allum / mallum@o-hand.com
Thanks to:
Liam R. E. Quin
William Skaggs
Jakub Steiner
Structure
---------
The stylesheet is divided into the following sections:
Positioning
Margins, paddings, width, font-size, clearing.
Decorations
Borders, style
Colors
Colors
Graphics
Graphical backgrounds
Nasty IE tweaks
Workarounds needed to make it work in internet explorer,
currently makes the stylesheet non validating, but up until
this point it is validating.
Mozilla extensions
Transparency for footer
Rounded corners on boxes
*/
/*************** /
/ Positioning /
/ ***************/
body {
font-family: Verdana, Sans, sans-serif;
min-width: 640px;
width: 80%;
margin: 0em auto;
padding: 2em 5em 5em 5em;
color: #333;
}
h1,h2,h3,h4,h5,h6,h7 {
font-family: Arial, Sans;
color: #00557D;
clear: both;
}
h1 {
font-size: 2em;
text-align: left;
padding: 0em 0em 0em 0em;
margin: 2em 0em 0em 0em;
}
h2.subtitle {
margin: 0.10em 0em 3.0em 0em;
padding: 0em 0em 0em 0em;
font-size: 1.8em;
padding-left: 20%;
font-weight: normal;
font-style: italic;
}
h2 {
margin: 2em 0em 0.66em 0em;
padding: 0.5em 0em 0em 0em;
font-size: 1.5em;
font-weight: bold;
}
h3.subtitle {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
font-size: 142.14%;
text-align: right;
}
h3 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 140%;
font-weight: bold;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: bold;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("figures/dev-title.png");
background-position: left top;
margin-top: -256px;
padding-right: 50px;
margin-left: 0px;
text-align: right;
width: 740px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
color: #333;
clear: both;
}
.author tt.email {
font-size: 66%;
}
.titlepage hr {
width: 0em;
clear: both;
}
.revhistory {
padding-top: 2em;
clear: both;
}
.toc,
.list-of-tables,
.list-of-examples,
.list-of-figures {
padding: 1.33em 0em 2.5em 0em;
color: #00557D;
}
.toc p,
.list-of-tables p,
.list-of-figures p,
.list-of-examples p {
padding: 0em 0em 0em 0em;
padding: 0em 0em 0.3em;
margin: 1.5em 0em 0em 0em;
}
.toc p b,
.list-of-tables p b,
.list-of-figures p b,
.list-of-examples p b{
font-size: 100.0%;
font-weight: bold;
}
.toc dl,
.list-of-tables dl,
.list-of-figures dl,
.list-of-examples dl {
margin: 0em 0em 0.5em 0em;
padding: 0em 0em 0em 0em;
}
.toc dt {
margin: 0em 0em 0em 0em;
padding: 0em 0em 0em 0em;
}
.toc dd {
margin: 0em 0em 0em 2.6em;
padding: 0em 0em 0em 0em;
}
div.glossary dl,
div.variablelist dl {
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
font-weight: normal;
width: 20em;
text-align: right;
}
.variablelist dl dt {
margin-top: 0.5em;
}
.glossary dl dd,
.variablelist dl dd {
margin-top: -1em;
margin-left: 25.5em;
}
.glossary dd p,
.variablelist dd p {
margin-top: 0em;
margin-bottom: 1em;
}
div.calloutlist table td {
padding: 0em 0em 0em 0em;
margin: 0em 0em 0em 0em;
}
div.calloutlist table td p {
margin-top: 0em;
margin-bottom: 1em;
}
div p.copyright {
text-align: left;
}
div.legalnotice p.legalnotice-title {
margin-bottom: 0em;
}
p {
line-height: 1.5em;
margin-top: 0em;
}
dl {
padding-top: 0em;
}
hr {
border: solid 1px;
}
.mediaobject,
.mediaobjectco {
text-align: center;
}
img {
border: none;
}
ul {
padding: 0em 0em 0em 1.5em;
}
ul li {
padding: 0em 0em 0em 0em;
}
ul li p {
text-align: left;
}
table {
width :100%;
}
th {
padding: 0.25em;
text-align: left;
font-weight: normal;
vertical-align: top;
}
td {
padding: 0.25em;
vertical-align: top;
}
p a[id] {
margin: 0px;
padding: 0px;
display: inline;
background-image: none;
}
a {
text-decoration: underline;
color: #444;
}
pre {
overflow: auto;
}
a:hover {
text-decoration: underline;
/*font-weight: bold;*/
}
/* This style defines how the permalink character
appears by itself and when hovered over with
the mouse. */
[alt='Permalink'] { color: #eee; }
[alt='Permalink']:hover { color: black; }
div.informalfigure,
div.informalexample,
div.informaltable,
div.figure,
div.table,
div.example {
margin: 1em 0em;
padding: 1em;
page-break-inside: avoid;
}
div.informalfigure p.title b,
div.informalexample p.title b,
div.informaltable p.title b,
div.figure p.title b,
div.example p.title b,
div.table p.title b{
padding-top: 0em;
margin-top: 0em;
font-size: 100%;
font-weight: normal;
}
.mediaobject .caption,
.mediaobject .caption p {
text-align: center;
font-size: 80%;
padding-top: 0.5em;
padding-bottom: 0.5em;
}
.epigraph {
padding-left: 55%;
margin-bottom: 1em;
}
.epigraph p {
text-align: left;
}
.epigraph .quote {
font-style: italic;
}
.epigraph .attribution {
font-style: normal;
text-align: right;
}
span.application {
font-style: italic;
}
.programlisting {
font-family: monospace;
font-size: 80%;
white-space: pre;
margin: 1.33em 0em;
padding: 1.33em;
}
.tip,
.warning,
.caution,
.note {
margin-top: 1em;
margin-bottom: 1em;
}
/* force full width of table within div */
.tip table,
.warning table,
.caution table,
.note table {
border: none;
width: 100%;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
padding: 0.8em 0.0em 0.0em 0.0em;
margin : 0em 0em 0em 0em;
}
.tip p,
.warning p,
.caution p,
.note p {
margin-top: 0.5em;
margin-bottom: 0.5em;
padding-right: 1em;
text-align: left;
}
.acronym {
text-transform: uppercase;
}
b.keycap,
.keycap {
padding: 0.09em 0.3em;
margin: 0em;
}
.itemizedlist li {
clear: none;
}
.filename {
font-size: medium;
font-family: Courier, monospace;
}
div.navheader, div.heading{
position: absolute;
left: 0em;
top: 0em;
width: 100%;
background-color: #cdf;
width: 100%;
}
div.navfooter, div.footing{
position: fixed;
left: 0em;
bottom: 0em;
background-color: #eee;
width: 100%;
}
div.navheader td,
div.navfooter td {
font-size: 66%;
}
div.navheader table th {
/*font-family: Georgia, Times, serif;*/
/*font-size: x-large;*/
font-size: 80%;
}
div.navheader table {
border-left: 0em;
border-right: 0em;
border-top: 0em;
width: 100%;
}
div.navfooter table {
border-left: 0em;
border-right: 0em;
border-bottom: 0em;
width: 100%;
}
div.navheader table td a,
div.navfooter table td a {
color: #777;
text-decoration: none;
}
/* normal text in the footer */
div.navfooter table td {
color: black;
}
div.navheader table td a:visited,
div.navfooter table td a:visited {
color: #444;
}
/* links in header and footer */
div.navheader table td a:hover,
div.navfooter table td a:hover {
text-decoration: underline;
background-color: transparent;
color: #33a;
}
div.navheader hr,
div.navfooter hr {
display: none;
}
.qandaset tr.question td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.qandaset tr.answer td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.answer td {
padding-bottom: 1.5em;
}
.emphasis {
font-weight: bold;
}
/************* /
/ decorations /
/ *************/
.titlepage {
}
.part .title {
}
.subtitle {
border: none;
}
/*
h1 {
border: none;
}
h2 {
border-top: solid 0.2em;
border-bottom: solid 0.06em;
}
h3 {
border-top: 0em;
border-bottom: solid 0.06em;
}
h4 {
border: 0em;
border-bottom: solid 0.06em;
}
h5 {
border: 0em;
}
*/
.programlisting {
border: solid 1px;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example {
border: 1px solid;
}
.tip,
.warning,
.caution,
.note {
border: 1px solid;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom: 1px solid;
}
.question td {
border-top: 1px solid black;
}
.answer {
}
b.keycap,
.keycap {
border: 1px solid;
}
div.navheader, div.heading{
border-bottom: 1px solid;
}
div.navfooter, div.footing{
border-top: 1px solid;
}
/********* /
/ colors /
/ *********/
body {
color: #333;
background: white;
}
a {
background: transparent;
}
a:hover {
background-color: #dedede;
}
h1,
h2,
h3,
h4,
h5,
h6,
h7,
h8 {
background-color: transparent;
}
hr {
border-color: #aaa;
}
.tip, .warning, .caution, .note {
border-color: #fff;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #fff;
}
.warning {
background-color: #f0f0f2;
}
.caution {
background-color: #f0f0f2;
}
.tip {
background-color: #f0f0f2;
}
.note {
background-color: #f0f0f2;
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
color: #044;
}
div.figure,
div.table,
div.example,
div.informalfigure,
div.informaltable,
div.informalexample {
border-color: #aaa;
}
pre.programlisting {
color: black;
background-color: #fff;
border-color: #aaa;
border-width: 2px;
}
.guimenu,
.guilabel,
.guimenuitem {
background-color: #eee;
}
b.keycap,
.keycap {
background-color: #eee;
border-color: #999;
}
div.navheader {
border-color: black;
}
div.navfooter {
border-color: black;
}
.writernotes {
color: red;
}
/*********** /
/ graphics /
/ ***********/
/*
body {
background-image: url("images/body_bg.jpg");
background-attachment: fixed;
}
.navheader,
.note,
.tip {
background-image: url("images/note_bg.jpg");
background-attachment: fixed;
}
.warning,
.caution {
background-image: url("images/warning_bg.jpg");
background-attachment: fixed;
}
.figure,
.informalfigure,
.example,
.informalexample,
.table,
.informaltable {
background-image: url("images/figure_bg.jpg");
background-attachment: fixed;
}
*/
h1,
h2,
h3,
h4,
h5,
h6,
h7{
}
/*
Example of how to stick an image as part of the title.
div.article .titlepage .title
{
background-image: url("figures/white-on-black.png");
background-position: center;
background-repeat: repeat-x;
}
*/
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title,
div.article .titlepage .title
{
}
div.section div.section .titlepage .title,
div.sect2 .titlepage .title {
background: none;
}
h1.title {
background-color: transparent;
background-repeat: no-repeat;
height: 256px;
text-indent: -9000px;
overflow:hidden;
}
h2.subtitle {
background-color: transparent;
text-indent: -9000px;
overflow:hidden;
width: 0px;
display: none;
}
/*************************************** /
/ pippin.gimp.org specific alterations /
/ ***************************************/
/*
div.heading, div.navheader {
color: #777;
font-size: 80%;
padding: 0;
margin: 0;
text-align: left;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 50px;
background: url('/gfx/heading_bg.png') transparent;
background-repeat: repeat-x;
background-attachment: fixed;
border: none;
}
div.heading a {
color: #444;
}
div.footing, div.navfooter {
border: none;
color: #ddd;
font-size: 80%;
text-align:right;
width: 100%;
padding-top: 10px;
position: absolute;
bottom: 0px;
left: 0px;
background: url('/gfx/footing_bg.png') transparent;
}
*/
/****************** /
/ nasty ie tweaks /
/ ******************/
/*
div.heading, div.navheader {
width:expression(document.body.clientWidth + "px");
}
div.footing, div.navfooter {
width:expression(document.body.clientWidth + "px");
margin-left:expression("-5em");
}
body {
padding:expression("4em 5em 0em 5em");
}
*/
/**************************************** /
/ mozilla vendor specific css extensions /
/ ****************************************/
/*
div.navfooter, div.footing{
-moz-opacity: 0.8em;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example,
.tip,
.warning,
.caution,
.note {
-moz-border-radius: 0.5em;
}
b.keycap,
.keycap {
-moz-border-radius: 0.3em;
}
*/
table tr td table tr td {
display: none;
}
hr {
display: none;
}
table {
border: 0em;
}
.photo {
float: right;
margin-left: 1.5em;
margin-bottom: 1.5em;
margin-top: 0em;
max-width: 17em;
border: 1px solid gray;
padding: 3px;
background: white;
}
.seperator {
padding-top: 2em;
clear: both;
}
#validators {
margin-top: 5em;
text-align: right;
color: #777;
}
@media print {
body {
font-size: 8pt;
}
.noprint {
display: none;
}
}
.tip,
.note {
background: #f0f0f2;
color: #333;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #333;
}
.tip a,
.note a {
color: #333;
text-decoration: underline;
}
.footnote {
font-size: small;
color: #333;
}
/* Changes the announcement text */
.tip h3,
.warning h3,
.caution h3,
.note h3 {
font-size:large;
color: #00557D;
}

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@ -1,622 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<appendix id='kernel-dev-concepts-appx'>
<title>Advanced Kernel Concepts</title>
<section id='kernel-big-picture'>
<title>Yocto Project Kernel Development and Maintenance</title>
<para>
Kernels available through the Yocto Project (Yocto Linux kernels),
like other kernels, are based off the Linux kernel releases from
<ulink url='http://www.kernel.org'></ulink>.
At the beginning of a major Linux kernel development cycle, the
Yocto Project team chooses a Linux kernel based on factors such as
release timing, the anticipated release timing of final upstream
<filename>kernel.org</filename> versions, and Yocto Project
feature requirements.
Typically, the Linux kernel chosen is in the final stages of
development by the Linux community.
In other words, the Linux kernel is in the release candidate
or "rc" phase and has yet to reach final release.
But, by being in the final stages of external development, the
team knows that the <filename>kernel.org</filename> final release
will clearly be within the early stages of the Yocto Project
development window.
</para>
<para>
This balance allows the Yocto Project team to deliver the most
up-to-date Yocto Linux kernel possible, while still ensuring that
the team has a stable official release for the baseline Linux
kernel version.
</para>
<para>
As implied earlier, the ultimate source for Yocto Linux kernels
are released kernels from <filename>kernel.org</filename>.
In addition to a foundational kernel from
<filename>kernel.org</filename>, the available Yocto Linux kernels
contain a mix of important new mainline developments, non-mainline
developments (when no alternative exists), Board Support Package
(BSP) developments, and custom features.
These additions result in a commercially released Yocto
Project Linux kernel that caters to specific embedded designer
needs for targeted hardware.
</para>
<para>
You can find a web interface to the Yocto Linux kernels in the
<ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
at
<ulink url='&YOCTO_GIT_URL;'></ulink>.
If you look at the interface, you will see to the left a
grouping of Git repositories titled "Yocto Linux Kernel".
Within this group, you will find several Linux Yocto kernels
developed and included with Yocto Project releases:
<itemizedlist>
<listitem><para>
<emphasis><filename>linux-yocto-4.1</filename>:</emphasis>
The stable Yocto Project kernel to use with the Yocto
Project Release 2.0.
This kernel is based on the Linux 4.1 released kernel.
</para></listitem>
<listitem><para>
<emphasis><filename>linux-yocto-4.4</filename>:</emphasis>
The stable Yocto Project kernel to use with the Yocto
Project Release 2.1.
This kernel is based on the Linux 4.4 released kernel.
</para></listitem>
<listitem><para>
<emphasis><filename>linux-yocto-4.6</filename>:</emphasis>
A temporary kernel that is not tied to any Yocto Project
release.
</para></listitem>
<listitem><para>
<emphasis><filename>linux-yocto-4.8</filename>:</emphasis>
The stable yocto Project kernel to use with the Yocto
Project Release 2.2.
</para></listitem>
<listitem><para>
<emphasis><filename>linux-yocto-4.9</filename>:</emphasis>
The stable Yocto Project kernel to use with the Yocto
Project Release 2.3.
This kernel is based on the Linux 4.9 released kernel.
</para></listitem>
<listitem><para>
<emphasis><filename>linux-yocto-4.10</filename>:</emphasis>
The default stable Yocto Project kernel to use with the
Yocto Project Release 2.3.
This kernel is based on the Linux 4.10 released kernel.
</para></listitem>
<listitem><para>
<emphasis><filename>linux-yocto-4.12</filename>:</emphasis>
The default stable Yocto Project kernel to use with the
Yocto Project Release 2.4.
This kernel is based on the Linux 4.12 released kernel.
</para></listitem>
<listitem><para>
<emphasis><filename>yocto-kernel-cache</filename>:</emphasis>
The <filename>linux-yocto-cache</filename> contains
patches and configurations for the linux-yocto kernel
tree.
This repository is useful when working on the linux-yocto
kernel.
For more information on this "Advanced Kernel Metadata",
see the
"<link linkend='kernel-dev-advanced'>Working With Advanced Metadata (<filename>yocto-kernel-cache</filename>)</link>"
Chapter.
</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>
<note><title>Notes</title>
Long Term Support Initiative (LTSI) for Yocto Linux
kernels is as follows:
<itemizedlist>
<listitem><para>
For Yocto Project releases 1.7, 1.8, and 2.0,
the LTSI kernel is
<filename>linux-yocto-3.14</filename>.
</para></listitem>
<listitem><para>
For Yocto Project releases 2.1, 2.2, and 2.3,
the LTSI kernel is <filename>linux-yocto-4.1</filename>.
</para></listitem>
<listitem><para>
For Yocto Project release 2.4, the LTSI kernel is
<filename>linux-yocto-4.9</filename>
</para></listitem>
<listitem><para>
<filename>linux-yocto-4.4</filename> is an LTS
kernel.
</para></listitem>
</itemizedlist>
</note>
</para>
<para>
Once a Yocto Linux kernel is officially released, the Yocto
Project team goes into their next development cycle, or upward
revision (uprev) cycle, while still continuing maintenance on the
released kernel.
It is important to note that the most sustainable and stable way
to include feature development upstream is through a kernel uprev
process.
Back-porting hundreds of individual fixes and minor features from
various kernel versions is not sustainable and can easily
compromise quality.
</para>
<para>
During the uprev cycle, the Yocto Project team uses an ongoing
analysis of Linux kernel development, BSP support, and release
timing to select the best possible <filename>kernel.org</filename>
Linux kernel version on which to base subsequent Yocto Linux
kernel development.
The team continually monitors Linux community kernel development
to look for significant features of interest.
The team does consider back-porting large features if they have a
significant advantage.
User or community demand can also trigger a back-port or creation
of new functionality in the Yocto Project baseline kernel during
the uprev cycle.
</para>
<para>
Generally speaking, every new Linux kernel both adds features and
introduces new bugs.
These consequences are the basic properties of upstream
Linux kernel development and are managed by the Yocto Project
team's Yocto Linux kernel development strategy.
It is the Yocto Project team's policy to not back-port minor
features to the released Yocto Linux kernel.
They only consider back-porting significant technological
jumps &dash; and, that is done after a complete gap analysis.
The reason for this policy is that back-porting any small to
medium sized change from an evolving Linux kernel can easily
create mismatches, incompatibilities and very subtle errors.
</para>
<para>
The policies described in this section result in both a stable
and a cutting edge Yocto Linux kernel that mixes forward ports of
existing Linux kernel features and significant and critical new
functionality.
Forward porting Linux kernel functionality into the Yocto Linux
kernels available through the Yocto Project can be thought of as
a "micro uprev."
The many "micro uprevs" produce a Yocto Linux kernel version with
a mix of important new mainline, non-mainline, BSP developments
and feature integrations.
This Yocto Linux kernel gives insight into new features and
allows focused amounts of testing to be done on the kernel,
which prevents surprises when selecting the next major uprev.
The quality of these cutting edge Yocto Linux kernels is evolving
and the kernels are used in leading edge feature and BSP
development.
</para>
</section>
<section id='yocto-linux-kernel-architecture-and-branching-strategies'>
<title>Yocto Linux Kernel Architecture and Branching Strategies</title>
<para>
As mentioned earlier, a key goal of the Yocto Project is
to present the developer with a kernel that has a clear and
continuous history that is visible to the user.
The architecture and mechanisms, in particular the branching
strategies, used achieve that goal in a manner similar to
upstream Linux kernel development in
<filename>kernel.org</filename>.
</para>
<para>
You can think of a Yocto Linux kernel as consisting of a
baseline Linux kernel with added features logically structured
on top of the baseline.
The features are tagged and organized by way of a branching
strategy implemented by the Yocto Project team using the
Source Code Manager (SCM) Git.
<note><title>Notes</title>
<itemizedlist>
<listitem><para>
Git is the obvious SCM for meeting the Yocto Linux
kernel organizational and structural goals described
in this section.
Not only is Git the SCM for Linux kernel development in
<filename>kernel.org</filename> but, Git continues to
grow in popularity and supports many different work
flows, front-ends and management techniques.
</para></listitem>
<listitem><para>
You can find documentation on Git at
<ulink url='http://git-scm.com/documentation'></ulink>.
You can also get an introduction to Git as it
applies to the Yocto Project in the
"<ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>"
section in the Yocto Project Overview and Concepts
Manual.
The latter reference provides an overview of
Git and presents a minimal set of Git commands
that allows you to be functional using Git.
You can use as much, or as little, of what Git
has to offer to accomplish what you need for your
project.
You do not have to be a "Git Expert" in order to
use it with the Yocto Project.
</para></listitem>
</itemizedlist>
</note>
</para>
<para>
Using Git's tagging and branching features, the Yocto Project
team creates kernel branches at points where functionality is
no longer shared and thus, needs to be isolated.
For example, board-specific incompatibilities would require
different functionality and would require a branch to
separate the features.
Likewise, for specific kernel features, the same branching
strategy is used.
</para>
<para>
This "tree-like" architecture results in a structure that has
features organized to be specific for particular functionality,
single kernel types, or a subset of kernel types.
Thus, the user has the ability to see the added features and the
commits that make up those features.
In addition to being able to see added features, the user
can also view the history of what made up the baseline
Linux kernel.
</para>
<para>
Another consequence of this strategy results in not having to
store the same feature twice internally in the tree.
Rather, the kernel team stores the unique differences required
to apply the feature onto the kernel type in question.
<note>
The Yocto Project team strives to place features in the tree
such that features can be shared by all boards and kernel
types where possible.
However, during development cycles or when large features
are merged, the team cannot always follow this practice.
In those cases, the team uses isolated branches to merge
features.
</note>
</para>
<para>
BSP-specific code additions are handled in a similar manner to
kernel-specific additions.
Some BSPs only make sense given certain kernel types.
So, for these types, the team creates branches off the end
of that kernel type for all of the BSPs that are supported on
that kernel type.
From the perspective of the tools that create the BSP branch,
the BSP is really no different than a feature.
Consequently, the same branching strategy applies to BSPs as
it does to kernel features.
So again, rather than store the BSP twice, the team only
stores the unique differences for the BSP across the supported
multiple kernels.
</para>
<para>
While this strategy can result in a tree with a significant number
of branches, it is important to realize that from the developer's
point of view, there is a linear path that travels from the
baseline <filename>kernel.org</filename>, through a select
group of features and ends with their BSP-specific commits.
In other words, the divisions of the kernel are transparent and
are not relevant to the developer on a day-to-day basis.
From the developer's perspective, this path is the "master" branch
in Git terms.
The developer does not need to be aware of the existence of any
other branches at all.
Of course, value exists in the having these branches in the tree,
should a person decide to explore them.
For example, a comparison between two BSPs at either the commit
level or at the line-by-line code <filename>diff</filename> level
is now a trivial operation.
</para>
<para>
The following illustration shows the conceptual Yocto
Linux kernel.
<imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
</para>
<para>
In the illustration, the "Kernel.org Branch Point" marks the
specific spot (or Linux kernel release) from which the
Yocto Linux kernel is created.
From this point forward in the tree, features and differences
are organized and tagged.
</para>
<para>
The "Yocto Project Baseline Kernel" contains functionality that
is common to every kernel type and BSP that is organized
further along in the tree.
Placing these common features in the tree this way means
features do not have to be duplicated along individual
branches of the tree structure.
</para>
<para>
From the "Yocto Project Baseline Kernel", branch points represent
specific functionality for individual Board Support Packages
(BSPs) as well as real-time kernels.
The illustration represents this through three BSP-specific
branches and a real-time kernel branch.
Each branch represents some unique functionality for the BSP
or for a real-time Yocto Linux kernel.
</para>
<para>
In this example structure, the "Real-time (rt) Kernel" branch has
common features for all real-time Yocto Linux kernels and
contains more branches for individual BSP-specific real-time
kernels.
The illustration shows three branches as an example.
Each branch points the way to specific, unique features for a
respective real-time kernel as they apply to a given BSP.
</para>
<para>
The resulting tree structure presents a clear path of markers
(or branches) to the developer that, for all practical
purposes, is the Yocto Linux kernel needed for any given set of
requirements.
<note>
Keep in mind the figure does not take into account all the
supported Yocto Linux kernels, but rather shows a single
generic kernel just for conceptual purposes.
Also keep in mind that this structure represents the Yocto
Project
<ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
that are either pulled from during the build or established
on the host development system prior to the build by either
cloning a particular kernel's Git repository or by
downloading and unpacking a tarball.
</note>
</para>
<para>
Working with the kernel as a structured tree follows recognized
community best practices.
In particular, the kernel as shipped with the product, should be
considered an "upstream source" and viewed as a series of
historical and documented modifications (commits).
These modifications represent the development and stabilization
done by the Yocto Project kernel development team.
</para>
<para>
Because commits only change at significant release points in the
product life cycle, developers can work on a branch created
from the last relevant commit in the shipped Yocto Project Linux
kernel.
As mentioned previously, the structure is transparent to the
developer because the kernel tree is left in this state after
cloning and building the kernel.
</para>
</section>
<section id='kernel-build-file-hierarchy'>
<title>Kernel Build File Hierarchy</title>
<para>
Upstream storage of all the available kernel source code is
one thing, while representing and using the code on your host
development system is another.
Conceptually, you can think of the kernel source repositories
as all the source files necessary for all the supported
Yocto Linux kernels.
As a developer, you are just interested in the source files
for the kernel on which you are working.
And, furthermore, you need them available on your host system.
</para>
<para>
Kernel source code is available on your host system several
different ways:
<itemizedlist>
<listitem><para>
<emphasis>Files Accessed While using <filename>devtool</filename>:</emphasis>
<filename>devtool</filename>, which is available with the
Yocto Project, is the preferred method by which to
modify the kernel.
See the
"<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
section.
</para></listitem>
<listitem><para>
<emphasis>Cloned Repository:</emphasis>
If you are working in the kernel all the time, you probably
would want to set up your own local Git repository of the
Yocto Linux kernel tree.
For information on how to clone a Yocto Linux kernel
Git repository, see the
"<link linkend='preparing-the-build-host-to-work-on-the-kernel'>Preparing the Build Host to Work on the Kernel</link>"
section.
</para></listitem>
<listitem><para>
<emphasis>Temporary Source Files from a Build:</emphasis>
If you just need to make some patches to the kernel using
a traditional BitBake workflow (i.e. not using the
<filename>devtool</filename>), you can access temporary
kernel source files that were extracted and used during
a kernel build.
</para></listitem>
</itemizedlist>
</para>
<para>
The temporary kernel source files resulting from a build using
BitBake have a particular hierarchy.
When you build the kernel on your development system, all files
needed for the build are taken from the source repositories
pointed to by the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
variable and gathered in a temporary work area where they are
subsequently used to create the unique kernel.
Thus, in a sense, the process constructs a local source tree
specific to your kernel from which to generate the new kernel
image.
</para>
<para>
The following figure shows the temporary file structure
created on your host system when you build the kernel using
Bitbake.
This
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
contains all the source files used during the build.
<imagedata fileref="figures/kernel-overview-2-generic.png"
width="6in" depth="5in" align="center" scale="100" />
</para>
<para>
Again, for additional information on the Yocto Project kernel's
architecture and its branching strategy, see the
"<link linkend='yocto-linux-kernel-architecture-and-branching-strategies'>Yocto Linux Kernel Architecture and Branching Strategies</link>"
section.
You can also reference the
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
and
"<link linkend='using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</link>"
sections for detailed example that modifies the kernel.
</para>
</section>
<section id='determining-hardware-and-non-hardware-features-for-the-kernel-configuration-audit-phase'>
<title>Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase</title>
<para>
This section describes part of the kernel configuration audit
phase that most developers can ignore.
For general information on kernel configuration including
<filename>menuconfig</filename>, <filename>defconfig</filename>
files, and configuration fragments, see the
"<link linkend='configuring-the-kernel'>Configuring the Kernel</link>"
section.
</para>
<para>
During this part of the audit phase, the contents of the final
<filename>.config</filename> file are compared against the
fragments specified by the system.
These fragments can be system fragments, distro fragments,
or user-specified configuration elements.
Regardless of their origin, the OpenEmbedded build system
warns the user if a specific option is not included in the
final kernel configuration.
</para>
<para>
By default, in order to not overwhelm the user with
configuration warnings, the system only reports missing
"hardware" options as they could result in a boot
failure or indicate that important hardware is not available.
</para>
<para>
To determine whether or not a given option is "hardware" or
"non-hardware", the kernel Metadata in
<filename>yocto-kernel-cache</filename> contains files that
classify individual or groups of options as either hardware
or non-hardware.
To better show this, consider a situation where the
<filename>yocto-kernel-cache</filename> contains the following
files:
<literallayout class='monospaced'>
yocto-kernel-cache/features/drm-psb/hardware.cfg
yocto-kernel-cache/features/kgdb/hardware.cfg
yocto-kernel-cache/ktypes/base/hardware.cfg
yocto-kernel-cache/bsp/mti-malta32/hardware.cfg
yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg
yocto-kernel-cache/bsp/qemuarma9/hardware.cfg
yocto-kernel-cache/bsp/mti-malta64/hardware.cfg
yocto-kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
yocto-kernel-cache/bsp/common-pc/hardware.cfg
yocto-kernel-cache/bsp/common-pc-64/hardware.cfg
yocto-kernel-cache/features/rfkill/non-hardware.cfg
yocto-kernel-cache/ktypes/base/non-hardware.cfg
yocto-kernel-cache/features/aufs/non-hardware.kcf
yocto-kernel-cache/features/ocf/non-hardware.kcf
yocto-kernel-cache/ktypes/base/non-hardware.kcf
yocto-kernel-cache/ktypes/base/hardware.kcf
yocto-kernel-cache/bsp/qemu-ppc32/hardware.kcf
</literallayout>
The following list provides explanations for the various
files:
<itemizedlist>
<listitem><para>
<filename>hardware.kcf</filename>:
Specifies a list of kernel Kconfig files that contain
hardware options only.
</para></listitem>
<listitem><para>
<filename>non-hardware.kcf</filename>:
Specifies a list of kernel Kconfig files that contain
non-hardware options only.
</para></listitem>
<listitem><para>
<filename>hardware.cfg</filename>:
Specifies a list of kernel <filename>CONFIG_</filename>
options that are hardware, regardless of whether or not
they are within a Kconfig file specified by a hardware
or non-hardware Kconfig file (i.e.
<filename>hardware.kcf</filename> or
<filename>non-hardware.kcf</filename>).
</para></listitem>
<listitem><para>
<filename>non-hardware.cfg</filename>:
Specifies a list of kernel <filename>CONFIG_</filename>
options that are not hardware, regardless of whether or
not they are within a Kconfig file specified by a
hardware or non-hardware Kconfig file (i.e.
<filename>hardware.kcf</filename> or
<filename>non-hardware.kcf</filename>).
</para></listitem>
</itemizedlist>
Here is a specific example using the
<filename>kernel-cache/bsp/mti-malta32/hardware.cfg</filename>:
<literallayout class='monospaced'>
CONFIG_SERIAL_8250
CONFIG_SERIAL_8250_CONSOLE
CONFIG_SERIAL_8250_NR_UARTS
CONFIG_SERIAL_8250_PCI
CONFIG_SERIAL_CORE
CONFIG_SERIAL_CORE_CONSOLE
CONFIG_VGA_ARB
</literallayout>
The kernel configuration audit automatically detects these
files (hence the names must be exactly the ones discussed here),
and uses them as inputs when generating warnings about the
final <filename>.config</filename> file.
</para>
<para>
A user-specified kernel Metadata repository, or recipe space
feature, can use these same files to classify options that are
found within its <filename>.cfg</filename> files as hardware
or non-hardware, to prevent the OpenEmbedded build system from
producing an error or warning when an option is not in the
final <filename>.config</filename> file.
</para>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,28 +0,0 @@
<?xml version='1.0'?>
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
<xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<!--
<xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
<xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-->
<xsl:include href="../template/permalinks.xsl"/>
<xsl:include href="../template/section.title.xsl"/>
<xsl:include href="../template/component.title.xsl"/>
<xsl:include href="../template/division.title.xsl"/>
<xsl:include href="../template/formal.object.heading.xsl"/>
<xsl:param name="html.stylesheet" select="'kernel-dev-style.css'" />
<xsl:param name="chapter.autolabel" select="1" />
<xsl:param name="appendix.autolabel">A</xsl:param>
<xsl:param name="section.autolabel" select="1" />
<xsl:param name="section.label.includes.component.label" select="1" />
</xsl:stylesheet>

View File

@ -1,143 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<appendix id='kernel-dev-faq'>
<title>Kernel Development FAQ</title>
<section id='kernel-dev-faq-section'>
<title>Common Questions and Solutions</title>
<para>
The following lists some solutions for common questions.
<qandaset>
<qandaentry>
<question>
<para>
How do I use my own Linux kernel <filename>.config</filename>
file?
</para>
</question>
<answer>
<para>
Refer to the "<link linkend='changing-the-configuration'>Changing the Configuration</link>"
section for information.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I create configuration fragments?
</para>
</question>
<answer>
<para>
Refer to the
"<link linkend='creating-config-fragments'>Creating Configuration Fragments</link>"
section for information.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I use my own Linux kernel sources?
</para>
</question>
<answer>
<para>
Refer to the "<link linkend='working-with-your-own-sources'>Working With Your Own Sources</link>"
section for information.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I install/not-install the kernel image on the rootfs?
</para>
</question>
<answer>
<para>
The kernel image (e.g. <filename>vmlinuz</filename>) is provided
by the <filename>kernel-image</filename> package.
Image recipes depend on <filename>kernel-base</filename>.
To specify whether or not the kernel
image is installed in the generated root filesystem, override
<filename>RDEPENDS_kernel-base</filename> to include or not
include "kernel-image".</para>
<para>See the
"<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
section in the Yocto Project Development Tasks Manual
for information on how to use an append file to
override metadata.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I install a specific kernel module?
</para>
</question>
<answer>
<para>
Linux kernel modules are packaged individually.
To ensure a specific kernel module is included in an image,
include it in the appropriate machine
<ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>
variable.</para>
<para>These other variables are useful for installing specific
modules:
<literallayout class='monospaced'>
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</filename></ulink>
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RDEPENDS'><filename>MACHINE_EXTRA_RDEPENDS</filename></ulink>
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS'><filename>MACHINE_EXTRA_RRECOMMENDS</filename></ulink>
</literallayout>
For example, set the following in the <filename>qemux86.conf</filename>
file to include the <filename>ab123</filename> kernel modules
with images built for the <filename>qemux86</filename> machine:
<literallayout class='monospaced'>
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
</literallayout>
For more information, see the
"<link linkend='incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</link>"
section.
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
How do I change the Linux kernel command line?
</para>
</question>
<answer>
<para>
The Linux kernel command line is typically specified in
the machine config using the <filename>APPEND</filename> variable.
For example, you can add some helpful debug information doing
the following:
<literallayout class='monospaced'>
APPEND += "printk.time=y initcall_debug debug"
</literallayout>
</para>
</answer>
</qandaentry>
</qandaset>
</para>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,260 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<chapter id='kernel-dev-intro'>
<title>Introduction</title>
<section id='kernel-dev-overview'>
<title>Overview</title>
<para>
Regardless of how you intend to make use of the Yocto Project,
chances are you will work with the Linux kernel.
This manual describes how to set up your build host to support
kernel development, introduces the kernel development process,
provides background information on the Yocto Linux kernel
<ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
describes common tasks you can perform using the kernel tools,
shows you how to use the kernel Metadata needed to work with
the kernel inside the Yocto Project, and provides insight into how
the Yocto Project team develops and maintains Yocto Linux kernel
Git repositories and Metadata.
</para>
<para>
Each Yocto Project release has a set of Yocto Linux kernel recipes,
whose Git repositories you can view in the Yocto
<ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> under
the "Yocto Linux Kernel" heading.
New recipes for the release track the latest Linux kernel
upstream developments from
<ulink url='http://www.kernel.org'></ulink> and introduce
newly-supported platforms.
Previous recipes in the release are refreshed and supported for at
least one additional Yocto Project release.
As they align, these previous releases are updated to include the
latest from the Long Term Support Initiative (LTSI) project.
You can learn more about Yocto Linux kernels and LTSI in the
"<link linkend='kernel-big-picture'>Yocto Project Kernel Development and Maintenance</link>"
section.
</para>
<para>
Also included is a Yocto Linux kernel development recipe
(<filename>linux-yocto-dev.bb</filename>) should you want to work
with the very latest in upstream Yocto Linux kernel development and
kernel Metadata development.
<note>
For more on Yocto Linux kernels, see the
"<link linkend='kernel-big-picture'>Yocto Project Kernel Development and Maintenance</link>
section.
</note>
</para>
<para>
The Yocto Project also provides a powerful set of kernel
tools for managing Yocto Linux kernel sources and configuration data.
You can use these tools to make a single configuration change,
apply multiple patches, or work with your own kernel sources.
</para>
<para>
In particular, the kernel tools allow you to generate configuration
fragments that specify only what you must, and nothing more.
Configuration fragments only need to contain the highest level
visible <filename>CONFIG</filename> options as presented by the
Yocto Linux kernel <filename>menuconfig</filename> system.
Contrast this against a complete Yocto Linux kernel
<filename>.config</filename> file, which includes all the automatically
selected <filename>CONFIG</filename> options.
This efficiency reduces your maintenance effort and allows you
to further separate your configuration in ways that make sense for
your project.
A common split separates policy and hardware.
For example, all your kernels might support the
<filename>proc</filename> and <filename>sys</filename> filesystems,
but only specific boards require sound, USB, or specific drivers.
Specifying these configurations individually allows you to aggregate
them together as needed, but maintains them in only one place.
Similar logic applies to separating source changes.
</para>
<para>
If you do not maintain your own kernel sources and need to make
only minimal changes to the sources, the released recipes provide a
vetted base upon which to layer your changes.
Doing so allows you to benefit from the continual kernel
integration and testing performed during development of the
Yocto Project.
</para>
<para>
If, instead, you have a very specific Linux kernel source tree
and are unable to align with one of the official Yocto Linux kernel
recipes, an alternative exists by which you can use the Yocto
Project Linux kernel tools with your own kernel sources.
</para>
<para>
The remainder of this manual provides instructions for completing
specific Linux kernel development tasks.
These instructions assume you are comfortable working with
<ulink url='http://openembedded.org/wiki/Bitbake'>BitBake</ulink>
recipes and basic open-source development tools.
Understanding these concepts will facilitate the process of working
with the kernel recipes.
If you find you need some additional background, please be sure to
review and understand the following documentation:
<itemizedlist>
<listitem><para>
<ulink url='&YOCTO_DOCS_BRIEF_URL;'>Yocto Project Quick Build</ulink>
document.
</para></listitem>
<listitem><para>
<ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>.
</para></listitem>
<listitem><para>
<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'><filename>devtool</filename> workflow</ulink>
as described in the Yocto Project Application Development and
the Extensible Software Development Kit (eSDK) manual.
</para></listitem>
<listitem><para>
The
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
section in the Yocto Project Development Tasks Manual.
</para></listitem>
<listitem><para>
The
"<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
section.
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='kernel-modification-workflow'>
<title>Kernel Modification Workflow</title>
<para>
Kernel modification involves changing the Yocto Project kernel,
which could involve changing configuration options as well as adding
new kernel recipes.
Configuration changes can be added in the form of configuration
fragments, while recipe modification comes through the kernel's
<filename>recipes-kernel</filename> area in a kernel layer you create.
</para>
<para>
This section presents a high-level overview of the Yocto Project
kernel modification workflow.
The illustration and accompanying list provide general information
and references for further information.
<imagedata fileref="figures/kernel-dev-flow.png"
width="9in" depth="5in" align="center" scalefit="1" />
</para>
<para>
<orderedlist>
<listitem><para>
<emphasis>Set up Your Host Development System to Support
Development Using the Yocto Project</emphasis>:
See the
"<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-start'>Setting Up the Development Host to Use the Yocto Project</ulink>"
section in the Yocto Project Development Tasks Manual for
options on how to get a build host ready to use the Yocto
Project.
</para></listitem>
<listitem><para>
<emphasis>Set Up Your Host Development System for Kernel Development:</emphasis>
It is recommended that you use <filename>devtool</filename>
and an extensible SDK for kernel development.
Alternatively, you can use traditional kernel development
methods with the Yocto Project.
Either way, there are steps you need to take to get the
development environment ready.</para>
<para>Using <filename>devtool</filename> and the eSDK requires
that you have a clean build of the image and that you are
set up with the appropriate eSDK.
For more information, see the
"<link linkend='getting-ready-to-develop-using-devtool'>Getting Ready to Develop Using <filename>devtool</filename></link>"
section.</para>
<para>Using traditional kernel development requires that you
have the kernel source available in an isolated local Git
repository.
For more information, see the
"<link linkend='getting-ready-for-traditional-kernel-development'>Getting Ready for Traditional Kernel Development</link>"
section.
</para></listitem>
<listitem><para>
<emphasis>Make Changes to the Kernel Source Code if
applicable:</emphasis>
Modifying the kernel does not always mean directly
changing source files.
However, if you have to do this, you make the changes to the
files in the eSDK's Build Directory if you are using
<filename>devtool</filename>.
For more information, see the
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
section.</para>
<para>If you are using traditional kernel development, you
edit the source files in the kernel's local Git repository.
For more information, see the
"<link linkend='using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</link>"
section.
</para></listitem>
<listitem><para>
<emphasis>Make Kernel Configuration Changes if
Applicable:</emphasis>
If your situation calls for changing the kernel's
configuration, you can use
<link linkend='using-menuconfig'><filename>menuconfig</filename></link>,
which allows you to interactively develop and test the
configuration changes you are making to the kernel.
Saving changes you make with <filename>menuconfig</filename>
updates the kernel's <filename>.config</filename> file.
<note><title>Warning</title>
Try to resist the temptation to directly edit an
existing <filename>.config</filename> file, which is
found in the Build Directory among the source code
used for the build.
Doing so, can produce unexpected results when the
OpenEmbedded build system regenerates the configuration
file.
</note>
Once you are satisfied with the configuration
changes made using <filename>menuconfig</filename>
and you have saved them, you can directly compare the
resulting <filename>.config</filename> file against an
existing original and gather those changes into a
<link linkend='creating-config-fragments'>configuration fragment file</link>
to be referenced from within the kernel's
<filename>.bbappend</filename> file.</para>
<para>Additionally, if you are working in a BSP layer
and need to modify the BSP's kernel's configuration,
you can use <filename>menuconfig</filename>.
</para></listitem>
<listitem><para>
<emphasis>Rebuild the Kernel Image With Your Changes:</emphasis>
Rebuilding the kernel image applies your changes.
Depending on your target hardware, you can verify your changes
on actual hardware or perhaps QEMU.
</para></listitem>
</orderedlist>
The remainder of this developer's guide covers common tasks typically
used during kernel development, advanced Metadata usage, and Yocto Linux
kernel maintenance concepts.
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,357 +0,0 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<appendix id='kernel-dev-maint-appx'>
<title>Kernel Maintenance</title>
<section id='tree-construction'>
<title>Tree Construction</title>
<para>
This section describes construction of the Yocto Project kernel
source repositories as accomplished by the Yocto Project team to
create Yocto Linux kernel repositories.
These kernel repositories are found under the heading "Yocto Linux
Kernel" at
<ulink url='&YOCTO_GIT_URL;'>&YOCTO_GIT_URL;</ulink>
and are shipped as part of a Yocto Project release.
The team creates these repositories by compiling and executing the
set of feature descriptions for every BSP and feature in the
product.
Those feature descriptions list all necessary patches,
configurations, branches, tags, and feature divisions found in a
Yocto Linux kernel.
Thus, the Yocto Project Linux kernel repository (or tree) and
accompanying Metadata in the
<filename>yocto-kernel-cache</filename> are built.
</para>
<para>
The existence of these repositories allow you to access and clone a
particular Yocto Project Linux kernel repository and use it to
build images based on their configurations and features.
</para>
<para>
You can find the files used to describe all the valid features and
BSPs in the Yocto Project Linux kernel in any clone of the Yocto
Project Linux kernel source repository and
<filename>yocto-kernel-cache</filename> Git trees.
For example, the following commands clone the Yocto Project
baseline Linux kernel that branches off
<filename>linux.org</filename> version 4.12 and the
<filename>yocto-kernel-cache</filename>, which contains stores of
kernel Metadata:
<literallayout class='monospaced'>
$ git clone git://git.yoctoproject.org/linux-yocto-4.12
$ git clone git://git.yoctoproject.org/linux-kernel-cache
</literallayout>
For more information on how to set up a local Git repository of
the Yocto Project Linux kernel files, see the
"<link linkend='preparing-the-build-host-to-work-on-the-kernel'>Preparing the Build Host to Work on the Kernel</link>"
section.
</para>
<para>
Once you have cloned the kernel Git repository and the
cache of Metadata on your local machine, you can discover the
branches that are available in the repository using the following
Git command:
<literallayout class='monospaced'>
$ git branch -a
</literallayout>
Checking out a branch allows you to work with a particular
Yocto Linux kernel.
For example, the following commands check out the
"standard/beagleboard" branch of the Yocto Linux kernel repository
and the "yocto-4.12" branch of the
<filename>yocto-kernel-cache</filename> repository:
<literallayout class='monospaced'>
$ cd ~/linux-yocto-4.12
$ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard
$ cd ~/linux-kernel-cache
$ git checkout -b my-4.12-metadata remotes/origin/yocto-4.12
</literallayout>
<note>
Branches in the <filename>yocto-kernel-cache</filename>
repository correspond to Yocto Linux kernel versions
(e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
</note>
Once you have checked out and switched to appropriate branches,
you can see a snapshot of all the kernel source files used to
used to build that particular Yocto Linux kernel for a
particular board.
</para>
<para>
To see the features and configurations for a particular Yocto
Linux kernel, you need to examine the
<filename>yocto-kernel-cache</filename> Git repository.
As mentioned, branches in the
<filename>yocto-kernel-cache</filename> repository correspond to
Yocto Linux kernel versions (e.g. <filename>yocto-4.12</filename>).
Branches contain descriptions in the form of
<filename>.scc</filename> and <filename>.cfg</filename> files.
</para>
<para>
You should realize, however, that browsing your local
<filename>yocto-kernel-cache</filename> repository for feature
descriptions and patches is not an effective way to determine what
is in a particular kernel branch.
Instead, you should use Git directly to discover the changes in
a branch.
Using Git is an efficient and flexible way to inspect changes to
the kernel.
<note>
Ground up reconstruction of the complete kernel tree is an
action only taken by the Yocto Project team during an active
development cycle.
When you create a clone of the kernel Git repository, you are
simply making it efficiently available for building and
development.
</note>
</para>
<para>
The following steps describe what happens when the Yocto Project
Team constructs the Yocto Project kernel source Git repository
(or tree) found at
<ulink url='&YOCTO_GIT_URL;'></ulink> given the
introduction of a new top-level kernel feature or BSP.
The following actions effectively provide the Metadata
and create the tree that includes the new feature, patch, or BSP:
<orderedlist>
<listitem><para>
<emphasis>Pass Feature to the OpenEmbedded Build System:</emphasis>
A top-level kernel feature is passed to the kernel build
subsystem.
Normally, this feature is a BSP for a particular kernel
type.
</para></listitem>
<listitem><para>
<emphasis>Locate Feature:</emphasis>
The file that describes the top-level feature is located
by searching these system directories:
<itemizedlist>
<listitem><para>
The in-tree kernel-cache directories, which are
located in the
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache/tree/bsp'><filename>yocto-kernel-cache</filename></ulink>
repository organized under the "Yocto Linux Kernel"
heading in the
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Yocto Project Source Repositories</ulink>.
</para></listitem>
<listitem><para>
Areas pointed to by <filename>SRC_URI</filename>
statements found in kernel recipes
</para></listitem>
</itemizedlist>
For a typical build, the target of the search is a
feature description in an <filename>.scc</filename> file
whose name follows this format (e.g.
<filename>beaglebone-standard.scc</filename> and
<filename>beaglebone-preempt-rt.scc</filename>):
<literallayout class='monospaced'>
<replaceable>bsp_root_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
</literallayout>
</para></listitem>
<listitem><para>
<emphasis>Expand Feature:</emphasis>
Once located, the feature description is either expanded
into a simple script of actions, or into an existing
equivalent script that is already part of the shipped
kernel.
</para></listitem>
<listitem><para>
<emphasis>Append Extra Features:</emphasis>
Extra features are appended to the top-level feature
description.
These features can come from the
<ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
variable in recipes.
</para></listitem>
<listitem><para>
<emphasis>Locate, Expand, and Append Each Feature:</emphasis>
Each extra feature is located, expanded and appended to
the script as described in step three.
</para></listitem>
<listitem><para>
<emphasis>Execute the Script:</emphasis>
The script is executed to produce files
<filename>.scc</filename> and <filename>.cfg</filename>
files in appropriate directories of the
<filename>yocto-kernel-cache</filename> repository.
These files are descriptions of all the branches, tags,
patches and configurations that need to be applied to the
base Git repository to completely create the
source (build) branch for the new BSP or feature.
</para></listitem>
<listitem><para>
<emphasis>Clone Base Repository:</emphasis>
The base repository is cloned, and the actions
listed in the <filename>yocto-kernel-cache</filename>
directories are applied to the tree.
</para></listitem>
<listitem><para>
<emphasis>Perform Cleanup:</emphasis>
The Git repositories are left with the desired branches
checked out and any required branching, patching and
tagging has been performed.
</para></listitem>
</orderedlist>
</para>
<para>
The kernel tree and cache are ready for developer consumption to
be locally cloned, configured, and built into a Yocto Project
kernel specific to some target hardware.
<note><title>Notes</title>
<itemizedlist>
<listitem><para>
The generated <filename>yocto-kernel-cache</filename>
repository adds to the kernel as shipped with the Yocto
Project release.
Any add-ons and configuration data are applied to the
end of an existing branch.
The full repository generation that is found in the
official Yocto Project kernel repositories at
<ulink url='&YOCTO_GIT_URL;'>http://git.yoctoproject.org</ulink>
is the combination of all supported boards and
configurations.
</para></listitem>
<listitem><para>
The technique the Yocto Project team uses is flexible
and allows for seamless blending of an immutable
history with additional patches specific to a
deployment.
Any additions to the kernel become an integrated part
of the branches.
</para></listitem>
<listitem><para>
The full kernel tree that you see on
<ulink url='&YOCTO_GIT_URL;'></ulink> is
generated through repeating the above steps for all
valid BSPs.
The end result is a branched, clean history tree that
makes up the kernel for a given release.
You can see the script (<filename>kgit-scc</filename>)
responsible for this in the
<ulink url='&YOCTO_GIT_URL;/cgit.cgi/yocto-kernel-tools/tree/tools'><filename>yocto-kernel-tools</filename></ulink>
repository.
</para></listitem>
<listitem><para>
The steps used to construct the full kernel tree are
the same steps that BitBake uses when it builds a
kernel image.
</para></listitem>
</itemizedlist>
</note>
</para>
</section>
<section id='build-strategy'>
<title>Build Strategy</title>
<para>
Once you have cloned a Yocto Linux kernel repository and the
cache repository (<filename>yocto-kernel-cache</filename>) onto
your development system, you can consider the compilation phase
of kernel development, which is building a kernel image.
Some prerequisites exist that are validated by the build process
before compilation starts:
</para>
<itemizedlist>
<listitem><para>
The
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
points to the kernel Git repository.
</para></listitem>
<listitem><para>
A BSP build branch with Metadata exists in the
<filename>yocto-kernel-cache</filename> repository.
The branch is based on the Yocto Linux kernel version and
has configurations and features grouped under the
<filename>yocto-kernel-cache/bsp</filename> directory.
For example, features and configurations for the
BeagleBone Board assuming a
<filename>linux-yocto_4.12</filename> kernel reside in the
following area of the <filename>yocto-kernel-cache</filename>
repository:
<literallayout class='monospaced'>
yocto-kernel-cache/bsp/beaglebone
</literallayout>
<note>
In the previous example, the "yocto-4.12" branch is
checked out in the <filename>yocto-kernel-cache</filename>
repository.
</note>
</para></listitem>
</itemizedlist>
<para>
The OpenEmbedded build system makes sure these conditions exist
before attempting compilation.
Other means, however, do exist, such as as bootstrapping a BSP.
</para>
<para>
Before building a kernel, the build process verifies the tree
and configures the kernel by processing all of the
configuration "fragments" specified by feature descriptions
in the <filename>.scc</filename> files.
As the features are compiled, associated kernel configuration
fragments are noted and recorded in the series of directories
in their compilation order.
The fragments are migrated, pre-processed and passed to the
Linux Kernel Configuration subsystem (<filename>lkc</filename>) as
raw input in the form of a <filename>.config</filename> file.
The <filename>lkc</filename> uses its own internal dependency
constraints to do the final processing of that information and
generates the final <filename>.config</filename> file that is used
during compilation.
</para>
<para>
Using the board's architecture and other relevant values from
the board's template, kernel compilation is started and a kernel
image is produced.
</para>
<para>
The other thing that you notice once you configure a kernel is that
the build process generates a build tree that is separate from
your kernel's local Git source repository tree.
This build tree has a name that uses the following form, where
<filename>${MACHINE}</filename> is the metadata name of the
machine (BSP) and "kernel_type" is one of the Yocto Project
supported kernel types (e.g. "standard"):
<literallayout class='monospaced'>
linux-${MACHINE}-<replaceable>kernel_type</replaceable>-build
</literallayout>
</para>
<para>
The existing support in the <filename>kernel.org</filename> tree
achieves this default functionality.
</para>
<para>
This behavior means that all the generated files for a particular
machine or BSP are now in the build tree directory.
The files include the final <filename>.config</filename> file,
all the <filename>.o</filename> files, the <filename>.a</filename>
files, and so forth.
Since each machine or BSP has its own separate
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
in its own separate branch of the Git repository, you can easily
switch between different builds.
</para>
</section>
</appendix>
<!--
vim: expandtab tw=80 ts=4
-->

View File

@ -1,991 +0,0 @@
/*
SPDX-License-Identifier: CC-BY-2.0-UK
Generic XHTML / DocBook XHTML CSS Stylesheet.
Browser wrangling and typographic design by
Oyvind Kolas / pippin@gimp.org
Customised for Poky by
Matthew Allum / mallum@o-hand.com
Thanks to:
Liam R. E. Quin
William Skaggs
Jakub Steiner
Structure
---------
The stylesheet is divided into the following sections:
Positioning
Margins, paddings, width, font-size, clearing.
Decorations
Borders, style
Colors
Colors
Graphics
Graphical backgrounds
Nasty IE tweaks
Workarounds needed to make it work in internet explorer,
currently makes the stylesheet non validating, but up until
this point it is validating.
Mozilla extensions
Transparency for footer
Rounded corners on boxes
*/
/*************** /
/ Positioning /
/ ***************/
body {
font-family: Verdana, Sans, sans-serif;
min-width: 640px;
width: 80%;
margin: 0em auto;
padding: 2em 5em 5em 5em;
color: #333;
}
h1,h2,h3,h4,h5,h6,h7 {
font-family: Arial, Sans;
color: #00557D;
clear: both;
}
h1 {
font-size: 2em;
text-align: left;
padding: 0em 0em 0em 0em;
margin: 2em 0em 0em 0em;
}
h2.subtitle {
margin: 0.10em 0em 3.0em 0em;
padding: 0em 0em 0em 0em;
font-size: 1.8em;
padding-left: 20%;
font-weight: normal;
font-style: italic;
}
h2 {
margin: 2em 0em 0.66em 0em;
padding: 0.5em 0em 0em 0em;
font-size: 1.5em;
font-weight: bold;
}
h3.subtitle {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
font-size: 142.14%;
text-align: right;
}
h3 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 140%;
font-weight: bold;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: bold;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 110%;
font-weight: bold;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("figures/kernel-dev-title.png");
background-position: left top;
margin-top: -256px;
padding-right: 50px;
margin-left: 0px;
text-align: right;
width: 740px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
color: #333;
clear: both;
}
.author tt.email {
font-size: 66%;
}
.titlepage hr {
width: 0em;
clear: both;
}
.revhistory {
padding-top: 2em;
clear: both;
}
.toc,
.list-of-tables,
.list-of-examples,
.list-of-figures {
padding: 1.33em 0em 2.5em 0em;
color: #00557D;
}
.toc p,
.list-of-tables p,
.list-of-figures p,
.list-of-examples p {
padding: 0em 0em 0em 0em;
padding: 0em 0em 0.3em;
margin: 1.5em 0em 0em 0em;
}
.toc p b,
.list-of-tables p b,
.list-of-figures p b,
.list-of-examples p b{
font-size: 100.0%;
font-weight: bold;
}
.toc dl,
.list-of-tables dl,
.list-of-figures dl,
.list-of-examples dl {
margin: 0em 0em 0.5em 0em;
padding: 0em 0em 0em 0em;
}
.toc dt {
margin: 0em 0em 0em 0em;
padding: 0em 0em 0em 0em;
}
.toc dd {
margin: 0em 0em 0em 2.6em;
padding: 0em 0em 0em 0em;
}
div.glossary dl,
div.variablelist dl {
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
font-weight: normal;
width: 20em;
text-align: right;
}
.variablelist dl dt {
margin-top: 0.5em;
}
.glossary dl dd,
.variablelist dl dd {
margin-top: -1em;
margin-left: 25.5em;
}
.glossary dd p,
.variablelist dd p {
margin-top: 0em;
margin-bottom: 1em;
}
div.calloutlist table td {
padding: 0em 0em 0em 0em;
margin: 0em 0em 0em 0em;
}
div.calloutlist table td p {
margin-top: 0em;
margin-bottom: 1em;
}
div p.copyright {
text-align: left;
}
div.legalnotice p.legalnotice-title {
margin-bottom: 0em;
}
p {
line-height: 1.5em;
margin-top: 0em;
}
dl {
padding-top: 0em;
}
hr {
border: solid 1px;
}
.mediaobject,
.mediaobjectco {
text-align: center;
}
img {
border: none;
}
ul {
padding: 0em 0em 0em 1.5em;
}
ul li {
padding: 0em 0em 0em 0em;
}
ul li p {
text-align: left;
}
table {
width :100%;
}
th {
padding: 0.25em;
text-align: left;
font-weight: normal;
vertical-align: top;
}
td {
padding: 0.25em;
vertical-align: top;
}
p a[id] {
margin: 0px;
padding: 0px;
display: inline;
background-image: none;
}
a {
text-decoration: underline;
color: #444;
}
pre {
overflow: auto;
}
a:hover {
text-decoration: underline;
/*font-weight: bold;*/
}
/* This style defines how the permalink character
appears by itself and when hovered over with
the mouse. */
[alt='Permalink'] { color: #eee; }
[alt='Permalink']:hover { color: black; }
div.informalfigure,
div.informalexample,
div.informaltable,
div.figure,
div.table,
div.example {
margin: 1em 0em;
padding: 1em;
page-break-inside: avoid;
}
div.informalfigure p.title b,
div.informalexample p.title b,
div.informaltable p.title b,
div.figure p.title b,
div.example p.title b,
div.table p.title b{
padding-top: 0em;
margin-top: 0em;
font-size: 100%;
font-weight: normal;
}
.mediaobject .caption,
.mediaobject .caption p {
text-align: center;
font-size: 80%;
padding-top: 0.5em;
padding-bottom: 0.5em;
}
.epigraph {
padding-left: 55%;
margin-bottom: 1em;
}
.epigraph p {
text-align: left;
}
.epigraph .quote {
font-style: italic;
}
.epigraph .attribution {
font-style: normal;
text-align: right;
}
span.application {
font-style: italic;
}
.programlisting {
font-family: monospace;
font-size: 80%;
white-space: pre;
margin: 1.33em 0em;
padding: 1.33em;
}
.tip,
.warning,
.caution,
.note {
margin-top: 1em;
margin-bottom: 1em;
}
/* force full width of table within div */
.tip table,
.warning table,
.caution table,
.note table {
border: none;
width: 100%;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
padding: 0.8em 0.0em 0.0em 0.0em;
margin : 0em 0em 0em 0em;
}
.tip p,
.warning p,
.caution p,
.note p {
margin-top: 0.5em;
margin-bottom: 0.5em;
padding-right: 1em;
text-align: left;
}
.acronym {
text-transform: uppercase;
}
b.keycap,
.keycap {
padding: 0.09em 0.3em;
margin: 0em;
}
.itemizedlist li {
clear: none;
}
.filename {
font-size: medium;
font-family: Courier, monospace;
}
div.navheader, div.heading{
position: absolute;
left: 0em;
top: 0em;
width: 100%;
background-color: #cdf;
width: 100%;
}
div.navfooter, div.footing{
position: fixed;
left: 0em;
bottom: 0em;
background-color: #eee;
width: 100%;
}
div.navheader td,
div.navfooter td {
font-size: 66%;
}
div.navheader table th {
/*font-family: Georgia, Times, serif;*/
/*font-size: x-large;*/
font-size: 80%;
}
div.navheader table {
border-left: 0em;
border-right: 0em;
border-top: 0em;
width: 100%;
}
div.navfooter table {
border-left: 0em;
border-right: 0em;
border-bottom: 0em;
width: 100%;
}
div.navheader table td a,
div.navfooter table td a {
color: #777;
text-decoration: none;
}
/* normal text in the footer */
div.navfooter table td {
color: black;
}
div.navheader table td a:visited,
div.navfooter table td a:visited {
color: #444;
}
/* links in header and footer */
div.navheader table td a:hover,
div.navfooter table td a:hover {
text-decoration: underline;
background-color: transparent;
color: #33a;
}
div.navheader hr,
div.navfooter hr {
display: none;
}
.qandaset tr.question td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.qandaset tr.answer td p {
margin: 0em 0em 1em 0em;
padding: 0em 0em 0em 0em;
}
.answer td {
padding-bottom: 1.5em;
}
.emphasis {
font-weight: bold;
}
/************* /
/ decorations /
/ *************/
.titlepage {
}
.part .title {
}
.subtitle {
border: none;
}
/*
h1 {
border: none;
}
h2 {
border-top: solid 0.2em;
border-bottom: solid 0.06em;
}
h3 {
border-top: 0em;
border-bottom: solid 0.06em;
}
h4 {
border: 0em;
border-bottom: solid 0.06em;
}
h5 {
border: 0em;
}
*/
.programlisting {
border: solid 1px;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example {
border: 1px solid;
}
.tip,
.warning,
.caution,
.note {
border: 1px solid;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom: 1px solid;
}
.question td {
border-top: 1px solid black;
}
.answer {
}
b.keycap,
.keycap {
border: 1px solid;
}
div.navheader, div.heading{
border-bottom: 1px solid;
}
div.navfooter, div.footing{
border-top: 1px solid;
}
/********* /
/ colors /
/ *********/
body {
color: #333;
background: white;
}
a {
background: transparent;
}
a:hover {
background-color: #dedede;
}
h1,
h2,
h3,
h4,
h5,
h6,
h7,
h8 {
background-color: transparent;
}
hr {
border-color: #aaa;
}
.tip, .warning, .caution, .note {
border-color: #fff;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #fff;
}
.warning {
background-color: #f0f0f2;
}
.caution {
background-color: #f0f0f2;
}
.tip {
background-color: #f0f0f2;
}
.note {
background-color: #f0f0f2;
}
.glossary dl dt,
.variablelist dl dt,
.variablelist dl dt span.term {
color: #044;
}
div.figure,
div.table,
div.example,
div.informalfigure,
div.informaltable,
div.informalexample {
border-color: #aaa;
}
pre.programlisting {
color: black;
background-color: #fff;
border-color: #aaa;
border-width: 2px;
}
.guimenu,
.guilabel,
.guimenuitem {
background-color: #eee;
}
b.keycap,
.keycap {
background-color: #eee;
border-color: #999;
}
div.navheader {
border-color: black;
}
div.navfooter {
border-color: black;
}
.writernotes {
color: red;
}
/*********** /
/ graphics /
/ ***********/
/*
body {
background-image: url("images/body_bg.jpg");
background-attachment: fixed;
}
.navheader,
.note,
.tip {
background-image: url("images/note_bg.jpg");
background-attachment: fixed;
}
.warning,
.caution {
background-image: url("images/warning_bg.jpg");
background-attachment: fixed;
}
.figure,
.informalfigure,
.example,
.informalexample,
.table,
.informaltable {
background-image: url("images/figure_bg.jpg");
background-attachment: fixed;
}
*/
h1,
h2,
h3,
h4,
h5,
h6,
h7{
}
/*
Example of how to stick an image as part of the title.
div.article .titlepage .title
{
background-image: url("figures/white-on-black.png");
background-position: center;
background-repeat: repeat-x;
}
*/
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title,
div.article .titlepage .title
{
}
div.section div.section .titlepage .title,
div.sect2 .titlepage .title {
background: none;
}
h1.title {
background-color: transparent;
background-repeat: no-repeat;
height: 256px;
text-indent: -9000px;
overflow:hidden;
}
h2.subtitle {
background-color: transparent;
text-indent: -9000px;
overflow:hidden;
width: 0px;
display: none;
}
/*************************************** /
/ pippin.gimp.org specific alterations /
/ ***************************************/
/*
div.heading, div.navheader {
color: #777;
font-size: 80%;
padding: 0;
margin: 0;
text-align: left;
position: absolute;
top: 0px;
left: 0px;
width: 100%;
height: 50px;
background: url('/gfx/heading_bg.png') transparent;
background-repeat: repeat-x;
background-attachment: fixed;
border: none;
}
div.heading a {
color: #444;
}
div.footing, div.navfooter {
border: none;
color: #ddd;
font-size: 80%;
text-align:right;
width: 100%;
padding-top: 10px;
position: absolute;
bottom: 0px;
left: 0px;
background: url('/gfx/footing_bg.png') transparent;
}
*/
/****************** /
/ nasty ie tweaks /
/ ******************/
/*
div.heading, div.navheader {
width:expression(document.body.clientWidth + "px");
}
div.footing, div.navfooter {
width:expression(document.body.clientWidth + "px");
margin-left:expression("-5em");
}
body {
padding:expression("4em 5em 0em 5em");
}
*/
/**************************************** /
/ mozilla vendor specific css extensions /
/ ****************************************/
/*
div.navfooter, div.footing{
-moz-opacity: 0.8em;
}
div.figure,
div.table,
div.informalfigure,
div.informaltable,
div.informalexample,
div.example,
.tip,
.warning,
.caution,
.note {
-moz-border-radius: 0.5em;
}
b.keycap,
.keycap {
-moz-border-radius: 0.3em;
}
*/
table tr td table tr td {
display: none;
}
hr {
display: none;
}
table {
border: 0em;
}
.photo {
float: right;
margin-left: 1.5em;
margin-bottom: 1.5em;
margin-top: 0em;
max-width: 17em;
border: 1px solid gray;
padding: 3px;
background: white;
}
.seperator {
padding-top: 2em;
clear: both;
}
#validators {
margin-top: 5em;
text-align: right;
color: #777;
}
@media print {
body {
font-size: 8pt;
}
.noprint {
display: none;
}
}
.tip,
.note {
background: #f0f0f2;
color: #333;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #333;
}
.tip a,
.note a {
color: #333;
text-decoration: underline;
}
.footnote {
font-size: small;
color: #333;
}
/* Changes the announcement text */
.tip h3,
.warning h3,
.caution h3,
.note h3 {
font-size:large;
color: #00557D;
}

View File

@ -1,187 +0,0 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
<book id='kernel-dev' lang='en'
xmlns:xi="http://www.w3.org/2003/XInclude"
xmlns="http://docbook.org/ns/docbook"
>
<bookinfo>
<mediaobject>
<imageobject>
<imagedata fileref='figures/kernel-dev-title.png'
format='SVG'
align='left' scalefit='1' width='100%'/>
</imageobject>
</mediaobject>
<title>
Yocto Project Linux Kernel Development Manual
</title>
<authorgroup>
<author>
<affiliation>
<orgname>&ORGNAME;</orgname>
</affiliation>
<email>&ORGEMAIL;</email>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>1.4</revnumber>
<date>April 2013</date>
<revremark>The initial document released with the Yocto Project 1.4 Release.</revremark>
</revision>
<revision>
<revnumber>1.5</revnumber>
<date>October 2013</date>
<revremark>Released with the Yocto Project 1.5 Release.</revremark>
</revision>
<revision>
<revnumber>1.6</revnumber>
<date>April 2014</date>
<revremark>Released with the Yocto Project 1.6 Release.</revremark>
</revision>
<revision>
<revnumber>1.7</revnumber>
<date>October 2014</date>
<revremark>Released with the Yocto Project 1.7 Release.</revremark>
</revision>
<revision>
<revnumber>1.8</revnumber>
<date>April 2015</date>
<revremark>Released with the Yocto Project 1.8 Release.</revremark>
</revision>
<revision>
<revnumber>2.0</revnumber>
<date>October 2015</date>
<revremark>Released with the Yocto Project 2.0 Release.</revremark>
</revision>
<revision>
<revnumber>2.1</revnumber>
<date>April 2016</date>
<revremark>Released with the Yocto Project 2.1 Release.</revremark>
</revision>
<revision>
<revnumber>2.2</revnumber>
<date>October 2016</date>
<revremark>Released with the Yocto Project 2.2 Release.</revremark>
</revision>
<revision>
<revnumber>2.3</revnumber>
<date>May 2017</date>
<revremark>Released with the Yocto Project 2.3 Release.</revremark>
</revision>
<revision>
<revnumber>2.4</revnumber>
<date>October 2017</date>
<revremark>Released with the Yocto Project 2.4 Release.</revremark>
</revision>
<revision>
<revnumber>2.5</revnumber>
<date>May 2018</date>
<revremark>Released with the Yocto Project 2.5 Release.</revremark>
</revision>
<revision>
<revnumber>2.6</revnumber>
<date>November 2018</date>
<revremark>Released with the Yocto Project 2.6 Release.</revremark>
</revision>
<revision>
<revnumber>2.7</revnumber>
<date>May 2019</date>
<revremark>Released with the Yocto Project 2.7 Release.</revremark>
</revision>
<revision>
<revnumber>3.0</revnumber>
<date>October 2019</date>
<revremark>Released with the Yocto Project 3.0 Release.</revremark>
</revision>
<revision>
<revnumber>3.1</revnumber>
<date>&REL_MONTH_YEAR;</date>
<revremark>Released with the Yocto Project 3.1 Release.</revremark>
</revision>
</revhistory>
<copyright>
<year>&COPYRIGHT_YEAR;</year>
<holder>Linux Foundation</holder>
</copyright>
<legalnotice>
<para>
Permission is granted to copy, distribute and/or modify this document under
the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
</para>
<note><title>Manual Notes</title>
<itemizedlist>
<listitem><para>
This version of the
<emphasis>Yocto Project Linux Kernel Development Manual</emphasis>
is for the &YOCTO_DOC_VERSION; release of the
Yocto Project.
To be sure you have the latest version of the manual
for this release, go to the
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
and select the manual from that site.
Manuals from the site are more up-to-date than manuals
derived from the Yocto Project released TAR files.
</para></listitem>
<listitem><para>
If you located this manual through a web search, the
version of the manual might not be the one you want
(e.g. the search might have returned a manual much
older than the Yocto Project version with which you
are working).
You can see all Yocto Project major releases by
visiting the
<ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
page.
If you need a version of this manual for a different
Yocto Project release, visit the
<ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
and select the manual set by using the
"ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
pull-down menus.
</para></listitem>
<listitem>
<para>
To report any inaccuracies or problems with this
(or any other Yocto Project) manual, send an email to
the Yocto Project documentation mailing list at
<filename>docs@lists.yoctoproject.org</filename> or
log into the freenode <filename>#yocto</filename> channel.
</para>
</listitem>
</itemizedlist>
</note>
</legalnotice>
</bookinfo>
<xi:include href="kernel-dev-intro.xml"/>
<xi:include href="kernel-dev-common.xml"/>
<xi:include href="kernel-dev-advanced.xml"/>
<xi:include href="kernel-dev-concepts-appx.xml"/>
<xi:include href="kernel-dev-maint-appx.xml"/>
<xi:include href="kernel-dev-faq.xml"/>
<!-- <index id='index'>
<title>Index</title>
</index>
-->
</book>
<!--
vim: expandtab tw=80 ts=4
-->

Binary file not shown.

Before

Width:  |  Height:  |  Size: 181 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 67 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 135 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 5.0 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 49 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 159 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 69 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 81 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 623 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 26 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 120 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 136 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 40 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 48 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 87 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 96 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 200 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 61 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 18 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 72 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 96 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 94 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 58 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 167 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 134 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 137 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 168 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 171 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 99 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 93 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 175 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 135 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Some files were not shown because too many files have changed in this diff Show More