bsp-guide, kernel-dev: Updates to how kernel metadata is found
Fixes [YOCTO #10946] There was insufficient information in the combination of the BSP Guide and the Kernel Development Manual on just how to locate and use kernel metadata. * bsp-guide - Removed the detailed append file example for the kernel recipe. This is moved now to the chapter in the kernel manual that describes append files. * kernel-dev - Placed the example from the BSP Guide into the section that describes kernel append files. Cleaned up some terminology issues throughout chapter 3. Added information about how BitBake picks up kernel metadata when the metadata is in a hierarchical directory and not just a simple *.scc file. (From yocto-docs rev: 1048acb7127e77ca9c1f524a208fe25344fcb57c) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
730617f8d0
commit
ed0d609c7c
|
|
@ -376,6 +376,7 @@
|
|||
|
||||
<section id="bsp-filelayout-readme">
|
||||
<title>README File</title>
|
||||
|
||||
<para>
|
||||
You can find this file in the BSP Layer at:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -400,6 +401,7 @@
|
|||
|
||||
<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'>
|
||||
|
|
@ -428,6 +430,7 @@
|
|||
|
||||
<section id="bsp-filelayout-binary">
|
||||
<title>Pre-built User Binaries</title>
|
||||
|
||||
<para>
|
||||
You can find these files in the BSP Layer at:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -461,6 +464,7 @@
|
|||
|
||||
<section id='bsp-filelayout-layer'>
|
||||
<title>Layer Configuration File</title>
|
||||
|
||||
<para>
|
||||
You can find this file in the BSP Layer at:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -526,6 +530,7 @@
|
|||
|
||||
<section id="bsp-filelayout-machine">
|
||||
<title>Hardware Configuration Options</title>
|
||||
|
||||
<para>
|
||||
You can find these files in the BSP Layer at:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -585,6 +590,7 @@
|
|||
|
||||
<section id='bsp-filelayout-misc-recipes'>
|
||||
<title>Miscellaneous BSP-Specific Recipe Files</title>
|
||||
|
||||
<para>
|
||||
You can find these files in the BSP Layer at:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -627,6 +633,7 @@
|
|||
|
||||
<section id='bsp-filelayout-recipes-graphics'>
|
||||
<title>Display Support Files</title>
|
||||
|
||||
<para>
|
||||
You can find these files in the BSP Layer at:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -644,6 +651,7 @@
|
|||
|
||||
<section id='bsp-filelayout-kernel'>
|
||||
<title>Linux Kernel Configuration</title>
|
||||
|
||||
<para>
|
||||
You can find these files in the BSP Layer at:
|
||||
<literallayout class='monospaced'>
|
||||
|
|
@ -652,29 +660,39 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
These files append your specific changes to the main kernel recipe you are using.
|
||||
These files append machine-specific changes to the main
|
||||
kernel recipe you are using.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the
|
||||
For your BSP, you typically want to use an existing Yocto
|
||||
Project kernel recipe found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
at <filename>meta/recipes-kernel/linux</filename>.
|
||||
You can append your specific changes to the kernel recipe by using a
|
||||
similarly named append file, which is located in the BSP Layer (e.g.
|
||||
the <filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory).
|
||||
You can append machine-specific changes to the kernel recipe
|
||||
by using a similarly named append file, which is located in
|
||||
the BSP Layer for your target device (e.g. the
|
||||
<filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Suppose you are using the <filename>linux-yocto_4.4.bb</filename> recipe to build
|
||||
the kernel.
|
||||
Suppose you are using the <filename>linux-yocto_4.4.bb</filename>
|
||||
recipe to build the kernel.
|
||||
In other words, you have selected the kernel in your
|
||||
<replaceable>bsp_name</replaceable><filename>.conf</filename> file by adding these types
|
||||
of statements:
|
||||
<replaceable>bsp_name</replaceable><filename>.conf</filename>
|
||||
file by adding
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink>
|
||||
and
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></ulink>
|
||||
statements as follows:
|
||||
<literallayout class='monospaced'>
|
||||
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
|
||||
PREFERRED_VERSION_linux-yocto ?= "4.4%"
|
||||
</literallayout>
|
||||
<note>
|
||||
When the preferred provider is assumed by default, the
|
||||
<filename>PREFERRED_PROVIDER</filename> statement does not appear in the
|
||||
<filename>PREFERRED_PROVIDER</filename>
|
||||
statement does not appear in the
|
||||
<replaceable>bsp_name</replaceable><filename>.conf</filename> file.
|
||||
</note>
|
||||
You would use the <filename>linux-yocto_4.4.bbappend</filename>
|
||||
|
|
@ -683,146 +701,12 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
As an example, consider the following append file
|
||||
used by the BSPs in <filename>meta-yocto-bsp</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend
|
||||
</literallayout>
|
||||
The following listing shows the file.
|
||||
Be aware that the actual commit ID strings in this
|
||||
example listing might be different than the actual strings
|
||||
in the file from the <filename>meta-yocto-bsp</filename>
|
||||
layer upstream.
|
||||
<literallayout class='monospaced'>
|
||||
KBRANCH_genericx86 = "standard/base"
|
||||
KBRANCH_genericx86-64 = "standard/base"
|
||||
|
||||
KMACHINE_genericx86 ?= "common-pc"
|
||||
KMACHINE_genericx86-64 ?= "common-pc-64"
|
||||
KBRANCH_edgerouter = "standard/edgerouter"
|
||||
KBRANCH_beaglebone = "standard/beaglebone"
|
||||
KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
|
||||
|
||||
SRCREV_machine_genericx86 ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
|
||||
SRCREV_machine_genericx86-64 ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
|
||||
SRCREV_machine_edgerouter ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
|
||||
SRCREV_machine_beaglebone ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "df00877ef9387b38b9601c82db57de2a1b23ce53"
|
||||
|
||||
COMPATIBLE_MACHINE_genericx86 = "genericx86"
|
||||
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
|
||||
COMPATIBLE_MACHINE_edgerouter = "edgerouter"
|
||||
COMPATIBLE_MACHINE_beaglebone = "beaglebone"
|
||||
COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
|
||||
|
||||
LINUX_VERSION_genericx86 = "4.4.3"
|
||||
LINUX_VERSION_genericx86-64 = "4.4.3"
|
||||
</literallayout>
|
||||
This append file contains statements used to support
|
||||
several BSPs that ship with the Yocto Project.
|
||||
The file defines machines using the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
|
||||
variable and uses the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>
|
||||
variable to ensure the machine name used by the OpenEmbedded
|
||||
build system maps to the machine name used by the Linux Yocto
|
||||
kernel.
|
||||
The file also uses the optional
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink>
|
||||
variable to ensure the build process uses the
|
||||
appropriate kernel branch.
|
||||
You can find more information on what your append file
|
||||
should contain in the
|
||||
"<ulink url='&YOCTO_DOCS_KERNEL_URL;#creating-the-append-file'>Creating the Append File</ulink>"
|
||||
section in the Yocto Project Linux Kernel Development
|
||||
Manual.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Although this particular example does not use it, the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
|
||||
variable could be used to enable features specific to
|
||||
the kernel.
|
||||
The append file points to specific commits in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
Git repository and the <filename>meta</filename> Git repository
|
||||
branches to identify the exact kernel needed to build the
|
||||
BSP.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
One thing missing in this particular BSP, which you will
|
||||
typically need when developing a BSP, is the kernel configuration
|
||||
file (<filename>.config</filename>) for your BSP.
|
||||
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 kernel's append file and having the same
|
||||
name as the kernel's main recipe file.
|
||||
With all these conditions met, simply reference those files in the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||||
statement in the append file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example, suppose you had some configuration options
|
||||
in a file called <filename>network_configs.cfg</filename>.
|
||||
You can place that file inside a directory named
|
||||
<filename>linux-yocto</filename> and then add
|
||||
a <filename>SRC_URI</filename> statement such as the
|
||||
following to the append file.
|
||||
When the OpenEmbedded build system builds the kernel, the
|
||||
configuration options are picked up and applied.
|
||||
<literallayout class='monospaced'>
|
||||
SRC_URI += "file://network_configs.cfg"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To group related configurations into multiple files, you
|
||||
perform a similar procedure.
|
||||
Here is an example that groups separate configurations
|
||||
specifically for Ethernet and graphics into their own
|
||||
files and adds the configurations by using a
|
||||
<filename>SRC_URI</filename> statement like the following
|
||||
in your append file:
|
||||
<literallayout class='monospaced'>
|
||||
SRC_URI += "file://myconfig.cfg \
|
||||
file://eth.cfg \
|
||||
file://gfx.cfg"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another variable you can use in your kernel recipe append
|
||||
file is the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||||
variable.
|
||||
When you use this statement, you are extending the locations
|
||||
used by the OpenEmbedded system to look for files and
|
||||
patches as the recipe is processed.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Other methods exist to accomplish grouping and defining configuration options.
|
||||
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
|
||||
<filename>meta</filename> branch for your BSP.
|
||||
The configuration options will likely end up in that location anyway if the BSP gets
|
||||
added to the Yocto Project.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In general, however, the Yocto Project maintainers take care of moving the
|
||||
<filename>SRC_URI</filename>-specified
|
||||
configuration options to the kernel's <filename>meta</filename> branch.
|
||||
Not only is it easier for BSP developers to not have to worry about putting those
|
||||
configurations in the branch, but having the maintainers do it allows them to apply
|
||||
'global' knowledge about the kinds of common configuration options multiple BSPs in
|
||||
the tree are typically using.
|
||||
This allows for promotion of common configurations into common features.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -524,22 +524,66 @@
|
|||
<title>BSP Descriptions</title>
|
||||
|
||||
<para>
|
||||
BSP descriptions combine kernel types with hardware-specific
|
||||
features.
|
||||
The hardware-specific portion is typically defined
|
||||
independently, and then aggregated with each supported kernel
|
||||
type.
|
||||
Consider this simple BSP description that supports the
|
||||
<replaceable>mybsp</replaceable> machine:
|
||||
BSP descriptions (i.e. <filename>*.scc</filename> files)
|
||||
combine kernel types with hardware-specific features.
|
||||
The hardware-specific Metadata is typically defined
|
||||
independently in the BSP layer, and then aggregated with each
|
||||
supported kernel type.
|
||||
<note>
|
||||
For BSPs supported by the Yocto Project, the BSP description
|
||||
files are located in the <filename>bsp</filename> directory
|
||||
of the <filename>yocto-kernel-cache</filename> repository
|
||||
organized under the "Yocto Linux Kernel" heading in the
|
||||
<ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Yocto Project Source Repositories</ulink>.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This section provides a BSP description structural overview along
|
||||
with aggregation concepts as well as a detailed example using
|
||||
a BSP supported by the Yocto Project (i.e. Minnow Board).
|
||||
</para>
|
||||
|
||||
<section id='bsp-description-file-overview'>
|
||||
<title>Overview</title>
|
||||
|
||||
<para>
|
||||
For simplicity, consider the following top-level BSP
|
||||
description file.
|
||||
Top-level BSP descriptions files employ both a structure
|
||||
and naming convention for consistency.
|
||||
The naming convention for the file is as follows:
|
||||
<literallayout class='monospaced'>
|
||||
<replaceable>bsp_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
|
||||
</literallayout>
|
||||
Here are some example top-level BSP filenames for the
|
||||
Minnow Board BSP, which is supported by the Yocto Project:
|
||||
<literallayout class='monospaced'>
|
||||
minnow-standard.scc
|
||||
minnow-preempt-rt.scc
|
||||
minnow-tiny.scc
|
||||
</literallayout>
|
||||
Each file uses the BSP name followed by the kernel type.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
is simple BSP description file whose name has the
|
||||
form
|
||||
<replaceable>mybsp</replaceable><filename>-standard</filename>
|
||||
and supports the <replaceable>mybsp</replaceable> machine using
|
||||
a standard kernel:
|
||||
<literallayout class='monospaced'>
|
||||
<replaceable>mybsp</replaceable>.scc:
|
||||
define KMACHINE <replaceable>mybsp</replaceable>
|
||||
define KTYPE standard
|
||||
define KARCH i386
|
||||
|
||||
kconf <replaceable>mybsp</replaceable>.cfg
|
||||
include ktypes/standard
|
||||
|
||||
include <replaceable>mybsp</replaceable>.scc
|
||||
|
||||
kconf hardware <replaceable>mybsp</replaceable>-<replaceable>extra</replaceable>.cfg
|
||||
</literallayout>
|
||||
Every BSP description should define the
|
||||
Every top-level BSP description file should define the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>,
|
||||
and <ulink url='&YOCTO_DOCS_REF_URL;#var-KARCH'><filename>KARCH</filename></ulink>
|
||||
|
|
@ -553,8 +597,8 @@
|
|||
|
||||
<para>
|
||||
Be aware that a hard link between the
|
||||
<filename>KTYPE</filename> variable and a kernel type
|
||||
description file does not exist.
|
||||
<filename>KTYPE</filename> variable and a kernel type description
|
||||
file does not exist.
|
||||
Thus, if you do not have kernel types defined in your kernel
|
||||
Metadata, you only need to ensure that the kernel recipe's
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></ulink>
|
||||
|
|
@ -567,39 +611,26 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
If you did want to separate your kernel policy from your
|
||||
hardware configuration, you could do so by specifying a kernel
|
||||
type, such as "standard" and including that description file
|
||||
in the BSP description file.
|
||||
To separate your kernel policy from your hardware configuration,
|
||||
you include a kernel type (<filename>ktype</filename>), such as
|
||||
"standard".
|
||||
In the previous example, this is done using the following:
|
||||
<literallayout class='monospaced'>
|
||||
include ktypes/standard
|
||||
</literallayout>
|
||||
In the previous example, <filename>ktypes/standard.scc</filename>
|
||||
aggregates all the configuration fragments, patches, and
|
||||
features that make up your standard kernel policy.
|
||||
See the "<link linkend='kernel-types'>Kernel Types</link>" section
|
||||
for more information.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You might also have multiple hardware configurations that you
|
||||
aggregate into a single hardware description file that you
|
||||
could include in the BSP description file, rather than referencing
|
||||
a single <filename>.cfg</filename> file.
|
||||
Consider the following:
|
||||
To aggregate common configurations and features specific to the
|
||||
kernel for <replaceable>mybsp</replaceable>, use the following:
|
||||
<literallayout class='monospaced'>
|
||||
<replaceable>mybsp</replaceable>.scc:
|
||||
define KMACHINE mybsp
|
||||
define KTYPE standard
|
||||
define KARCH i386
|
||||
|
||||
include standard.scc
|
||||
include <replaceable>mybsp</replaceable>-hw.scc
|
||||
include <replaceable>mybsp</replaceable>.scc
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the above example, <filename>standard.scc</filename>
|
||||
aggregates all the configuration fragments, patches, and
|
||||
features that make up your standard kernel policy whereas
|
||||
<replaceable>mybsp</replaceable><filename>-hw.scc</filename>
|
||||
aggregates all those necessary
|
||||
to support the hardware available on the
|
||||
<replaceable>mybsp</replaceable> machine.
|
||||
For information on how to break a complete
|
||||
<filename>.config</filename> file into the various
|
||||
configuration fragments, see the
|
||||
|
|
@ -607,13 +638,29 @@
|
|||
section.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, if you have any configurations specific to the
|
||||
hardware that are not in a <filename>*.scc</filename> file,
|
||||
you can include them as follows:
|
||||
<literallayout class='monospaced'>
|
||||
kconf hardware <replaceable>mybsp</replaceable>-<replaceable>extra</replaceable>.cfg
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='bsp-description-file-example-minnow'>
|
||||
<title>Example</title>
|
||||
|
||||
<para>
|
||||
Many real-world examples are more complex.
|
||||
Like any other <filename>.scc</filename> file, BSP
|
||||
descriptions can aggregate features.
|
||||
Consider the Minnow BSP definition from the
|
||||
<filename>linux-yocto-3.19</filename>
|
||||
Git repository:
|
||||
<filename>linux-yocto-4.4</filename> in the
|
||||
Yocto Project
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
|
||||
(i.e.
|
||||
<filename>yocto-kernel-cache/bsp/minnow</filename>):
|
||||
<literallayout class='monospaced'>
|
||||
minnow.scc:
|
||||
include cfg/x86.scc
|
||||
|
|
@ -626,10 +673,10 @@
|
|||
include features/usb/usb-gadgets.scc
|
||||
include features/usb/touchscreen-composite.scc
|
||||
include cfg/timer/hpet.scc
|
||||
include cfg/timer/rtc.scc
|
||||
include features/leds/leds.scc
|
||||
include features/spi/spidev.scc
|
||||
include features/i2c/i2cdev.scc
|
||||
include features/mei/mei-txe.scc
|
||||
|
||||
# Earlyprintk and port debug requires 8250
|
||||
kconf hardware cfg/8250.cfg
|
||||
|
|
@ -646,7 +693,8 @@
|
|||
BSP as well as several more general configuration
|
||||
fragments and features enabling hardware found on the
|
||||
machine.
|
||||
This description file is then included in each of the three
|
||||
This <filename>minnow.scc</filename> description file is then
|
||||
included in each of the three
|
||||
"minnow" description files for the supported kernel types
|
||||
(i.e. "standard", "preempt-rt", and "tiny").
|
||||
Consider the "minnow" description for the "standard" kernel
|
||||
|
|
@ -680,13 +728,14 @@
|
|||
</literallayout>
|
||||
The <filename>include</filename> command midway through the file
|
||||
includes the <filename>minnow.scc</filename> description that
|
||||
defines all hardware enablements for the BSP that is common to all
|
||||
kernel types.
|
||||
defines all enabled hardware for the BSP that is common to
|
||||
all kernel types.
|
||||
Using this command significantly reduces duplication.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Now consider the "minnow" description for the "tiny" kernel type:
|
||||
Now consider the "minnow" description for the "tiny" kernel
|
||||
type:
|
||||
<literallayout class='monospaced'>
|
||||
minnow-tiny.scc:
|
||||
define KMACHINE minnow
|
||||
|
|
@ -700,9 +749,10 @@
|
|||
As you might expect, the "tiny" description includes quite a
|
||||
bit less.
|
||||
In fact, it includes only the minimal policy defined by the
|
||||
"tiny" kernel type and the hardware-specific configuration required
|
||||
for booting the machine along with the most basic functionality of
|
||||
the system as defined in the base "minnow" description file.
|
||||
"tiny" kernel type and the hardware-specific configuration
|
||||
required for booting the machine along with the most basic
|
||||
functionality of the system as defined in the base "minnow"
|
||||
description file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -714,6 +764,7 @@
|
|||
</para>
|
||||
</section>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='kernel-metadata-location'>
|
||||
<title>Kernel Metadata Location</title>
|
||||
|
|
@ -795,6 +846,18 @@
|
|||
value when changing the content of files not explicitly listed
|
||||
in the <filename>SRC_URI</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the kernel Metadata is in a layer, you cannot simply list the
|
||||
<filename>*.scc</filename> in the <filename>SRC_URI</filename>
|
||||
statement.
|
||||
You need to use the following form from your kernel append file:
|
||||
<literallayout class='monospaced'>
|
||||
SRC_URI_append_<replaceable>myplatform</replaceable> = " \
|
||||
file://<replaceable>myplatform</replaceable>;type=kmeta;destsuffix=<replaceable>myplatform</replaceable> \
|
||||
"
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id='metadata-outside-the-recipe-space'>
|
||||
|
|
@ -817,7 +880,8 @@
|
|||
<filename>${KMETA}</filename>, in this context, is simply used to
|
||||
name the directory into which the Git fetcher places the Metadata.
|
||||
This behavior is no different than any multi-repository
|
||||
<filename>SRC_URI</filename> statement used in a recipe.
|
||||
<filename>SRC_URI</filename> statement used in a recipe (e.g.
|
||||
see the previous section).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
|||
|
|
@ -84,11 +84,11 @@
|
|||
You also name it accordingly based on the linux-yocto recipe
|
||||
you are using.
|
||||
For example, if you are modifying the
|
||||
<filename>meta/recipes-kernel/linux/linux-yocto_3.19.bb</filename>
|
||||
<filename>meta/recipes-kernel/linux/linux-yocto_4.4.bb</filename>
|
||||
recipe, the append file will typically be located as follows
|
||||
within your custom layer:
|
||||
<literallayout class='monospaced'>
|
||||
<replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.19.bbappend
|
||||
<replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_4.4.bbappend
|
||||
</literallayout>
|
||||
The append file should initially extend the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
|
||||
|
|
@ -114,6 +114,151 @@
|
|||
<ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As an example, consider the following append file
|
||||
used by the BSPs in <filename>meta-yocto-bsp</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend
|
||||
</literallayout>
|
||||
The following listing shows the file.
|
||||
Be aware that the actual commit ID strings in this
|
||||
example listing might be different than the actual strings
|
||||
in the file from the <filename>meta-yocto-bsp</filename>
|
||||
layer upstream.
|
||||
<literallayout class='monospaced'>
|
||||
KBRANCH_genericx86 = "standard/base"
|
||||
KBRANCH_genericx86-64 = "standard/base"
|
||||
|
||||
KMACHINE_genericx86 ?= "common-pc"
|
||||
KMACHINE_genericx86-64 ?= "common-pc-64"
|
||||
KBRANCH_edgerouter = "standard/edgerouter"
|
||||
KBRANCH_beaglebone = "standard/beaglebone"
|
||||
KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
|
||||
|
||||
SRCREV_machine_genericx86 ?= "ad8b1d659ddd2699ebf7d50ef9de8940b157bfc2"
|
||||
SRCREV_machine_genericx86-64 ?= "ad8b1d659ddd2699ebf7d50ef9de8940b157bfc2"
|
||||
SRCREV_machine_edgerouter ?= "cebe1ad56aebd89e0de29412e19433fb441bf13c"
|
||||
SRCREV_machine_beaglebone ?= "cebe1ad56aebd89e0de29412e19433fb441bf13c"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "06c0dbdcba374ca7f92a53d69292d6bb7bc9b0f3"
|
||||
|
||||
COMPATIBLE_MACHINE_genericx86 = "genericx86"
|
||||
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
|
||||
COMPATIBLE_MACHINE_edgerouter = "edgerouter"
|
||||
COMPATIBLE_MACHINE_beaglebone = "beaglebone"
|
||||
COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
|
||||
|
||||
LINUX_VERSION_genericx86 = "4.4.41"
|
||||
LINUX_VERSION_genericx86-64 = "4.4.41"
|
||||
LINUX_VERSION_edgerouter = "4.4.53"
|
||||
LINUX_VERSION_beaglebone = "4.4.53"
|
||||
LINUX_VERSION_mpc8315e-rdb = "4.4.53"
|
||||
</literallayout>
|
||||
This append file contains statements used to support
|
||||
several BSPs that ship with the Yocto Project.
|
||||
The file defines machines using the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
|
||||
variable and uses the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>
|
||||
variable to ensure the machine name used by the OpenEmbedded
|
||||
build system maps to the machine name used by the Linux Yocto
|
||||
kernel.
|
||||
The file also uses the optional
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink>
|
||||
variable to ensure the build process uses the
|
||||
appropriate kernel branch.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Although this particular example does not use it, the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
|
||||
variable could be used to enable features specific to
|
||||
the kernel.
|
||||
The append file points to specific commits in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
Git repository and the <filename>meta</filename> Git repository
|
||||
branches to identify the exact kernel needed to build the
|
||||
BSP.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
One thing missing in this particular BSP, which you will
|
||||
typically need when developing a BSP, is the kernel configuration
|
||||
file (<filename>.config</filename>) for your BSP.
|
||||
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 kernel's append file and having the same
|
||||
name as the kernel's main recipe file.
|
||||
With all these conditions met, simply reference those files in the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||||
statement in the append file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For example, suppose you had some configuration options
|
||||
in a file called <filename>network_configs.cfg</filename>.
|
||||
You can place that file inside a directory named
|
||||
<filename>linux-yocto</filename> and then add
|
||||
a <filename>SRC_URI</filename> statement such as the
|
||||
following to the append file.
|
||||
When the OpenEmbedded build system builds the kernel, the
|
||||
configuration options are picked up and applied.
|
||||
<literallayout class='monospaced'>
|
||||
SRC_URI += "file://network_configs.cfg"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To group related configurations into multiple files, you
|
||||
perform a similar procedure.
|
||||
Here is an example that groups separate configurations
|
||||
specifically for Ethernet and graphics into their own
|
||||
files and adds the configurations by using a
|
||||
<filename>SRC_URI</filename> statement like the following
|
||||
in your append file:
|
||||
<literallayout class='monospaced'>
|
||||
SRC_URI += "file://myconfig.cfg \
|
||||
file://eth.cfg \
|
||||
file://gfx.cfg"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another variable you can use in your kernel recipe append
|
||||
file is the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||||
variable.
|
||||
When you use this statement, you are extending the locations
|
||||
used by the OpenEmbedded system to look for files and
|
||||
patches as the recipe is processed.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
<para>
|
||||
Other methods exist to accomplish grouping and defining configuration options.
|
||||
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
|
||||
<filename>meta</filename> branch for your BSP.
|
||||
The configuration options will likely end up in that location anyway if the BSP gets
|
||||
added to the Yocto Project.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In general, however, the Yocto Project maintainers take care of moving the
|
||||
<filename>SRC_URI</filename>-specified
|
||||
configuration options to the kernel's <filename>meta</filename> branch.
|
||||
Not only is it easier for BSP developers to not have to worry about putting those
|
||||
configurations in the branch, but having the maintainers do it allows them to apply
|
||||
'global' knowledge about the kinds of common configuration options multiple BSPs in
|
||||
the tree are typically using.
|
||||
This allows for promotion of common configurations into common features.
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='applying-patches'>
|
||||
|
|
|
|||
Loading…
Reference in New Issue