mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-09 17:39:31 +00:00
Code Issues Projects Releases Wiki Activity

documentation/bsp-guide/bsp.xml: Edits to the BSP Tools section

Browse Source 
I have scrubbed the new section for the BSP Tools.  Changes reflect
re-wordings, formatting, etc.

(From yocto-docs rev: c13d5a42665d256c6da6d663611291eef9617f1f)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2012-04-02 12:40:19 -06:00
committed by Richard Purdie
parent 0be0e3b350
commit 23e85906e0
1 changed files with 432 additions and 434 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/bsp-guide/bsp.xml
+432 -434
View File
@@ -754,454 +754,452 @@
You must eventually rebuild the image if you want to remove this restriction.
</note>
</section>
<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 &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
[-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
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 &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
[-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
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>
<section id='using-the-yocto-projects-bsp-tools'>
<title>Using the Yocto Project's BSP Tools</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.
The Yocto Project includes a couple of tools that enable
you to create a <link linkend='bsp-layers'>BSP layer</link>
from scratch and do basic configuration and maintenance
of the kernel without ever looking at a Yocto Project metadata file.
These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>,
respectively.
</para>
<para>
The following sections describe the common location and help features as well
as details for the <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>
tools.
</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'>
<section id='common-features'>
<title>Common Features</title>
<para>
Designed to have a command interface somewhat like
<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>, 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>
Both tools reside in the <filename>scripts/</filename> subdirectory
of the <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project
Files</ulink>.
Consequently, to use the scripts, you must <filename>source</filename> the
environment just as you would when invoking a build:
<literallayout class='monospaced'>
$ source oe-init-build-env [build_dir]
</literallayout>
</para>
<para>
The most immediately useful function is to get help on both tools.
The built-in help system makes it easy to drill down at
any time and view the syntax required for any specific command.
Simply enter the name of the command, or the command along with
<filename>help</filename> to display a list of the available sub-commands.
Here is an example:
<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 shows the detailed usage
for that sub-command:
<literallayout class='monospaced'>
$ yocto-bsp create
Usage:
Create a new Yocto BSP
usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
[-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
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:
<literallayout class='monospaced'>
$ yocto-bsp help create
NAME
yocto-bsp create - Create a new Yocto BSP
SYNOPSIS
yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
[-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
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>
Now that you know where these two commands reside and how to access information
on them, you should find it relatively straightforward to discover the commands
necessary to create a BSP and perform basic kernel maintainence on that BSP using
the tools.
The next sections provide a concrete starting point to expand on a few points that
might not be immediately obvious or that could use further explanation.
</para>
</section>
<section id='creating-a-new-bsp-layer-using-the-yocto-bsp-script'>
<title>Creating a new BSP Layer Using the yocto-bsp Script</title>
<para>
The <filename>yocto-bsp</filename> script creates a new
<link linkend='bsp-layers'>BSP layer</link> for any architecture supported
by the Yocto Project, as well as QEMU versions of the same.
The default mode of the script's operation is to prompt you for information needed
to generate the BSP layer.
For the current set of BSPs, the script prompts you for various important
parameters such as:
<itemizedlist>
<listitem><para>which kernel to use</para></listitem>
<listitem><para>which branch of that kernel to use (or re-use)</para></listitem>
<listitem><para>whether or not to use X, and if so, which drivers to use</para></listitem>
<listitem><para>whether to turn on SMP</para></listitem>
<listitem><para>whether the BSP has a keyboard</para></listitem>
<listitem><para>whether the BSP has a touchscreen</para></listitem>
<listitem><para>any remaining configurable items associated with the BSP</para></listitem>
</itemizedlist>
</para>
<para>
You use the <filename>yocto-bsp create</filename> sub-command to create
a new BSP layer.
This command requires you to specify a particular architecture on which to
base the BSP.
Assuming you have sourced the environment, you can use the
<filename>yocto-bsp list karch</filename> sub-command to list the
architectures available for BSP creation as follows:
<literallayout class='monospaced'>
$ yocto-bsp list karch
Architectures available:
arm
powerpc
i386
mips
x86_64
qemu
</literallayout>
</para>
<para>
The remainder of this section presents an example that uses
<filename>myarm</filename> as the machine name and <filename>qemu</filename>
as the machine architecture.
Of the available architectures, <filename>qemu</filename> is the only architecture
that causes the script to prompt you further for an actual architecture.
In every other way, this architecture is representative of how creating a BSP for
a 'real' machine would work.
The reason the example uses this architecture is because it is an emulated architecture
and can easily be followed without requireing actual hardware.
</para>
<para>
As the <filename>yocto-bsp create</filename> command runs, default values for
the prompts appear in brackets.
Pressing enter without supplying anything on the command line or pressing enter
and providing an invalid response causes the script to accept the default value.
</para>
<para>
Following is the complete example:
<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/cedartrailbsp (copy).xml
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>
Let's take a closer look at the example now:
<orderedlist>
<listitem><para>For the <filename>qemu</filename> architecture,
the script first prompts you for which emulated architecture to use.
In the example, we use the <filename>arm</filename> architecture.
</para></listitem>
<listitem><para>The script then prompts you for the kernel.
The default kernel is 3.2 and is acceptable.
So, the example accepts the default.
If you enter 'n', the script prompts you to further enter the kernel
you do want to use (e.g. 3.0, 3.2_preempt-rt, etc.).</para></listitem>
<listitem><para>Next, the script asks whether you would like to have a new
branch created especially for your BSPin the local
<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>
Git repository .
If not, then the script re-uses an existing branch.</para>
<para>In this example, the default (or 'yes') is accepted.
Thus, a new branch is created for the BSP rather than using a common, shared
branch.
The new branch is the branch committed to for any patches you might later add.
The reason a new branch is the default is that typically
new BSPs do require BSP-specific patches.
The tool thus assumes that most of time a new branch is required.
<note>In the current implementation, creation or re-use of a branch does
not actually matter.
The reason is because the generated BSPs assume that patches and
configurations live in recipe-space, which is something that can be done
with or without a dedicated branch.
Generated BSPs, however, are different.
This difference becomes significant once the tool's 'publish' functionality
is implemented.</note></para></listitem>
<listitem><para>Regardless of which choice is made in the previous step,
you are now given the opportunity to select a particular machine branch on
which to base your new BSP-specific machine branch on
(or to re-use if you had elected to not create a new branch).
Because this example is generating an <filename>arm</filename> BSP, the example
uses <filename>#3</filename> at the prompt, which selects the arm-versatile branch.
</para></listitem>
<listitem><para>The remainder of the prompts are routine.
Defaults are accepted for each.</para></listitem>
<listitem><para>By default, the script creates the new BSP Layer in the
<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project
Build Directory</ulink>.</para></listitem>
</orderedlist>
</para>
<para>
Once the BSP Layer is created, you must add it to your
<filename>bblayers.conf</filename> file.
Here is an example:
<literallayout class='monospaced'>
BBLAYERS = " \
/usr/local/src/yocto/meta \
/usr/local/src/yocto/meta-yocto \
/usr/local/src/yocto/meta-myarm \
"
</literallayout>
</para>
</literallayout>
Adding the layer to this file allows the build system to build the BSP and
the <filename>yocto-kernel</filename> tool to be able to find the layer and
other metadata it needs on which to operate.
</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.
<section id='managing-kernel-patches-and-config-items-with-yocto-kernel'>
<title>Managing Kernel Patches and Config Items with yocto-kernel</title>
usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
<para>
Assuming you have created a Yocto Project
<link linkend='bsp-layers'>BSP Layer</link> using
<link linkend='creating-a-new-bsp-layer-using-the-yocto-bsp-script'>
<filename>yocto-bsp</filename></link> and you added it to your
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
variable in the <filename>bblayers.conf</filename> file, you can now use
the <filename>yocto-kernel</filename> script to add patches and configuration
items to the BSP's kernel.
</para>
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
<para>
The <filename>yocto-kernel</filename> script allows you to add, remove, and list patches
and kernel config settings to a Yocto Project BSP's kernel
<filename>.bbappend</filename> file.
All you need to do is use the appropriate sub-command.
Recall that the easiest way to see exactly what sub-commands are available
is to use the <filename>yocto-kernel</filename> built-in help as follows:
<literallayout class='monospaced'>
$ yocto-kernel
Usage:
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
Modify and list Yocto BSP kernel config items and patches.
$ 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
usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
$ 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>
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 you to add a
patch to a BSP.
The following example adds two patches to the <filename>myarm</filename> 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>Although the previous example adds patches one at a time, it is possible
to add multiple patches at the same time.</note>
</para>
<para>
You can verify patches have been added by using the
<filename>yocto-kernel patch list</filename> sub-command.
Here is an example:
<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>
You can also use the <filename>yocto-kernel</filename> script to
remove a patch using the <filename>yocto-kernel patch rm</filename> sub-command.
Here is an example:
<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 the <filename>yocto-kernel patch list</filename> sub-command,
you can verify that the patch 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, you 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
<filename>myarm</filename> 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>Although the previous example adds config items one at a time, it is possible
to add multiple config items at the same time.</note>
</para>
<para>
You can list the config items now associated with the BSP.
Doing so shows you the config items you added as well as others associated
with the BSP:
<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>
Finally, you can remove one or more config items using the
<filename>yocto-kernel config rm</filename> sub-command in a manner
completely analogous to <filename>yocto-kernel patch rm</filename>.
</para>
</section>
</section>
</chapter>