2010-11-04 20:01:19 +00:00
|
|
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
2012-03-08 21:17:14 +00:00
|
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
|
|
|
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
2010-11-04 20:01:19 +00:00
|
|
|
|
|
|
|
<chapter id='bsp'>
|
|
|
|
|
2011-08-18 23:00:16 +00:00
|
|
|
<title>Board Support Packages (BSP) - Developer's Guide</title>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
|
|
|
<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>
|
2012-03-08 21:17:14 +00:00
|
|
|
This chapter (or document if you are reading the BSP Developer's Guide) defines
|
2010-11-11 18:59:49 +00:00
|
|
|
a structure for these components
|
2010-11-04 20:01:19 +00:00
|
|
|
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>
|
|
|
|
|
2011-08-18 23:00:16 +00:00
|
|
|
<note>
|
2011-07-14 22:33:13 +00:00
|
|
|
The information here does not provide an example of how to create a BSP.
|
2011-08-29 18:46:27 +00:00
|
|
|
For examples on how to create a BSP, see the
|
2012-03-08 21:17:14 +00:00
|
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development Example</ulink>"
|
2012-02-06 21:29:08 +00:00
|
|
|
section in The Yocto Project Development Manual.
|
2011-08-29 18:46:27 +00:00
|
|
|
You can also see the
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
|
2011-08-29 18:46:27 +00:00
|
|
|
wiki page</ulink>.
|
2011-08-18 23:00:16 +00:00
|
|
|
</note>
|
2011-07-14 22:33:13 +00:00
|
|
|
|
2010-11-04 20:01:19 +00:00
|
|
|
<para>
|
2011-07-14 21:49:34 +00:00
|
|
|
The proposed format does have elements that are specific to the Yocto Project and
|
2010-11-04 20:01:19 +00:00
|
|
|
OpenEmbedded build systems.
|
|
|
|
It is intended that this information can be
|
2011-07-14 21:49:34 +00:00
|
|
|
used by other systems besides Yocto Project and OpenEmbedded and that it will be simple
|
2010-11-04 20:01:19 +00:00
|
|
|
to extract information and convert it to other formats if required.
|
2011-07-14 21:49:34 +00:00
|
|
|
Yocto Project, through its standard layers mechanism, can directly accept the format
|
2010-11-04 20:01:19 +00:00
|
|
|
described as a layer.
|
|
|
|
The BSP captures all
|
2010-11-11 18:23:10 +00:00
|
|
|
the hardware-specific details in one place in a standard format, which is
|
2010-11-04 20:01:19 +00:00
|
|
|
useful for any person wishing to use the hardware platform regardless of
|
2010-11-11 18:23:10 +00:00
|
|
|
the build system they are using.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The BSP specification does not include a build system or other tools -
|
|
|
|
it is concerned with the hardware-specific components only.
|
2012-02-22 20:43:04 +00:00
|
|
|
At the end-distribution point, you can ship the BSP combined with a build system
|
2010-11-04 20:01:19 +00:00
|
|
|
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>
|
|
|
|
|
2012-02-17 21:03:46 +00:00
|
|
|
<section id='bsp-layers'>
|
|
|
|
<title>BSP Layers</title>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
|
|
|
<para>
|
2012-02-17 21:03:46 +00:00
|
|
|
The BSP consists of a file structure inside a base directory.
|
|
|
|
Collectively, you can think of the base directory and the file structure
|
|
|
|
as a BSP Layer.
|
|
|
|
BSP Layers use the following naming convention:
|
2010-12-14 00:21:12 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>
|
|
|
|
</literallayout>
|
2012-02-17 21:03:46 +00:00
|
|
|
"bsp_name" is a placeholder for the machine or platform name.
|
2011-05-17 19:03:04 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2012-02-17 21:03:46 +00:00
|
|
|
The layer's base directory (<filename>meta-<bsp_name></filename>) is the root
|
|
|
|
of the BSP Layer.
|
2012-03-26 16:08:39 +00:00
|
|
|
This root is what you add to the
|
|
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
|
2012-02-22 20:43:04 +00:00
|
|
|
variable in the <filename>conf/bblayers.conf</filename> file found in the
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project Build Directory</ulink>.
|
2011-08-18 23:00:16 +00:00
|
|
|
Adding the root allows the Yocto Project build system to recognize the BSP
|
|
|
|
definition and from it build an image.
|
2011-05-17 19:03:04 +00:00
|
|
|
Here is an example:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
BBLAYERS = " \
|
|
|
|
/usr/local/src/yocto/meta \
|
|
|
|
/usr/local/src/yocto/meta-yocto \
|
|
|
|
/usr/local/src/yocto/meta-<bsp_name> \
|
|
|
|
"
|
|
|
|
</literallayout>
|
2012-02-17 21:03:46 +00:00
|
|
|
</para>
|
|
|
|
|
2012-03-26 16:08:39 +00:00
|
|
|
<para>
|
|
|
|
Some BSPs require additional layers on
|
|
|
|
top of the BSP's root layer in order to be functional.
|
|
|
|
For these cases, you also need to add those layers to the
|
|
|
|
<filename>BBLAYERS</filename> variable in order to build the BSP.
|
|
|
|
You must also specify in the "Dependiencies" section of the BSP's
|
|
|
|
<filename>README</filename> file any requirements for additional
|
|
|
|
layers and, preferably, any
|
|
|
|
build instructions that might be contained elsewhere
|
|
|
|
in the <filename>README</filename> file.
|
|
|
|
</para>
|
|
|
|
|
2012-02-17 21:03:46 +00:00
|
|
|
<para>
|
2011-05-17 19:03:04 +00:00
|
|
|
For more detailed information on layers, see the
|
2012-03-08 21:17:14 +00:00
|
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
|
2012-02-17 21:03:46 +00:00
|
|
|
section of the Yocto Project Development Manual.
|
2011-08-18 23:00:16 +00:00
|
|
|
You can also see the detailed examples in the appendices of
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;'>The Yocto Project Development Manual</ulink>.
|
2011-05-17 19:03:04 +00:00
|
|
|
</para>
|
2012-02-17 21:03:46 +00:00
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
|
|
<section id="bsp-filelayout">
|
|
|
|
<title>Example Filesystem Layout</title>
|
2011-05-17 19:03:04 +00:00
|
|
|
|
2010-12-14 00:21:12 +00:00
|
|
|
<para>
|
2012-02-17 21:03:46 +00:00
|
|
|
Below is the common form for the file structure inside a BSP Layer.
|
2010-12-15 17:28:22 +00:00
|
|
|
While you can use this basic form for the standard, realize that the actual structures
|
|
|
|
for specific BSPs could differ.
|
|
|
|
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/
|
|
|
|
meta-<bsp_name>/<bsp_license_file>
|
|
|
|
meta-<bsp_name>/README
|
|
|
|
meta-<bsp_name>/binary/<bootable_images>
|
|
|
|
meta-<bsp_name>/conf/layer.conf
|
|
|
|
meta-<bsp_name>/conf/machine/*.conf
|
|
|
|
meta-<bsp_name>/recipes-bsp/*
|
|
|
|
meta-<bsp_name>/recipes-graphics/*
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-<bsp_name>/recipes-kernel/linux/linux-yocto_<kernel_rev>.bbappend
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2011-08-29 18:46:27 +00:00
|
|
|
Below is an example of the Crown Bay BSP:
|
2011-08-18 23:00:16 +00:00
|
|
|
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-crownbay/COPYING.MIT
|
|
|
|
meta-crownbay/README
|
2012-02-22 20:43:04 +00:00
|
|
|
meta-crownbay/README.sources
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/binary
|
|
|
|
meta-crownbay/conf/
|
2011-08-18 23:00:16 +00:00
|
|
|
meta-crownbay/conf/layer.conf
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/conf/machine/
|
2011-08-18 23:00:16 +00:00
|
|
|
meta-crownbay/conf/machine/crownbay.conf
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/conf/machine/crownbay-noemgd.conf
|
|
|
|
meta-crownbay/recipes-bsp/
|
|
|
|
meta-crownbay/recipes-bsp/formfactor/
|
2011-08-18 23:00:16 +00:00
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor/
|
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/
|
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
|
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/
|
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
|
2011-09-28 19:36:33 +00:00
|
|
|
meta-crownbay/recipes-core
|
|
|
|
meta-crownbay/recipes-core/tasks
|
2012-02-22 20:43:04 +00:00
|
|
|
meta-crownbay/recipes-core/tasks/task-core-tools-profile.bbappend
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/recipes-graphics/
|
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/
|
2011-08-18 23:00:16 +00:00
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/
|
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/
|
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
|
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/
|
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
|
|
|
|
meta-crownbay/recipes-kernel/
|
|
|
|
meta-crownbay/recipes-kernel/linux/
|
2012-02-22 20:43:04 +00:00
|
|
|
meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/recipes-kernel/linux/linux-yocto_2.6.37.bbappend
|
|
|
|
meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2010-12-15 20:46:11 +00:00
|
|
|
</para>
|
|
|
|
|
2010-11-04 20:01:19 +00:00
|
|
|
<para>
|
2010-12-15 20:56:20 +00:00
|
|
|
The following sections describe each part of the proposed BSP format.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id="bsp-filelayout-license">
|
2010-12-15 21:11:27 +00:00
|
|
|
<title>License Files</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
|
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find these files in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/<bsp_license_file>
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-12-15 21:11:27 +00:00
|
|
|
|
|
|
|
<para>
|
|
|
|
These optional files satisfy licensing requirements for the BSP.
|
|
|
|
The type or types of files here can vary depending on the licensing requirements.
|
2011-08-29 18:46:27 +00:00
|
|
|
For example, in the Crown Bay BSP all licensing requirements are handled with the
|
2010-12-15 21:11:27 +00:00
|
|
|
<filename>COPYING.MIT</filename> file.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Licensing files can be MIT, BSD, GPLv*, and so forth.
|
|
|
|
These files are recommended for the BSP but are optional and totally up to the BSP developer.
|
|
|
|
</para>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
2010-12-15 21:19:09 +00:00
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id="bsp-filelayout-readme">
|
2010-12-15 21:19:09 +00:00
|
|
|
<title>README File</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2012-02-22 20:54:58 +00:00
|
|
|
You can find this file in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/README
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-12-15 21:19:09 +00:00
|
|
|
|
|
|
|
<para>
|
|
|
|
This file provides information on how to boot the live images that are optionally
|
|
|
|
included in the <filename>/binary</filename> directory.
|
|
|
|
The <filename>README</filename> file also provides special information needed for
|
|
|
|
building the image.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2012-03-26 16:15:19 +00:00
|
|
|
At a minimum, the <filename>README</filename> file must
|
|
|
|
contain a list of dependencies, such as the names of
|
|
|
|
any other layers on which the BSP depends and the name of
|
|
|
|
the BSP maintainer with his or her contact information.
|
2012-02-22 20:54:58 +00:00
|
|
|
</para>
|
|
|
|
</section>
|
|
|
|
|
|
|
|
<section id="bsp-filelayout-readme-sources">
|
|
|
|
<title>README.sources File</title>
|
|
|
|
<para>
|
|
|
|
You can find this file in the BSP Layer at:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/README.sources
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
This file provides information on where to locate the BSP source files.
|
|
|
|
For example, information provides where to find the sources that comprise
|
|
|
|
the images shipped with the BSP.
|
|
|
|
Information is also included to help you find the metadata used to generate the images
|
|
|
|
that ship with the BSP.
|
|
|
|
</para>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
2010-12-15 21:11:27 +00:00
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id="bsp-filelayout-binary">
|
2010-12-15 21:26:13 +00:00
|
|
|
<title>Pre-built User Binaries</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find these files in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/binary/<bootable_images>
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
|
|
|
<para>
|
2011-03-17 19:35:27 +00:00
|
|
|
This optional area contains useful pre-built kernels and user-space filesystem
|
2010-12-15 01:03:53 +00:00
|
|
|
images appropriate to the target system.
|
2011-05-17 16:28:25 +00:00
|
|
|
This directory typically contains graphical (e.g. sato) and minimal live images
|
2012-02-22 20:58:23 +00:00
|
|
|
when the BSP tarball has been created and made available in the
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
|
2010-12-14 00:21:12 +00:00
|
|
|
You can use these kernels and images to get a system running and quickly get started
|
2010-12-15 21:26:13 +00:00
|
|
|
on development tasks.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2010-12-14 00:21:12 +00:00
|
|
|
The exact types of binaries present are highly hardware-dependent.
|
2012-02-22 20:58:23 +00:00
|
|
|
However, a README file should be present in the BSP Layer that explains how to use
|
2010-12-15 21:26:13 +00:00
|
|
|
the kernels and images with the target hardware.
|
2010-12-14 00:21:12 +00:00
|
|
|
If pre-built binaries are present, source code to meet licensing requirements must also
|
2012-02-22 20:58:23 +00:00
|
|
|
exist in some form.
|
2010-12-14 00:21:12 +00:00
|
|
|
</para>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id='bsp-filelayout-layer'>
|
2010-12-15 21:40:41 +00:00
|
|
|
<title>Layer Configuration File</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find this file in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-<bsp_name>/conf/layer.conf
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
|
|
|
<para>
|
2011-08-29 18:46:27 +00:00
|
|
|
The <filename>conf/layer.conf</filename> file identifies the file structure as a Yocto
|
|
|
|
Project layer, identifies the
|
2011-07-14 21:49:34 +00:00
|
|
|
contents of the layer, and contains information about how Yocto Project should use it.
|
2010-12-16 21:39:14 +00:00
|
|
|
Generally, a standard boilerplate file such as the following works.
|
2012-02-22 21:12:38 +00:00
|
|
|
In the following example, you would replace "<filename>bsp</filename>" and
|
|
|
|
"<filename>_bsp</filename>" with the actual name
|
|
|
|
of the BSP (i.e. <filename><bsp_name></filename> from the example template).
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2012-02-22 21:12:38 +00:00
|
|
|
# We have a conf and classes directory, add to BBPATH
|
2011-08-18 23:00:16 +00:00
|
|
|
BBPATH := "${BBPATH}:${LAYERDIR}"
|
2010-11-04 20:01:19 +00:00
|
|
|
|
2012-02-22 21:12:38 +00:00
|
|
|
# We have a recipes directory, add to BBFILES
|
2011-08-18 23:00:16 +00:00
|
|
|
BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \
|
|
|
|
${LAYERDIR}/recipes/*/*.bbappend"
|
2010-11-04 20:01:19 +00:00
|
|
|
|
2011-08-18 23:00:16 +00:00
|
|
|
BBFILE_COLLECTIONS += "bsp"
|
|
|
|
BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
|
2012-02-22 21:12:38 +00:00
|
|
|
BBFILE_PRIORITY_bsp = "6"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To illustrate the string substitutions, here are the last three statements from the Crown
|
|
|
|
Bay <filename>conf/layer.conf</filename> file:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
BBFILE_COLLECTIONS += "crownbay"
|
|
|
|
BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
|
|
|
|
BBFILE_PRIORITY_crownbay = "6"
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2010-12-14 00:21:12 +00:00
|
|
|
This file simply makes BitBake aware of the recipes and configuration directories.
|
2012-02-22 21:12:38 +00:00
|
|
|
The file must exist so that the Yocto Project build system can recognize the BSP.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id="bsp-filelayout-machine">
|
2010-12-15 22:00:11 +00:00
|
|
|
<title>Hardware Configuration Options</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find these files in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/conf/machine/*.conf
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
|
|
|
<para>
|
|
|
|
The machine files bind together all the information contained elsewhere
|
2011-07-14 21:49:34 +00:00
|
|
|
in the BSP into a format that the Yocto Project build system can understand.
|
2010-11-04 20:01:19 +00:00
|
|
|
If the BSP supports multiple machines, multiple machine configuration files
|
|
|
|
can be present.
|
2011-08-29 18:46:27 +00:00
|
|
|
These filenames correspond to the values to which users have set the
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2010-12-14 00:21:12 +00:00
|
|
|
These files define things such as the kernel package to use
|
2012-03-08 21:17:14 +00:00
|
|
|
(<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink>
|
2012-02-22 22:13:29 +00:00
|
|
|
of virtual/kernel), the hardware drivers to
|
2010-11-04 20:01:19 +00:00
|
|
|
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>
|
2012-02-22 22:13:29 +00:00
|
|
|
Each BSP Layer requires at least one machine file.
|
2010-11-04 20:01:19 +00:00
|
|
|
However, you can supply more than one file.
|
2011-08-29 18:46:27 +00:00
|
|
|
For example, in the Crown Bay BSP shown earlier in this section, the
|
|
|
|
<filename>conf/machine</filename> directory contains two configuration files:
|
|
|
|
<filename>crownbay.conf</filename> and <filename>crownbay-noemgd.conf</filename>.
|
|
|
|
The <filename>crownbay.conf</filename> file is used for the Crown Bay BSP
|
|
|
|
that supports the <trademark class='registered'>Intel</trademark> Embedded
|
|
|
|
Media and Graphics Driver (<trademark class='registered'>Intel</trademark>
|
|
|
|
EMGD), while the <filename>crownbay-noemgd.conf</filename> file is used for the
|
|
|
|
Crown Bay BSP that does not support the <trademark class='registered'>Intel</trademark>
|
|
|
|
EMGD.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2011-08-31 19:28:54 +00:00
|
|
|
This <filename>crownbay.conf</filename> file could also include
|
|
|
|
a hardware "tuning" file that is commonly used to
|
2012-02-22 22:13:29 +00:00
|
|
|
define the package architecture and specify
|
2011-08-31 19:28:54 +00:00
|
|
|
optimization flags, which are carefully chosen to give best
|
|
|
|
performance on a given processor.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
2011-08-31 19:28:54 +00:00
|
|
|
|
2010-11-04 20:01:19 +00:00
|
|
|
<para>
|
2011-08-31 19:28:54 +00:00
|
|
|
Tuning files are found in the <filename>meta/conf/machine/include</filename>
|
2012-02-22 22:13:29 +00:00
|
|
|
directory of the
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>.
|
2012-02-22 22:13:29 +00:00
|
|
|
Tuning files can also reside in the BSP Layer itself.
|
|
|
|
For example, the <filename>ia32-base.inc</filename> file resides in the
|
|
|
|
<filename>meta-intel</filename> BSP Layer in <filename>conf/machine/include</filename>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
To use an include file, you simply include them in the machine configuration file.
|
2011-08-31 19:28:54 +00:00
|
|
|
For example, the Crown Bay BSP <filename>crownbay.conf</filename> has the
|
2012-02-22 22:13:29 +00:00
|
|
|
following statements:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2011-08-31 19:28:54 +00:00
|
|
|
include conf/machine/include/tune-atom.inc
|
2012-02-22 22:13:29 +00:00
|
|
|
include conf/machine/include/ia32-base.inc
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id='bsp-filelayout-misc-recipes'>
|
2010-12-15 22:13:20 +00:00
|
|
|
<title>Miscellaneous Recipe Files</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find these files in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/recipes-bsp/*
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-12-15 22:13:20 +00:00
|
|
|
|
|
|
|
<para>
|
2010-12-16 21:54:15 +00:00
|
|
|
This optional directory contains miscellaneous recipe files for the BSP.
|
|
|
|
Most notably would be the formfactor files.
|
2011-08-29 18:46:27 +00:00
|
|
|
For example, in the Crown Bay BSP there is the
|
|
|
|
<filename>formfactor_0.0.bbappend</filename> file, which is an append file used
|
|
|
|
to augment the recipe that starts the build.
|
|
|
|
Furthermore, there are machine-specific settings used during the build that are
|
|
|
|
defined by the <filename>machconfig</filename> files.
|
|
|
|
In the Crown Bay example, two <filename>machconfig</filename> files exist:
|
2012-02-24 23:44:44 +00:00
|
|
|
one that supports the
|
|
|
|
<trademark class='registered'>Intel</trademark> Embedded
|
|
|
|
Media and Graphics Driver (<trademark class='registered'>Intel</trademark>
|
|
|
|
EMGD) and one that does not:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
|
2011-08-18 23:00:16 +00:00
|
|
|
meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
|
|
|
|
</literallayout>
|
2010-12-15 22:13:20 +00:00
|
|
|
</para>
|
2010-12-16 21:54:15 +00:00
|
|
|
|
|
|
|
<note><para>
|
|
|
|
If a BSP does not have a formfactor entry, defaults are established according to
|
2012-02-24 22:57:10 +00:00
|
|
|
the formfactor configuration file that is installed by the main
|
|
|
|
formfactor recipe
|
|
|
|
<filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>,
|
|
|
|
which is found in the
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>.
|
2010-12-16 21:54:15 +00:00
|
|
|
</para></note>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
2010-12-15 22:13:20 +00:00
|
|
|
|
2011-09-28 19:36:33 +00:00
|
|
|
<section id='bsp-filelayout-core-recipes'>
|
|
|
|
<title>Core Recipe Files</title>
|
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find these files in the BSP Layer at:
|
2011-09-28 19:36:33 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/recipes-core/*
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2012-02-22 22:47:20 +00:00
|
|
|
This directory contains recipe files that are almost always necessary to build a
|
|
|
|
useful, working Linux image.
|
|
|
|
Thus, the term "core" is used to group these recipes.
|
2011-09-28 19:36:33 +00:00
|
|
|
For example, in the Crown Bay BSP there is the
|
2012-02-22 22:47:20 +00:00
|
|
|
<filename>task-core-tools-profile.bbappend</filename> file, which is an append file used
|
|
|
|
to recommend that the
|
|
|
|
<ulink url='http://sourceware.org/systemtap/wiki'>SystemTap</ulink>
|
|
|
|
package be included as a package when the image is built.
|
2011-09-28 19:36:33 +00:00
|
|
|
</para>
|
|
|
|
</section>
|
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id='bsp-filelayout-recipes-graphics'>
|
2010-12-15 22:25:34 +00:00
|
|
|
<title>Display Support Files</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find these files in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-<bsp_name>/recipes-graphics/*
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-12-15 22:25:34 +00:00
|
|
|
|
|
|
|
<para>
|
2010-12-16 21:58:32 +00:00
|
|
|
This optional directory contains recipes for the BSP if it has
|
|
|
|
special requirements for graphics support.
|
2010-12-15 22:25:34 +00:00
|
|
|
All files that are needed for the BSP to support a display are kept here.
|
2012-02-22 23:09:28 +00:00
|
|
|
For example, the Crown Bay BSP contains two versions of the
|
|
|
|
<filename>xorg.conf</filename> file.
|
|
|
|
The version in <filename>crownbay</filename> builds a BSP that supports the
|
|
|
|
<trademark class='registered'>Intel</trademark> Embedded Media Graphics Driver (EMGD),
|
|
|
|
while the version in <filename>crownbay-noemgd</filename> builds
|
|
|
|
a BSP that supports Video Electronics Standards Association (VESA) graphics only:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
|
|
|
|
meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2010-12-15 22:25:34 +00:00
|
|
|
</para>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
2010-12-15 22:25:34 +00:00
|
|
|
|
2010-12-15 22:37:33 +00:00
|
|
|
<section id='bsp-filelayout-kernel'>
|
2010-12-15 22:29:36 +00:00
|
|
|
<title>Linux Kernel Configuration</title>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2012-02-22 20:48:38 +00:00
|
|
|
You can find these files in the BSP Layer at:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-<bsp_name>/recipes-kernel/linux/linux-yocto_*.bbappend
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
|
|
|
</para>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
|
|
|
<para>
|
2011-08-29 18:46:27 +00:00
|
|
|
These files append your specific changes to the kernel you are using.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
<para>
|
2011-08-29 18:46:27 +00:00
|
|
|
For your BSP, you typically want to use an existing Yocto Project kernel found in the
|
2012-03-08 21:17:14 +00:00
|
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto
|
2012-02-24 23:44:44 +00:00
|
|
|
Project Files</ulink> at <filename>meta/recipes-kernel/linux</filename>.
|
2011-08-29 18:46:27 +00:00
|
|
|
You can append your specific changes to the kernel recipe by using a
|
2012-03-13 18:34:30 +00:00
|
|
|
similarly named append file, which is located in the BSP Layer (e.g.
|
2012-02-24 23:44:44 +00:00
|
|
|
the <filename>meta-<bsp_name>/recipes-kernel/linux</filename> directory).
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
<para>
|
2012-02-24 23:44:44 +00:00
|
|
|
Suppose the BSP uses the <filename>linux-yocto_3.0.bb</filename> kernel,
|
2010-12-17 22:53:40 +00:00
|
|
|
which is the preferred kernel to use for developing a new BSP using the Yocto Project.
|
2010-12-18 00:53:59 +00:00
|
|
|
In other words, you have selected the kernel in your
|
2011-08-29 18:46:27 +00:00
|
|
|
<filename><bsp_name>.conf</filename> file by adding the following statements:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
2011-08-29 18:46:27 +00:00
|
|
|
PREFERRED_VERSION_linux-yocto = "3.0%"
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2011-08-29 18:46:27 +00:00
|
|
|
You would use the <filename>linux-yocto_3.0.bbappend</filename> file to append
|
2010-12-17 16:30:35 +00:00
|
|
|
specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
|
|
|
<para>
|
2011-08-29 18:46:27 +00:00
|
|
|
As an example, look at the existing Crown Bay BSP.
|
2010-12-18 00:53:59 +00:00
|
|
|
The append file used is:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2011-08-29 18:46:27 +00:00
|
|
|
meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2012-02-07 22:21:00 +00:00
|
|
|
The following listing shows the file.
|
|
|
|
Be aware that the actual commit ID strings in this example listing might be different
|
2012-02-24 23:44:44 +00:00
|
|
|
than the actual strings in the file from the <filename>meta-intel</filename>
|
2012-02-07 22:21:00 +00:00
|
|
|
Git source repository.
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2011-08-29 18:46:27 +00:00
|
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
|
|
|
|
2011-08-18 23:00:16 +00:00
|
|
|
COMPATIBLE_MACHINE_crownbay = "crownbay"
|
2011-08-29 18:46:27 +00:00
|
|
|
KMACHINE_crownbay = "yocto/standard/crownbay"
|
|
|
|
KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
|
|
|
|
|
|
|
|
COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
|
|
|
|
KMACHINE_crownbay-noemgd = "yocto/standard/crownbay"
|
|
|
|
KERNEL_FEATURES_append_crownbay-noemgd += " cfg/smp.scc"
|
|
|
|
|
2012-02-07 18:54:47 +00:00
|
|
|
SRCREV_machine_pn-linux-yocto_crownbay ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
|
|
|
|
SRCREV_meta_pn-linux-yocto_crownbay ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"
|
2011-08-29 18:46:27 +00:00
|
|
|
|
2012-02-07 18:54:47 +00:00
|
|
|
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
|
|
|
|
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"
|
2011-08-29 18:46:27 +00:00
|
|
|
</literallayout>
|
2012-02-24 23:44:44 +00:00
|
|
|
This append file contains statements used to support the Crown Bay BSP for both
|
|
|
|
<trademark class='registered'>Intel</trademark> EMGD and the VESA graphics.
|
2011-08-31 19:28:54 +00:00
|
|
|
The build process, in this case, recognizes and uses only the statements that
|
|
|
|
apply to the defined machine name - <filename>crownbay</filename> in this case.
|
|
|
|
So, the applicable statements in the <filename>linux-yocto_3.0.bbappend</filename>
|
|
|
|
file are follows:
|
2011-08-29 18:46:27 +00:00
|
|
|
<literallayout class='monospaced'>
|
|
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
|
|
|
|
|
|
|
COMPATIBLE_MACHINE_crownbay = "crownbay"
|
|
|
|
KMACHINE_crownbay = "yocto/standard/crownbay"
|
|
|
|
KERNEL_FEATURES_append_crownbay += " cfg/smp.scc"
|
|
|
|
|
2012-02-07 18:54:47 +00:00
|
|
|
SRCREV_machine_pn-linux-yocto_crownbay ?= "63c65842a3a74e4bd3128004ac29b5639f16433f"
|
|
|
|
SRCREV_meta_pn-linux-yocto_crownbay ?= "59314a3523e360796419d76d78c6f7d8c5ef2593"
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2012-03-13 18:34:30 +00:00
|
|
|
The append file defines <filename>crownbay</filename> as the compatible machine and
|
|
|
|
defines the <filename>KMACHINE</filename>.
|
|
|
|
The file also points to some configuration fragments to use by setting the
|
|
|
|
<filename>KERNEL_FEATURES</filename> variable.
|
|
|
|
The location for the configuration fragments is the kernel tree itself in the
|
|
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project Build
|
|
|
|
Directory</ulink> under <filename>linux/meta</filename>.
|
|
|
|
Finally, the append file points to the specific commits in the
|
|
|
|
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink> Git
|
|
|
|
repository and the <filename>meta</filename> Git repository branches to identify the
|
|
|
|
exact kernel needed to build the Crown Bay BSP.
|
2010-11-04 20:01:19 +00:00
|
|
|
</para>
|
2010-12-17 22:53:40 +00:00
|
|
|
<para>
|
|
|
|
One thing missing in this particular BSP, which you will typically need when
|
2011-08-29 18:46:27 +00:00
|
|
|
developing a BSP, is the kernel configuration file (<filename>.config</filename>) for your BSP.
|
2010-12-17 22:53:40 +00:00
|
|
|
When developing a BSP, you probably have a kernel configuration file or a set of kernel
|
|
|
|
configuration files that, when taken together, define the kernel configuration for your BSP.
|
|
|
|
You can accomplish this definition by putting the configurations in a file or a set of files
|
|
|
|
inside a directory located at the same level as your append file and having the same name
|
|
|
|
as the kernel.
|
2011-08-29 18:46:27 +00:00
|
|
|
With all these conditions met simply reference those files in a
|
|
|
|
<filename>SRC_URI</filename> statement in the append file.
|
2010-12-17 22:53:40 +00:00
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
For example, suppose you had a set of configuration options in a file called
|
2012-03-13 18:34:30 +00:00
|
|
|
<filename>myconfig</filename>.
|
2010-12-17 22:53:40 +00:00
|
|
|
If you put that file inside a directory named
|
2011-08-29 18:46:27 +00:00
|
|
|
<filename>/linux-yocto</filename> and then added
|
|
|
|
a <filename>SRC_URI</filename> statement such as the following to the append file,
|
|
|
|
those configuration
|
2010-12-17 22:53:40 +00:00
|
|
|
options will be picked up and applied when the kernel is built.
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2012-03-13 18:34:30 +00:00
|
|
|
SRC_URI += "file://myconfig"
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2010-12-17 22:53:40 +00:00
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
As mentioned earlier, you can group related configurations into multiple files and
|
2011-08-29 18:46:27 +00:00
|
|
|
name them all in the <filename>SRC_URI</filename> statement as well.
|
2010-12-18 00:59:47 +00:00
|
|
|
For example, you could group separate configurations specifically for Ethernet and graphics
|
2011-08-29 18:46:27 +00:00
|
|
|
into their own files and add those by using a <filename>SRC_URI</filename> statement like the
|
2010-12-17 22:53:40 +00:00
|
|
|
following in your append file:
|
2011-08-18 23:00:16 +00:00
|
|
|
<literallayout class='monospaced'>
|
2012-03-13 18:34:30 +00:00
|
|
|
SRC_URI += "file://myconfig \
|
2010-12-17 22:53:40 +00:00
|
|
|
file://eth.cfg \
|
|
|
|
file://gfx.cfg"
|
2011-08-18 23:00:16 +00:00
|
|
|
</literallayout>
|
2010-12-17 22:53:40 +00:00
|
|
|
</para>
|
|
|
|
<para>
|
2012-03-13 18:34:30 +00:00
|
|
|
The <filename>FILESEXTRAPATHS</filename> variable is in boilerplate form in the
|
|
|
|
previous example in order to make it easy to do that.
|
|
|
|
This variable must be in your layer or BitBake will not find the patches or
|
|
|
|
configurations even if you have them in your <filename>SRC_URI</filename>.
|
|
|
|
The <filename>FILESEXTRAPATHS</filename> variable enables the build process to
|
|
|
|
find those configuration files.
|
2010-12-17 22:53:40 +00:00
|
|
|
</para>
|
2011-08-18 23:00:16 +00:00
|
|
|
<note>
|
|
|
|
<para>
|
2010-12-17 22:53:40 +00:00
|
|
|
Other methods exist to accomplish grouping and defining configuration options.
|
2012-03-13 18:34:30 +00:00
|
|
|
For example, if you are working with a local clone of the kernel repository,
|
|
|
|
you could checkout the kernel's <filename>meta</filename> branch, make your changes,
|
|
|
|
and then push the changes to the local bare clone of the kernel.
|
|
|
|
The result is that you directly add configuration options to the Yocto kernel
|
2011-08-29 18:46:27 +00:00
|
|
|
<filename>meta</filename> branch for your BSP.
|
2010-12-17 22:53:40 +00:00
|
|
|
The configuration options will likely end up in that location anyway if the BSP gets
|
|
|
|
added to the Yocto Project.
|
2012-02-07 19:01:04 +00:00
|
|
|
For an example showing how to change the BSP configuration, see the
|
2012-03-13 18:34:30 +00:00
|
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#changing-the-bsp-configuration'>Changing the BSP Configuration</ulink>"
|
|
|
|
section in the Yocto Project Development Manual.
|
|
|
|
For a better understanding of working with a local clone of the kernel repository
|
|
|
|
and a local bare clone of the kernel, see the
|
|
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#modifying-the-kernel-source-code'>Modifying the Kernel
|
|
|
|
Source Code</ulink>" section also in the Yocto Project Development Manual.</para>
|
2011-08-18 23:00:16 +00:00
|
|
|
<para>
|
2011-08-29 18:46:27 +00:00
|
|
|
In general, however, the Yocto Project maintainers take care of moving the
|
|
|
|
<filename>SRC_URI</filename>-specified
|
2012-03-13 18:34:30 +00:00
|
|
|
configuration options to the kernel's <filename>meta</filename> branch.
|
2010-12-17 22:53:40 +00:00
|
|
|
Not only is it easier for BSP developers to not have to worry about putting those
|
2010-12-18 00:59:47 +00:00
|
|
|
configurations in the branch, but having the maintainers do it allows them to apply
|
2010-12-17 22:53:40 +00:00
|
|
|
'global' knowledge about the kinds of common configuration options multiple BSPs in
|
|
|
|
the tree are typically using.
|
2011-08-18 23:00:16 +00:00
|
|
|
This allows for promotion of common configurations into common features.</para>
|
|
|
|
</note>
|
2010-12-15 22:37:33 +00:00
|
|
|
</section>
|
|
|
|
</section>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
2012-03-22 19:43:51 +00:00
|
|
|
<section id='bsp-licensing-considerations'>
|
2012-03-22 13:20:52 +00:00
|
|
|
<title>BSP Licensing Considerations</title>
|
2012-03-22 19:43:51 +00:00
|
|
|
|
2010-11-04 20:01:19 +00:00
|
|
|
<para>
|
2012-03-22 19:43:51 +00:00
|
|
|
In some cases, a BSP contains separately licensed Intellectual Property (IP)
|
|
|
|
for a component or components.
|
|
|
|
For these cases, you are required to accept the terms of a commercial or other
|
|
|
|
type of license that requires some kind of explicit End User License Agreement (EULA).
|
|
|
|
Once the license is accepted, the Yocto Project build system can then build and
|
|
|
|
include the corresponding component in the final BSP image.
|
|
|
|
If the BSP is available as a pre-built image, you can download the image after
|
|
|
|
agreeing to the license or EULA.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
You could find that some separately licensed components that are essential
|
|
|
|
for normal operation of the system might not have an unencumbered (or free)
|
|
|
|
substitute.
|
|
|
|
Without these essential components, the system would be non-functional.
|
|
|
|
Then again, you might find that other licensed components that are simply
|
|
|
|
'good-to-have' or purely elective do have an unencumbered, free replacement
|
|
|
|
component that you can use rather than agreeing to the separately licensed component.
|
|
|
|
Even for components essential to the system, you might find an unencumbered component
|
|
|
|
that is not identical but will work as a less-capable version of the
|
|
|
|
licensed version in the BSP recipe.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
For cases where you can substitute a free component and still
|
|
|
|
maintain the system's functionality, the Yocto Project website's
|
|
|
|
<ulink url='&YOCTO_HOME_URL;/download/all?keys=&download_type=1&download_version='>BSP
|
|
|
|
Download Page</ulink> makes available de-featured BSPs
|
|
|
|
that are completely free of any IP encumbrances.
|
|
|
|
For these cases, you can use the substitution directly and
|
|
|
|
without any further licensing requirements.
|
|
|
|
If present, these fully de-featured BSPs are named appropriately
|
|
|
|
different as compared to the names of the respective
|
|
|
|
encumbered BSPs.
|
|
|
|
If available, these substitutions are your
|
|
|
|
simplest and most preferred options.
|
|
|
|
Use of these substitutions of course assumes the resulting functionality meets
|
|
|
|
system requirements.
|
|
|
|
</para>
|
2010-11-04 20:01:19 +00:00
|
|
|
|
2012-03-22 19:43:51 +00:00
|
|
|
<para>
|
|
|
|
If however, a non-encumbered version is unavailable or
|
|
|
|
it provides unsuitable functionality or quality, you can use an encumbered
|
|
|
|
version.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A couple different methods exist within the Yocto
|
|
|
|
Project build system to satisfy the licensing
|
|
|
|
requirements for an encumbered BSP.
|
|
|
|
The following list describes them in order of preference:
|
|
|
|
<orderedlist>
|
|
|
|
<listitem><para><emphasis>Use the <filename>LICENSE_FLAGS</filename> variable
|
|
|
|
to define the Yocto Project recipes that have commercial or other types of
|
|
|
|
specially-licensed packages:</emphasis>
|
|
|
|
For each of those recipes, you can
|
|
|
|
specify a matching license string in a
|
|
|
|
<filename>local.conf</filename> variable named
|
|
|
|
<filename>LICENSE_FLAGS_WHITELIST</filename>.
|
|
|
|
Specifying the matching license string signifies that you agree to the license.
|
|
|
|
Thus, the build system can build the corresponding recipe and include
|
|
|
|
the component in the image.
|
|
|
|
See the
|
|
|
|
"<ulink url='&YOCTO_DOCS_REF_URL;#enabling-commercially-licensed-recipes'>Enabling
|
|
|
|
Commercially Licensed Recipes</ulink>" section in the Yocto Project Reference
|
|
|
|
Manual for details on how to use these variables.</para>
|
|
|
|
<para>If you build as you normally would, without
|
|
|
|
specifying any recipes in the
|
|
|
|
<filename>LICENSE_FLAGS_WHITELIST</filename>, the build stops and
|
|
|
|
provides you with the list of recipes that you have
|
|
|
|
tried to include in the image that need entries in
|
|
|
|
the <filename>LICENSE_FLAGS_WHITELIST</filename>.
|
|
|
|
Once you enter the appropriate license flags into the whitelist,
|
|
|
|
restart the build to continue where it left off.
|
|
|
|
During the build, the prompt will not appear again
|
|
|
|
since you have satisfied the requirement.</para>
|
|
|
|
<para>Once the appropriate license flags are whitelisted
|
|
|
|
in the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, you
|
|
|
|
can build the encumbered image with no change at all
|
|
|
|
to the normal build process.</para></listitem>
|
|
|
|
<listitem><para><emphasis>Get a pre-built version of the BSP:</emphasis>
|
|
|
|
You can get this type of BSP by visiting the Yocto Project website's
|
|
|
|
<ulink url='&YOCTO_HOME_URL;/download'>Download</ulink>
|
|
|
|
page and clicking on "BSP Downloads".
|
|
|
|
You can download BSP tarballs that contain proprietary components
|
|
|
|
after agreeing to the licensing
|
|
|
|
requirements of each of the individually encumbered
|
|
|
|
packages as part of the download process.
|
|
|
|
Obtaining the BSP this way allows you to access an encumbered
|
|
|
|
image immediately after agreeing to the
|
|
|
|
click-through license agreements presented by the
|
|
|
|
website.
|
|
|
|
Note that if you want to build the image
|
|
|
|
yourself using the recipes contained within the BSP
|
|
|
|
tarball, you will still need to create an
|
|
|
|
appropriate <filename>LICENSE_FLAGS_WHITELIST</filename> to match the
|
|
|
|
encumbered recipes in the BSP.</para></listitem>
|
|
|
|
</orderedlist>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<note>
|
|
|
|
Pre-compiled images are bundled with
|
|
|
|
a time-limited kernel that runs for a
|
|
|
|
predetermined amount of time (10 days) before it forces
|
|
|
|
the system to reboot.
|
|
|
|
This limitation is meant to discourage direct redistribution
|
|
|
|
of the image.
|
|
|
|
You must eventually rebuild the image if you want to remove this restriction.
|
|
|
|
</note>
|
|
|
|
</section>
|
2012-04-02 15:07:36 +00:00
|
|
|
<section id='yocto-bsp-tools'>
|
|
|
|
<title>Using the Yocto BSP Tools</title>
|
|
|
|
<para>
|
|
|
|
The Yocto Project includes a couple of tools that enable
|
|
|
|
you to create a BSP from scratch
|
|
|
|
(<filename>yocto-bsp</filename>) and do basic
|
|
|
|
configuration and maintenance of the kernel
|
|
|
|
(<filename>yocto-kernel</filename>) without ever looking at
|
|
|
|
a Yocto metadata file.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The following sections describe each of those tools in
|
|
|
|
detail, but there are some features common to both that
|
|
|
|
will be useful to describe before delving into the
|
|
|
|
details of either.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
First, a word about how the tools are structured.
|
|
|
|
Designed to have a 'git-like' command interface, each
|
|
|
|
tool is structured as a set of sub-commands under a
|
|
|
|
'top-level' command. The top-level command
|
|
|
|
(<filename>yocto-bsp</filename>
|
|
|
|
or <filename>yocto-kernel</filename>) itself does
|
|
|
|
nothing but invoke or provide help on the sub-commands
|
|
|
|
it supports.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Secondly, since the tools themselves live in
|
|
|
|
the <filename>scripts/</filename> subdirectory, in order
|
|
|
|
to use them, you need to 'source' the environment just
|
|
|
|
as you would when invoking a build:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ source oe-init-build-env [build_dir]
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
With that in mind, the most immediately useful function
|
|
|
|
to describe is the built-in help system common to both
|
|
|
|
tools.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The built-in help system makes it easy to drill down at
|
|
|
|
any time and remind oneself of the syntax required for
|
|
|
|
any specific command.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Simply entering the name of the command, or the command
|
|
|
|
along with 'help' will display a list of the available
|
|
|
|
sub-commands. For example:
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-bsp
|
|
|
|
$ yocto-bsp help
|
|
|
|
|
|
|
|
Usage:
|
|
|
|
|
|
|
|
Create a customized Yocto BSP layer.
|
|
|
|
|
|
|
|
usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
|
|
|
|
|
|
|
|
The most commonly used 'yocto-bsp' commands are:
|
|
|
|
create Create a new Yocto BSP
|
|
|
|
list List available values for options and BSP properties
|
|
|
|
|
|
|
|
See 'yocto-bsp help COMMAND' for more information on a specific command.
|
|
|
|
|
|
|
|
|
|
|
|
Options:
|
|
|
|
--version show program's version number and exit
|
|
|
|
-h, --help show this help message and exit
|
|
|
|
-D, --debug output debug information
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Similarly, entering just the name of a sub-command will
|
|
|
|
show the detailed usage for that sub-command:
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-bsp create
|
|
|
|
|
|
|
|
Usage:
|
|
|
|
|
|
|
|
Create a new Yocto BSP
|
|
|
|
usage: yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>]
|
|
|
|
[-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]
|
|
|
|
|
|
|
|
This command creates a Yocto BSP based on the specified parameters.
|
|
|
|
The new BSP will be a new Yocto BSP layer contained by default within
|
|
|
|
the top-level directory specified as 'meta-bsp-name'. The -o option
|
|
|
|
can be used to place the BSP layer in a directory with a different
|
|
|
|
name and location.
|
|
|
|
|
|
|
|
...
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
For any sub-command, you can also use the word 'help'
|
|
|
|
just before the sub-command to get more extensive
|
|
|
|
documentation on the sub-command:
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-bsp help create
|
|
|
|
|
|
|
|
NAME
|
|
|
|
yocto-bsp create - Create a new Yocto BSP
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
yocto-bsp create <bsp-name> <karch> [-o <DIRNAME> | --outdir <DIRNAME>]
|
|
|
|
[-i <JSON PROPERTY FILE> | --infile <JSON PROPERTY_FILE>]
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
This command creates a Yocto BSP based on the specified
|
|
|
|
parameters. The new BSP will be a new Yocto BSP layer contained
|
|
|
|
by default within the top-level directory specified as
|
|
|
|
'meta-bsp-name'. The -o option can be used to place the BSP layer
|
|
|
|
in a directory with a different name and location.
|
|
|
|
|
|
|
|
The value of the 'karch' parameter determines the set of files
|
|
|
|
that will be generated for the BSP, along with the specific set of
|
|
|
|
'properties' that will be used to fill out the BSP-specific
|
|
|
|
portions of the BSP.
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
NOTE: Once created, you should add your new layer to your
|
|
|
|
bblayers.conf file in order for it to be subsquently seen and
|
|
|
|
modified by the yocto-kernel tool.
|
|
|
|
|
|
|
|
NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
|
|
|
|
presence of the of the meta-intel layer, so you should also have a
|
|
|
|
meta-intel layer present and added to your bblayers.conf as well.
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
With the knowledge that there are two
|
|
|
|
commands, <filename>yocto-bsp</filename>
|
|
|
|
and <filename>yocto-kernel</filename> and a built-in
|
|
|
|
help system available for each, it should be relatively
|
|
|
|
straightforward to discover the commands necessary to
|
|
|
|
create a BSP and do basic kernel maintainence of that
|
|
|
|
BSP using the tools. The following sections are
|
|
|
|
provided, however, in order to serve as a concrete
|
|
|
|
starting point and to expand on a few points that may
|
|
|
|
not be immediately obvious or that could use further
|
|
|
|
explanation.
|
|
|
|
</para>
|
|
|
|
<section id='using-yocto-bsp'>
|
|
|
|
<title>Creating a new BSP using <filename>yocto-bsp</filename></title>
|
|
|
|
<para>
|
|
|
|
<filename>yocto-bsp</filename> is a Yocto script that
|
|
|
|
allows you to create a new Yocto BSP for any
|
|
|
|
architecture supported Yocto, as well as qemu versions
|
|
|
|
of the same. The default mode of operation when invoked
|
|
|
|
from the command-line is to prompt the user for
|
|
|
|
information needed to generate the BSP. For the current
|
|
|
|
set of BSPs, the user is prompted for various important
|
|
|
|
parameters such as which kernel to use, which branch of
|
|
|
|
that kernel to use (or re-use), whether or not to use X,
|
|
|
|
and if so, which drivers to use, whether to turn on SMP,
|
|
|
|
whether the BSP has a keyboard, touchscreen, or anything
|
|
|
|
that happens to be configurable and has an associated
|
|
|
|
input prompt.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The <filename>yocto-bsp create</filename> sub-command is
|
|
|
|
the sub-command you use to create a new BSP. It
|
|
|
|
requires you to specify a particular architecture to
|
|
|
|
base the BSP on. You can use the <filename>yocto-bsp
|
|
|
|
list karch</filename> sub-command to list the
|
|
|
|
architectures available for BSP creation:
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Assuming you've sourced the environment, you can invoke
|
|
|
|
the <filename>yocto-bsp create</filename> command to
|
|
|
|
create the BSP. The example below uses 'myarm' as the
|
|
|
|
machine name, and tells it to use the 'qemu'
|
|
|
|
architecture (the specific qemu machine architecture to
|
|
|
|
use will be prompted for). You can use the 'yocto-bsp
|
|
|
|
list karch' command to list the aviailable architectures
|
|
|
|
for BSP creation:
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-bsp list karch
|
|
|
|
Architectures available:
|
|
|
|
arm
|
|
|
|
powerpc
|
|
|
|
i386
|
|
|
|
mips
|
|
|
|
x86_64
|
|
|
|
qemu
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
For the example output below, we'll use the 'qemu'
|
|
|
|
architecture, which is a special architecture that is
|
|
|
|
the only one of the supported architectures that will
|
|
|
|
prompt you further for a 'real' architecture. In every
|
|
|
|
other way, it's representative of how creating a BSP for
|
|
|
|
a 'real' machine would work; the reason we're using it
|
|
|
|
here as an example is that since it's an emulated
|
|
|
|
architecture, it's easy for readers to try out
|
|
|
|
themselves without having any special hardware
|
|
|
|
requirements.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The 'yocto-bsp create' command for the qemu architecture
|
|
|
|
will display the following prompts along the way to
|
|
|
|
gather the input required for BSP generation. Each
|
|
|
|
prompt asks for input, but has a default value [in
|
|
|
|
brackets]. If you press 'enter' (or any invalid value),
|
|
|
|
the default value will automatically be used.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
In the case of the qemu architecture, the first prompt
|
|
|
|
asks which emulated architecture to use. In this
|
|
|
|
example, we'll use the 'arm' qemu architecture.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
It then asks if the default kernel (3.2) is ok, and we
|
|
|
|
press enter, essentially telling it 'yes'. If we had
|
|
|
|
entered 'n', we would have been prompted to choose a
|
|
|
|
different kernel from a list of available kernels (3.0,
|
|
|
|
3.2_preempt-rt, etc).
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Once we've selected the kernel, the next prompt asks
|
|
|
|
whether we'd like to have a new branch in the Yocto
|
|
|
|
kernel git repository created especially for this BSP,
|
|
|
|
or whether we'll just re-use an existing branch. If we
|
|
|
|
say 'yes', which is the default, the BSP code generated
|
|
|
|
will create a new branch specifically for the BSP rather
|
|
|
|
than a common shared branch; this is the branch that any
|
|
|
|
patches we add later would be committed. The reason
|
|
|
|
creating a new branch is the default is that typically
|
|
|
|
new BSPs do require BSP-specific patches and so the BSP
|
|
|
|
tool assumes that most of time a new branch will be
|
|
|
|
required. Note that in the current implementation it
|
|
|
|
doesn't actually matter, since the generated BSPs assume
|
|
|
|
that patches and configuration live in recipe-space,
|
|
|
|
which is something that can be done with or without a
|
|
|
|
dedicated branch. The BSP that's generated, however,
|
|
|
|
will be different, and this difference will become
|
|
|
|
significant once 'publish' functionality is implemented.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Regardless of which choice we made in the previous step,
|
|
|
|
we're then given the opportunity to select a particular
|
|
|
|
machine branch to base our new BSP-specific machine
|
|
|
|
branch on (or re-use if we elected not to create a new
|
|
|
|
branch). Because we're generating an arm BSP, we choose
|
|
|
|
#3 at that prompt to select the arm-versatile branch.
|
|
|
|
The rest of the prompts are routine, and once all the
|
|
|
|
questions have been completed, the BSP is generated
|
|
|
|
along with a message telling you so. The output of the
|
|
|
|
complete session is shown below:
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-bsp create myarm qemu
|
|
|
|
Which qemu architecture would you like to use? [default: x86]
|
|
|
|
1) common 32-bit x86
|
|
|
|
2) common 64-bit x86
|
|
|
|
3) common 32-bit ARM
|
|
|
|
4) common 32-bit PowerPC
|
|
|
|
5) common 32-bit MIPS
|
|
|
|
3
|
|
|
|
Would you like to use the default (3.2) kernel? (Y/n)
|
|
|
|
Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n]
|
|
|
|
Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2...
|
|
|
|
Please choose a machine branch to base this BSP on => [default: standard/default/common-pc]
|
|
|
|
1) base
|
|
|
|
2) standard/base
|
|
|
|
3) standard/default/arm-versatile-926ejs
|
|
|
|
4) standard/default/base
|
|
|
|
5) standard/default/beagleboard
|
|
|
|
6) standard/default/cedartrail
|
|
|
|
7) standard/default/common-pc-64/base
|
|
|
|
8) standard/default/common-pc-64/jasperforest
|
|
|
|
9) standard/default/common-pc-64/romley
|
|
|
|
10) standard/default/common-pc-64/sugarbay
|
|
|
|
11) standard/default/common-pc/atom-pc
|
|
|
|
12) standard/default/common-pc/base
|
|
|
|
13) standard/default/crownbay
|
|
|
|
14) standard/default/emenlow
|
|
|
|
15) standard/default/fishriver
|
|
|
|
16) standard/default/fri2
|
|
|
|
17) standard/default/fsl-mpc8315e-rdb
|
|
|
|
18) standard/default/mti-malta32-be
|
|
|
|
19) standard/default/mti-malta32-le
|
|
|
|
20) standard/default/preempt-rt
|
|
|
|
21) standard/default/qemu-ppc32
|
|
|
|
22) standard/default/routerstationpro
|
|
|
|
23) standard/preempt-rt/base
|
|
|
|
24) standard/preempt-rt/qemu-ppc32
|
|
|
|
25) standard/preempt-rt/routerstationpro
|
|
|
|
26) standard/tiny
|
|
|
|
3
|
|
|
|
Do you need SMP support? (Y/n)
|
|
|
|
Does your BSP have a touchscreen? (y/N)
|
|
|
|
Does your BSP have a keyboard? (Y/n)
|
|
|
|
New qemu BSP created in meta-myarm
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Now that we have our BSP created, we need to add it to
|
|
|
|
our bblayers.conf. This of course is required in order
|
|
|
|
to build the BSP, but it's also required in order for
|
|
|
|
the <filename>yocto-kernel</filename> tool to be able to
|
|
|
|
find the layer and other metadata it needs to operate
|
|
|
|
on.
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
BBLAYERS = " \
|
|
|
|
/usr/local/src/yocto/meta \
|
|
|
|
/usr/local/src/yocto/meta-yocto \
|
|
|
|
/usr/local/src/yocto/meta-myarm \
|
|
|
|
"
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
</section>
|
|
|
|
<section id='using-yocto-kernel'>
|
|
|
|
<title>Managing Kernel Patches and Config Items
|
|
|
|
with <filename>yocto-kernel</filename></title>
|
|
|
|
<para>
|
|
|
|
Assuming we've created a Yocto BSP layer
|
|
|
|
using <filename>yocto-bsp</filename> and added it to our
|
|
|
|
BBLAYERS, we can now use
|
|
|
|
the <filename>yocto-kernel</filename> command to add
|
|
|
|
patches and config items to the BSP's
|
|
|
|
kernel. <filename>yocto-kernel</filename> is a Yocto
|
|
|
|
script that allows you to add, remove, and list patches
|
|
|
|
and kernel config settings to a Yocto BSP's kernel
|
|
|
|
.bbappend file. The easiest way to see exactly what
|
|
|
|
sub-commands are available
|
|
|
|
using <filename>yocto-kernel</filename> is again to make
|
|
|
|
use of the built-in help:
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-kernel
|
|
|
|
Usage:
|
|
|
|
|
|
|
|
Modify and list Yocto BSP kernel config items and patches.
|
|
|
|
|
|
|
|
usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
|
|
|
|
|
|
|
|
The most commonly used 'yocto-kernel' commands are:
|
|
|
|
config list List the modifiable set of bare kernel config options for a BSP
|
|
|
|
config add Add or modify bare kernel config options for a BSP
|
|
|
|
config rm Remove bare kernel config options from a BSP
|
|
|
|
patch list List the patches associated with a BSP
|
|
|
|
patch add Patch the Yocto kernel for a BSP
|
|
|
|
patch rm Remove patches from a BSP
|
|
|
|
|
|
|
|
See 'yocto-kernel help COMMAND' for more information on a specific command.
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
The <filename>yocto-kernel patch add</filename>
|
|
|
|
sub-command allows us to add a patch to a BSP. The
|
|
|
|
following commands add a couple of patches to the
|
|
|
|
'myarm' BSP:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-kernel patch add myarm ~/test.patch
|
|
|
|
Added patches:
|
|
|
|
test.patch
|
|
|
|
|
|
|
|
$ yocto-kernel patch add myarm ~/yocto-testmod.patch
|
|
|
|
Added patches:
|
|
|
|
yocto-testmod.patch
|
|
|
|
</literallayout>
|
|
|
|
Note that though we added patches one by one above, we
|
|
|
|
could also add multiple patches at the same time if we
|
|
|
|
wanted to.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
We can verify that the patches were added by using
|
|
|
|
the <filename>yocto-kernel patch list</filename>
|
|
|
|
sub-command:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-kernel patch list myarm
|
|
|
|
The current set of machine-specific patches for myarm is:
|
|
|
|
1) test.patch
|
|
|
|
2) yocto-testmod.patch
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
We can also use <filename>yocto-kernel</filename> to
|
|
|
|
remove a patch using the <filename>yocto-kernel patch
|
|
|
|
rm</filename> sub-command:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-kernel patch rm myarm
|
|
|
|
Specify the patches to remove:
|
|
|
|
1) test.patch
|
|
|
|
2) yocto-testmod.patch
|
|
|
|
1
|
|
|
|
Removed patches:
|
|
|
|
test.patch
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Again using <filename>yocto-kernel patch list</filename>
|
|
|
|
we can verify that it was in fact removed:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-kernel patch list myarm
|
|
|
|
The current set of machine-specific patches for myarm is:
|
|
|
|
1) yocto-testmod.patch
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
In a completely similar way, we can use
|
|
|
|
the <filename>yocto-kernel config add</filename>
|
|
|
|
sub-command to add one or more kernel config item
|
|
|
|
settings to a BSP. The following commands add a couple
|
|
|
|
of config items to the 'myarm' BSP:
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-kernel config add myarm CONFIG_MISC_DEVICES=y
|
|
|
|
Added items:
|
|
|
|
CONFIG_MISC_DEVICES=y
|
|
|
|
|
|
|
|
$ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y
|
|
|
|
Added items:
|
|
|
|
CONFIG_YOCTO_TESTMOD=y
|
|
|
|
</literallayout>
|
|
|
|
Note that though we added config items one by one
|
|
|
|
above, we could also add multiple configuration
|
|
|
|
settings at the same time if we wanted to.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Finally, we can list the config items now associated
|
|
|
|
with the BSP and see the config items we added along
|
|
|
|
with some others.
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
$ yocto-kernel config list myarm
|
|
|
|
The current set of machine-specific kernel config items for myarm is:
|
|
|
|
1) CONFIG_MISC_DEVICES=y
|
|
|
|
2) CONFIG_YOCTO_TESTMOD=y
|
|
|
|
</literallayout>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
Similarly, we can remove one or more config items using
|
|
|
|
<filename>yocto-kernel config rm</filename> in a manner
|
|
|
|
completely analogous to <filename>yocto-kernel patch
|
|
|
|
rm</filename>.
|
|
|
|
</para>
|
|
|
|
</section>
|
|
|
|
</section>
|
2010-11-04 20:01:19 +00:00
|
|
|
</chapter>
|