Created a new folder to hold the BSP Guide

I created a new sub folder to hold the BSP Guide by itself so there are
three folders now for each of the Yocto manuals: BSP Guide, quick start
and poky ref manual.  The new folder for the BSP guide is 'bsp-guide'.
It contains the bsp.xml file, its own Makefile, a bsp-guide.xml file,
and its own 'Figures' directory.  The 'bsp-guide.xml' file that was
in the poky reference folder was deleted.

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
This commit is contained in:
Scott Rifenbark 2010-11-04 13:01:19 -07:00 committed by Richard Purdie
parent 4b7f1eee28
commit 890a794e38
6 changed files with 1453 additions and 8 deletions

View File

@ -0,0 +1,35 @@
all: html pdf tarball
pdf:
../tools/poky-docbook-to-pdf bsp-guide.xml ../template
XSLTOPTS = --stringparam html.stylesheet style.css \
--stringparam chapter.autolabel 1 \
--stringparam section.autolabel 1 \
--stringparam section.label.includes.component.label 1 \
--xinclude
##
# These URI should be rewritten by your distribution's xml catalog to
# match your localy installed XSL stylesheets.
XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current
XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
html:
# See http://www.sagehill.net/docbookxsl/HtmlOutput.html
xsltproc $(XSLTOPTS) -o bsp-guide.html $(XSL_XHTML_URI) bsp-guide.xml
tarball: html
tar -cvzf bsp-guide.tgz style.css bsp-guide.html figures/poky-ref-manual.png
validate:
xmllint --postvalid --xinclude --noout bsp-guide.xml
OUTPUTS = bsp-guide.pdf bsp-guide.html
SOURCES = *.png *.xml *.css *.svg
publish:
scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/
clean:
rm -f $(OUTPUTS)

View File

@ -29,9 +29,9 @@
<revhistory>
<revision>
<revnumber>0.4</revnumber>
<date>26 May 2010</date>
<revremark>Alpha Draft</revremark>
<revnumber>0.9</revnumber>
<date>27 October 2010</date>
<revremark>Beta Draft</revremark>
</revision>
</revhistory>
@ -51,9 +51,10 @@
<xi:include href="bsp.xml"/>
<index id='index'>
<!-- <index id='index'>
<title>Index</title>
</index>
-->
</book>
<!--

View File

@ -0,0 +1,459 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<chapter id='bsp'>
<title>Board Support Packages (BSP) - Developers Guide</title>
<para>
A Board Support Package (BSP) is a collection of information that
defines how to support a particular hardware device, set of devices, or
hardware platform.
The BSP includes information about the hardware features
present on the device and kernel configuration information along with any
additional hardware drivers required.
The BSP also lists any additional software
components required in addition to a generic Linux software stack for both
essential and optional platform features.
</para>
<para>
The intent of this document is to define a structure for these components
so that BSPs follow a commonly understood layout.
Providing a common form allows end-users to understand and become familiar
with the layout.
A common form also encourages standardization
of software support of hardware.
</para>
<para>
The proposed format does have elements that are specific to the Poky and
OpenEmbedded build systems.
It is intended that this information can be
used by other systems besides Poky and OpenEmbedded and thatspecified it will be simple
to extract information and convert it to other formats if required.
Poky, through its standard slyers mechanism, can directly accept The format
described as a layer.
The BSP captures all
the hardware specific details in one place in a standard format, which is
useful for any person wishing to use the hardware platform regardless of
the build system being used.
</para>
<para>
The BSP specification does not include a build system or other tools -
it is concerned with the hardware-specific components only.
At the end
distribution point you can shipt the BSP combined with a build system
and other tools.
However, it is important to maintain the distinction that these
are separate components that happen to be combined in certain end products.
</para>
<section id="bsp-filelayout">
<title>Example Filesystem Layout</title>
<para>
The BSP consists of a file structure inside a base directory, meta-bsp in this example,
where "bsp" is a placeholder for the machine or platform name.
Examples of some files that it could contain are:
</para>
<para>
<literallayout class='monospaced'>
meta-bsp/
meta-bsp/binary/zImage
meta-bsp/binary/poky-image-minimal.directdisk
meta-bsp/conf/layer.conf
meta-bsp/conf/machine/*.conf
meta-bsp/conf/machine/include/tune-*.inc
meta-bsp/packages/bootloader/bootloader_0.1.bb
meta-bsp/packages/linux/linux-bsp-2.6.50/*.patch
meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
meta-bsp/packages/linux/linux-bsp_2.6.50.bb
meta-bsp/packages/modem/modem-driver_0.1.bb
meta-bsp/packages/modem/modem-daemon_0.1.bb
meta-bsp/packages/image-creator/image-creator-native_0.1.bb
meta-bsp/prebuilds/
</literallayout>
</para>
<para>
The following sections detail what these files and directories could contain.
</para>
</section>
<section id="bsp-filelayout-binary">
<title>Prebuilt User Binaries (meta-bsp/binary/*)</title>
<para>
This optional area contains useful prebuilt kernels and userspace filesystem
images appropriate to the target system.
Users could use these to get a system
running and quickly get started on development tasks.
The exact types of binaries
present will be highly hardware-dependent but a README file should be present
explaining how to use them with the target hardware.
If prebuilt binaries are
present, source code to meet licensing requirements must also be provided in
some form.
</para>
</section>
<section id='bsp-filelayout-layer'>
<title>Layer Configuration (meta-bsp/conf/layer.conf)</title>
<para>
This file identifies the structure as a Poky layer by identifying the
contents of the layer and containing information about how Poky should use
it.
Generally, a standard boilerplate file consisting of the following works.
</para>
<para>
<literallayout class='monospaced'>
# We have a conf directory, add to BBPATH
BBPATH := "${BBPATH}${LAYERDIR}"
# We have a recipes directory containing .bb and .bbappend files, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend"
BBFILE_COLLECTIONS += "bsp"
BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
BBFILE_PRIORITY_bsp = "5"
</literallayout>
</para>
<para>
This file simply makes bitbake aware of the recipes and conf directories and is required
for recognition of the BSP by Poky.
</para>
</section>
<section id="bsp-filelayout-machine">
<title>Hardware Configuration Options (meta-bsp/conf/machine/*.conf)</title>
<para>
The machine files bind together all the information contained elsewhere
in the BSP into a format that Poky/OpenEmbedded can understand.
If the BSP supports multiple machines, multiple machine configuration files
can be present.
These filenames correspond to the values to which users have set the MACHINE variable.
</para>
<para>
These files define things such as what kernel package to use
(PREFERRED_PROVIDER of virtual/kernel), what hardware drivers to
include in different types of images, any special software components
that are needed, any bootloader information, and also any special image
format requirements.
</para>
<para>
At least one machine file is required for a Poky BSP layer.
However, you can supply more than one file.
</para>
</section>
<section id="bsp-filelayout-tune">
<title>Hardware Optimization Options (meta-bsp/conf/machine/include/tune-*.inc)</title>
<para>
These are shared hardware "tuning" definitions and are commonly used to
pass specific optimization flags to the compiler.
An example is tune-atom.inc:
</para>
<para>
<literallayout class='monospaced'>
BASE_PACKAGE_ARCH = "core2"
TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse"
</literallayout>
</para>
<para>
This example defines a new package architecture called "core2" and uses the
specified optimization flags, which are carefully chosen to give best
performance on atom processors.
</para>
<para>
The tune file would be included by the machine definition and can be
contained in the BSP or referenced from one of the standard core set of
files included with Poky itself.
</para>
<para>
Both the base package architecuture file and the tune file are optional for a Poky BSP layer.
</para>
</section>
<section id='bsp-filelayout-kernel'>
<title>Linux Kernel Configuration (meta-bsp/packages/linux/*)</title>
<para>
These files make up the definition of a kernel to use with this
hardware.
In this case it is a complete self-contained kernel with its own
configuration and patches but kernels can be shared between many
machines as well.
Following is an example:
<literallayout class='monospaced'>
meta-bsp/packages/linux/linux-bsp_2.6.50.bb
</literallayout>
This example file is the core kernel recipe that details from where to get the kernel
source.
All standard source code locations are supported so this could
be a release tarball, some git repository, or source included in
the directory within the BSP itself.
</para>
<para>
The file then contains information about what patches to apply and how to configure and build them.
It can reuse the main Poky kernel build class, so the definitions here can remain very simple.
</para>
<para>
<literallayout class='monospaced'>
linux-bsp-2.6.50/*.patch
</literallayout>
</para>
<para>
The above example file contains patches you can apply against the base kernel, wherever
they may have been obtained from.
</para>
<para>
<literallayout class='monospaced'>
meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
</literallayout>
</para>
<para>
Finally, this last example file contains configuration information to use to configure the kernel.
</para>
<para>
Examples of kernel recipes are available in Poky itself.
These files are optional since a kernel from Poky itself could be selected, although it
would be unusual not to have a kernel configuration.
</para>
</section>
<section id='bsp-filelayout-packages'>
<title>Other Software (meta-bsp/packages/*)</title>
<para>
This section describes other pieces of software that the hardware might need for best
operation.
These are examples of the kinds of things that you could encounter.
The examples used in this section are standard <filename>.bb</filename> file recipes in the
usual Poky format.
You can include the source directly by referring to it in the source control system or
the released tarballs of external software projects.
You only need to provide these types of files if the platform requires them.
</para>
<para>
The following file is a bootloader recipe that can be used to generate a new
bootloader binary.
Sometimes these files are included in the final image format and are needed to reflash hardware.
</para>
<para>
<literallayout class='monospaced'>
meta-bsp/packages/bootloader/bootloader_0.1.bb
</literallayout>
</para>
<para>
These next two files are examples of a hardware driver and a hardware daemon that might need
to be included in images to make the hardware useful.
Although the example uses "modem" there may be other components needed, such as firmware.
</para>
<para>
<literallayout class='monospaced'>
meta-bsp/packages/modem/modem-driver_0.1.bb
meta-bsp/packages/modem/modem-daemon_0.1.bb
</literallayout>
</para>
<para>
Sometimes the device needs an image in a very specific format so that the update
mechanism can accept and reflash it.
Recipes to build the tools needed to do this can be included with the BSP.
Following is an example.
</para>
<para>
<literallayout class='monospaced'>
meta-bsp/packages/image-creator/image-creator-native_0.1.bb
</literallayout>
</para>
</section>
<section id='bs-filelayout-bbappend'>
<title>Append BSP-Specific Information to Existing Recipes</title>
<para>
Suppose you have a recipe such as 'pointercal' that requires machine-specific information.
At the same time, you have your new BSP code nicely partitioned into a layer, which is where
you would also like to specify any machine-specific information associated with your new machine.
Before the <filename>.bbappend</filename> extension was introduced, you would have to copy the whole
pointercal recipe and files into your layer, and then add the single file for your machine.
</para>
<para>
With the <filename>.bbappend</filename> extension, however, your work becomes much easier.
It allows you to easily merge BSP-specific information with the original recipe.
Whenever bitbake finds any <filename>.bbappend</filename> files, they will be
included after bitbake loads the associated <filename>.bb</filename> but before any finalize
or anonymous methods run.
This allows the BSP layer to do whatever it might want to do to customize the original recipe.
</para>
<para>
If your recipe needs to reference extra files it can use the FILESEXTRAPATH variable
to specify their location.
The example below shows extra files contained in a folder called ${PN} (the package name).
</para>
<literallayout class='monospaced'>
FILESEXTRAPATHS := "${THISDIR}/${PN}"
</literallayout>
<para>
This technique allows the BSP to add machine-specific configuration files to the layer directory,
which will be picked up by bitbake.
For an example see <filename>meta-emenlow/packages/formfactor</filename>.
</para>
</section>
<section id="bsp-filelayout-prebuilds">
<title>Prebuild Data (meta-bsp/prebuilds/*)</title>
<para>
This location can contain precompiled representations of the source code
contained elsewhere in the BSP layer.
Assuming a compatible configuration is used, Poky can process and use these optional precompiled
representations to provide much faster build times.
</para>
</section>
<section id='bsp-click-through-licensing'>
<title>BSP 'Click-Through' Licensing Procedure</title>
<note><para> This section is here as a description of how
click-through licensing is expected to work, and is
not yet not impemented.
</para></note>
<para>
In some cases, a BSP may contain separately licensed IP
(Intellectual Property) for a component, which imposes
upon the user a requirement to accept the terms of a
'click-through' license. Once the license is accepted
(in whatever form that may be, see details below) the
Poky build system can then build and include the
corresponding component in the final BSP image. Some
affected components may be essential to the normal
functioning of the system and have no 'free' replacement
i.e. the resulting system would be non-functional
without them. Other components may be simply
'good-to-have' or purely elective, or if essential
nonetheless have a 'free' (possibly less-capable)
version which may substituted for in the BSP recipe.
</para>
<para>
For the latter cases, where it is possible to do so from
a functionality perspective, the Poky website will make
available a 'de-featured' BSP completely free of
encumbered IP, which can be used directly and without
any further licensing requirements. If present, this
fully 'de-featured' BSP will be named meta-bsp (i.e. the
normal default naming convention). This is the simplest
and therefore preferred option if available, assuming
the resulting functionality meets requirements.
</para>
<para>
If however, a non-encumbered version is unavailable or
the 'free' version would provide unsuitable
functionality or quality, an encumbered version can be
used. Encumbered versions of a BSP are given names of
the form meta-bsp-nonfree. There are several ways
within the Poky build system to satisfy the licensing
requirements for an encumbered BSP, in roughly the
following order of preference:
</para>
<itemizedlist>
<listitem>
<para>
Get a license key (or keys) for the encumbered BSP
by visiting
<ulink url='https://pokylinux.org/bsp-keys.html'>https://pokylinux.org/bsp-keys.html</ulink>
and give the web form there the name of the BSP and your e-mail address.
</para>
<literallayout class='monospaced'>
[screenshot of dialog box]
</literallayout>
<para>
After agreeing to any applicable license terms, the
BSP key(s) will be immediately sent to the address
given and can be used by specifying BSPKEY_&lt;keydomain&gt;
environment variables when building the image:
</para>
<literallayout class='monospaced'>
$ BSPKEY_&lt;keydomain&gt;=&lt;key&gt; bitbake poky-image-sato
</literallayout>
<para>
This will allow the encumbered image to be built
with no change at all to the normal build process.
</para>
<para>
Equivalently and probably more conveniently, a line
for each key can instead be put into the user's
local.conf file.
</para>
<para>
The &lt;keydomain&gt; component of the
BSPKEY_&lt;keydomain&gt; is required because there
may be multiple licenses in effect for a give BSP; a
given &lt;keydomain&gt; in such cases corresponds to
a particular license. In order for an encumbered
BSP encompassing multiple key domains to be built
successfully, a &lt;keydomain&gt; entry for each
applicable license must be present in local.conf or
supplied on the command-line.
</para>
</listitem>
<listitem>
<para>
Do nothing - build as you normally would, and follow
any license prompts that originate from the
encumbered BSP (the build will cleanly stop at this
point). These usually take the form of instructions
needed to manually fetch the encumbered package(s)
and md5 sums into e.g. the poky/build/downloads
directory. Once the manual package fetch has been
completed, restarting the build will continue where
it left off, this time without the prompt since the
license requirements will have been satisfied.
</para>
</listitem>
<listitem>
<para>
Get a full-featured BSP recipe rather than a key, by
visiting
<ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
Accepting the license agreement(s) presented will
subsequently allow you to download a tarball
containing a full-featured BSP legally cleared for
your use by the just-given license agreement(s).
This method will also allow the encumbered image to
be built with no change at all to the normal build
process.
</para>
</listitem>
</itemizedlist>
<para>
Note that method 3 is also the only option available
when downloading pre-compiled images generated from
non-free BSPs. Those images are likewise available at
<ulink url='https://pokylinux.org/bsps.html'>https://pokylinux.org/bsps.html</ulink>.
</para>
</section>
</chapter>

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

View File

@ -0,0 +1,952 @@
/*
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:#999999;
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: normal;
}
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: normal;
}
h4 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 120%;
font-weight: normal;
}
h5 {
margin: 1em 0em 0.5em 0em;
padding: 1em 0em 0em 0em;
font-size: 110.000%;
border-bottom: 1px solid black;
}
h6 {
margin: 1em 0em 0em 0em;
padding: 1em 0em 0em 0em;
font-size: 80%;
font-weight: normal;
}
.authorgroup {
background-color: transparent;
background-repeat: no-repeat;
padding-top: 256px;
background-image: url("figures/poky-ref-manual.png");
background-position: left top;
margin-top: -256px;
padding-right: 50px;
margin-left: 50px;
text-align: right;
width: 600px;
}
h3.author {
margin: 0em 0me 0em 0em;
padding: 0em 0em 0em 0em;
font-weight: normal;
font-size: 100%;
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;
}
.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;*/
}
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: #aaa;
}
.tip table th,
.warning table th,
.caution table th,
.note table th {
border-bottom-color: #aaa;
}
.warning {
background-color: #fea;
}
.caution {
background-color: #fea;
}
.tip {
background-color: #eff;
}
.note {
background-color: #dfc;
}
.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{
}
div.preface .titlepage .title,
div.colophon .title,
div.chapter .titlepage .title {
background-image: url("images/title-bg.png");
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-image: url("poky-ref-manual.png");
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: #91ae35;
color: #fff;
padding: 20px;
margin: 20px;
}
.tip h3,
.note h3 {
padding: 0em;
margin: 0em;
font-size: 2em;
font-weight: bold;
color: #fff;
}
.tip a,
.note a {
color: #fff;
text-decoration: underline;
}

View File

@ -2,7 +2,6 @@ all: html pdf tarball
pdf:
../tools/poky-docbook-to-pdf poky-ref-manual.xml ../template
../tools/poky-docbook-to-pdf bsp-guide.xml ../template
XSLTOPTS = --stringparam html.stylesheet style.css \
--stringparam chapter.autolabel 1 \
@ -20,15 +19,14 @@ XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
html:
# See http://www.sagehill.net/docbookxsl/HtmlOutput.html
xsltproc $(XSLTOPTS) -o poky-ref-manual.html $(XSL_XHTML_URI) poky-ref-manual.xml
xsltproc $(XSLTOPTS) -o bsp-guide.html $(XSL_XHTML_URI) bsp-guide.xml
tarball: html
tar -cvzf poky-ref-manual.tgz poky-ref-manual.html style.css figures/yocto-project-transp.png figures/poky-ref-manual.png
tar -cvzf poky-ref-manual.tgz poky-ref-manual.html style.css figures/yocto-project-transp.png figures/poky-ref-manual.png screenshots/ss-sato.png
validate:
xmllint --postvalid --xinclude --noout poky-ref-manual.xml
OUTPUTS = poky-ref-manual.tgz poky-ref-manual.html poky-ref-manual.pdf bsp-guide.pdf bsp-guide.html
OUTPUTS = poky-ref-manual.tgz poky-ref-manual.html poky-ref-manual.pdf
SOURCES = *.png *.xml *.css *.svg
publish: