kernel-dev: Updated 4.4 to 4.12 for kernel example in layer

(From yocto-docs rev: ba8dd3676e3800b8356b7de948ceeb6e4cba4bbf)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2017-09-20 08:05:07 -07:00
committed by Richard Purdie
parent 4db9f48854
commit 46d9bd0076

View File

@@ -563,11 +563,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_4.4.bb</filename>
<filename>meta/recipes-kernel/linux/linux-yocto_4.12.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_4.4.bbappend
<replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_4.12.bbappend
</literallayout>
The append file should initially extend the
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
@@ -598,7 +598,7 @@
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
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend
</literallayout>
The following listing shows the file.
Be aware that the actual commit ID strings in this
@@ -615,11 +615,12 @@
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"
SRCREV_machine_genericx86 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
SRCREV_machine_genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
SRCREV_machine_edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
SRCREV_machine_beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
SRCREV_machine_mpc8315e-rdb ?= "2d1d010240846d7bff15d1fcc0cb6eb8a22fc78a"
COMPATIBLE_MACHINE_genericx86 = "genericx86"
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -627,11 +628,11 @@
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"
LINUX_VERSION_genericx86 = "4.12.7"
LINUX_VERSION_genericx86-64 = "4.12.7"
LINUX_VERSION_edgerouter = "4.12.10"
LINUX_VERSION_beaglebone = "4.12.10"
LINUX_VERSION_mpc8315e-rdb = "4.12.10"
</literallayout>
This append file contains statements used to support
several BSPs that ship with the Yocto Project.
@@ -662,8 +663,8 @@
<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.
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.
@@ -671,7 +672,8 @@
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
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>
@@ -717,25 +719,31 @@
<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.
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.
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>