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>
|
@ -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;
|
|
@ -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 <stdio.h>
|
||||
|
||||
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
|
||||
-->
|
|
@ -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
|
||||
-->
|
|
@ -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>
|
|
@ -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>
|
|
@ -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
|
||||
-->
|
|
@ -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>©RIGHT_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 & 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
|
||||
-->
|
|
@ -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> -o </replaceable>sysroot_dir> \
|
||||
--force-overwrite install libglade-dev
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
</chapter>
|
||||
<!--
|
||||
vim: expandtab tw=80 ts=4
|
||||
-->
|
|
@ -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;
|
||||
}
|
|
@ -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>
|
|
@ -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;
|
||||
}
|
|
@ -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>©RIGHT_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 & 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 <target>'
|
||||
|
||||
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
|
||||
-->
|
|
@ -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>
|
|
@ -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>©RIGHT_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 & 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
|
||||
-->
|
|
@ -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;
|
||||
}
|
|
@ -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>
|
|
@ -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
|
||||
-->
|
|
@ -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=<port> - specify tcp serial port number
|
||||
biosdir=<dir> - specify custom bios dir
|
||||
biosfilename=<filename> - specify bios filename
|
||||
qemuparams=<xyz> - specify custom parameters to QEMU
|
||||
bootparams=<xyz> - 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/<qemuboot.conf>
|
||||
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/<image>-<machine>.wic
|
||||
runqemu path/to/<image>-<machine>.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
|
||||
-->
|
|
@ -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>©RIGHT_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 & 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
|
||||
-->
|
|
@ -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;
|
||||
}
|
|
@ -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 ‐ 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
|
||||
-->
|
|
@ -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>
|
|
@ -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
|
||||
-->
|
|
@ -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
|
||||
-->
|
|
@ -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
|
||||
-->
|
|
@ -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;
|
||||
}
|
|
@ -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>©RIGHT_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 & 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
|
||||
-->
|
Before Width: | Height: | Size: 181 KiB |
Before Width: | Height: | Size: 108 KiB |
Before Width: | Height: | Size: 67 KiB |
Before Width: | Height: | Size: 135 KiB |
Before Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 5.0 KiB |
Before Width: | Height: | Size: 51 KiB |
Before Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 49 KiB |
Before Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 159 KiB |
Before Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 69 KiB |
Before Width: | Height: | Size: 81 KiB |
Before Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 623 B |
Before Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 120 KiB |
Before Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 136 KiB |
Before Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 52 KiB |
Before Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 35 KiB |
Before Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 87 KiB |
Before Width: | Height: | Size: 56 KiB |
Before Width: | Height: | Size: 96 KiB |
Before Width: | Height: | Size: 200 KiB |
Before Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 61 KiB |
Before Width: | Height: | Size: 10 KiB |
Before Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 72 KiB |
Before Width: | Height: | Size: 96 KiB |
Before Width: | Height: | Size: 103 KiB |
Before Width: | Height: | Size: 36 KiB |
Before Width: | Height: | Size: 94 KiB |
Before Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 56 KiB |
Before Width: | Height: | Size: 58 KiB |
Before Width: | Height: | Size: 167 KiB |
Before Width: | Height: | Size: 134 KiB |
Before Width: | Height: | Size: 137 KiB |
Before Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 168 KiB |
Before Width: | Height: | Size: 171 KiB |
Before Width: | Height: | Size: 23 KiB |
Before Width: | Height: | Size: 99 KiB |
Before Width: | Height: | Size: 93 KiB |
Before Width: | Height: | Size: 175 KiB |
Before Width: | Height: | Size: 135 KiB |
Before Width: | Height: | Size: 100 KiB |
Before Width: | Height: | Size: 108 KiB |
Before Width: | Height: | Size: 100 KiB |
Before Width: | Height: | Size: 23 KiB |
Before Width: | Height: | Size: 11 KiB |