You can find these files in the BSP Layer at:
meta-<bsp_name>/recipes-kernel/linux/linux-yocto_*.bbappend
These files append your specific changes to the main kernel recipe you are using.
For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the
Source Directory
at meta/recipes-kernel/linux
.
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 meta-<bsp_name>/recipes-kernel/linux
directory).
Suppose you are using the linux-yocto_3.4.bb
recipe to build
the kernel.
In other words, you have selected the kernel in your
<bsp_name>.conf
file by adding these types
of statements:
PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" PREFERRED_VERSION_linux-yocto = "3.4%"
PREFERRED_PROVIDER
statement does not appear in the
<bsp_name>.conf
file.
You would use the linux-yocto_3.4.bbappend
file to append
specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
As an example, look at the existing Crown Bay BSP. The append file used is:
meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
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 meta-intel
Git source repository.
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" COMPATIBLE_MACHINE_crownbay = "crownbay" KMACHINE_crownbay = "crownbay" KBRANCH_crownbay = "standard/crownbay" COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd" KMACHINE_crownbay-noemgd = "crownbay" KBRANCH_crownbay-noemgd = "standard/crownbay" SRCREV_machine_pn-linux-yocto_crownbay ?= "449f7f520350700858f21a5554b81cc8ad23267d" SRCREV_meta_pn-linux-yocto_crownbay ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac" SRCREV_emgd_pn-linux-yocto_crownbay ?= "86643bdd8cbad616a161ab91f51108cf0da827bc" SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "449f7f520350700858f21a5554b81cc8ad23267d" SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac" KSRC_linux_yocto_3_4 ?= "git.yoctoproject.org/linux-yocto-3.4.git" SRC_URI_crownbay = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta,emgd-1.14;name=machine,meta,emgd" SRC_URI_crownbay-noemgd = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
This append file contains statements used to support the Crown Bay BSP for both
Intel® EMGD and the VESA graphics.
The build process, in this case, recognizes and uses only the statements that
apply to the defined machine name - crownbay
in this case.
So, the applicable statements in the linux-yocto_3.4.bbappend
file are follows:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" COMPATIBLE_MACHINE_crownbay = "crownbay" KMACHINE_crownbay = "crownbay" KBRANCH_crownbay = "standard/crownbay" SRCREV_machine_pn-linux-yocto_crownbay ?= "449f7f520350700858f21a5554b81cc8ad23267d" SRCREV_meta_pn-linux-yocto_crownbay ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac" SRCREV_emgd_pn-linux-yocto_crownbay ?= "86643bdd8cbad616a161ab91f51108cf0da827bc"
The append file defines crownbay
as the
COMPATIBLE_MACHINE
and uses the
KMACHINE
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
KBRANCH
variable
to ensure the build process uses the standard/default/crownbay
kernel branch.
Finally, the append file points to specific commits in the
Source Directory Git
repository and the meta
Git repository branches to identify the
exact kernel needed to build the Crown Bay BSP.
crownbay
, a specific commit is also needed to point
to the branch that supports EMGD graphics.
At a minimum, every BSP points to the
machine
and meta
commits.
One thing missing in this particular BSP, which you will typically need when
developing a BSP, is the kernel configuration file (.config
) 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 a
SRC_URI
statement in the append file.
For example, suppose you had a some configuration options in a file called
network_configs.cfg
.
You can place that file inside a directory named /linux-yocto
and then add
a SRC_URI
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.
SRC_URI += "file://network_configs.cfg"
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 SRC_URI
statement like the following in your append file:
SRC_URI += "file://myconfig.cfg \ file://eth.cfg \ file://gfx.cfg"
The FILESEXTRAPATHS
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 SRC_URI
.
The FILESEXTRAPATHS
variable enables the build process to
find those configuration files.
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 meta
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
meta
branch for your BSP.
The configuration options will likely end up in that location anyway if the BSP gets
added to the Yocto Project.
In general, however, the Yocto Project maintainers take care of moving the
SRC_URI
-specified
configuration options to the kernel's meta
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.