You create this file in your custom layer.
You also name it accordingly based on the linux-yocto recipe
you are using.
For example, if you are modifying the
meta/recipes-kernel/linux/linux-yocto_4.4.bb
recipe, the append file will typically be located as follows
within your custom layer:
your-layer
/recipes-kernel/linux/linux-yocto_4.4.bbappend
The append file should initially extend the
FILESPATH
search path by prepending the directory that contains your
files to the
FILESEXTRAPATHS
variable as follows:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
The path ${
THISDIR
}/${
PN
}
expands to "linux-yocto" in the current directory for this
example.
If you add any new files that modify the kernel recipe and you
have extended FILESPATH
as
described above, you must place the files in your layer in the
following area:
your-layer
/recipes-kernel/linux/linux-yocto/
As an example, consider the following append file
used by the BSPs in meta-yocto-bsp
:
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.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-yocto-bsp
layer upstream.
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"
This append file contains statements used to support
several BSPs that ship with the Yocto Project.
The file defines machines using the
COMPATIBLE_MACHINE
variable 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
appropriate kernel branch.
Although this particular example does not use it, the
KERNEL_FEATURES
variable could be used to enable features specific to
the kernel.
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
BSP.
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 the
SRC_URI
statement in the append file.
For example, suppose you had 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"
Another variable you can use in your kernel recipe append
file is the
FILESEXTRAPATHS
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.
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.