2718 lines
139 KiB
XML
2718 lines
139 KiB
XML
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||
|
|
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||
|
|
|
||
|
|
<chapter id='kernel-dev-common'>
|
||
|
|
<title>Common Tasks</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
This chapter presents several common tasks you perform when you
|
||
|
|
work with the Yocto Project Linux kernel.
|
||
|
|
These tasks include preparing your host development system for
|
||
|
|
kernel development, preparing a layer, modifying an existing recipe,
|
||
|
|
patching the kernel, configuring the kernel, iterative development,
|
||
|
|
working with your own sources, and incorporating out-of-tree modules.
|
||
|
|
<note>
|
||
|
|
The examples presented in this chapter work with the Yocto Project
|
||
|
|
2.4 Release and forward.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<section id='preparing-the-build-host-to-work-on-the-kernel'>
|
||
|
|
<title>Preparing the Build Host to Work on the Kernel</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Before you can do any kernel development, you need to be
|
||
|
|
sure your build host is set up to use the Yocto Project.
|
||
|
|
For information on how to get set up, see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Setting Up to Use the Yocto Project</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks Manual.
|
||
|
|
Part of preparing the system is creating a local Git
|
||
|
|
repository of the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
|
||
|
|
(<filename>poky</filename>) on your system.
|
||
|
|
Follow the steps in the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository'>Cloning the <filename>poky</filename> Repository</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks Manual to set up your
|
||
|
|
Source Directory.
|
||
|
|
<note>
|
||
|
|
Be sure you check out the appropriate development branch or
|
||
|
|
you create your local branch by checking out a specific tag
|
||
|
|
to get the desired version of Yocto Project.
|
||
|
|
See the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking Out by Branch in Poky</ulink>"
|
||
|
|
and
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#checkout-out-by-tag-in-poky'>Checking Out by Tag in Poky</ulink>"
|
||
|
|
sections in the Yocto Project Development Tasks Manual for more
|
||
|
|
information.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Kernel development is best accomplished using
|
||
|
|
<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'><filename>devtool</filename></ulink>
|
||
|
|
and not through traditional kernel workflow methods.
|
||
|
|
The remainder of this section provides information for both
|
||
|
|
scenarios.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<section id='getting-ready-to-develop-using-devtool'>
|
||
|
|
<title>Getting Ready to Develop Using <filename>devtool</filename></title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Follow these steps to prepare to update the kernel image using
|
||
|
|
<filename>devtool</filename>.
|
||
|
|
Completing this procedure leaves you with a clean kernel image
|
||
|
|
and ready to make modifications as described in the
|
||
|
|
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
|
||
|
|
section:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Initialize the BitBake Environment:</emphasis>
|
||
|
|
Before building an extensible SDK, you need to
|
||
|
|
initialize the BitBake build environment by sourcing the
|
||
|
|
build environment script
|
||
|
|
(i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>oe-init-build-env</filename></ulink>):
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky
|
||
|
|
$ source oe-init-build-env
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
The previous commands assume the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>
|
||
|
|
(i.e. <filename>poky</filename>) have been cloned
|
||
|
|
using Git and the local repository is named
|
||
|
|
"poky".
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Prepare Your <filename>local.conf</filename> File:</emphasis>
|
||
|
|
By default, the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||
|
|
variable is set to "qemux86", which is fine if you are
|
||
|
|
building for the QEMU emulator in 32-bit mode.
|
||
|
|
However, if you are not, you need to set the
|
||
|
|
<filename>MACHINE</filename> variable appropriately in
|
||
|
|
your <filename>conf/local.conf</filename> file found in
|
||
|
|
the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
|
||
|
|
(i.e. <filename>~/poky/build</filename> in this
|
||
|
|
example).</para>
|
||
|
|
|
||
|
|
<para>Also, since you are preparing to work on the
|
||
|
|
kernel image, you need to set the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
|
||
|
|
variable to include kernel modules.</para>
|
||
|
|
|
||
|
|
<para>This example uses the default "qemux86" for the
|
||
|
|
<filename>MACHINE</filename> variable but needs to
|
||
|
|
add the "kernel-modules":
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create a Layer for Patches:</emphasis>
|
||
|
|
You need to create a layer to hold patches created
|
||
|
|
for the kernel image.
|
||
|
|
You can use the
|
||
|
|
<filename>bitbake-layers create-layer</filename>
|
||
|
|
command as follows:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake-layers create-layer ../../meta-mylayer
|
||
|
|
NOTE: Starting bitbake server...
|
||
|
|
Add your new layer with 'bitbake-layers add-layer ../../meta-mylayer'
|
||
|
|
$
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
For background information on working with
|
||
|
|
common and BSP layers, see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks
|
||
|
|
Manual and the
|
||
|
|
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
|
||
|
|
section in the Yocto Project Board Support (BSP)
|
||
|
|
Developer's Guide, respectively.
|
||
|
|
For information on how to use the
|
||
|
|
<filename>bitbake-layers create-layer</filename>
|
||
|
|
command, see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks
|
||
|
|
Manual.
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Inform the BitBake Build Environment About
|
||
|
|
Your Layer:</emphasis>
|
||
|
|
As directed when you created your layer, you need to
|
||
|
|
add the layer to the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
|
||
|
|
variable in the <filename>bblayers.conf</filename> file
|
||
|
|
as follows:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake-layers add-layer ../../meta-mylayer
|
||
|
|
NOTE: Starting bitbake server...
|
||
|
|
$
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Build the Extensible SDK:</emphasis>
|
||
|
|
Use BitBake to build the extensible SDK specifically
|
||
|
|
for use with images to be run using QEMU:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake core-image-minimal -c populate_sdk_ext
|
||
|
|
</literallayout>
|
||
|
|
Once the build finishes, you can find the SDK installer
|
||
|
|
file (i.e. <filename>*.sh</filename> file) in the
|
||
|
|
following directory:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
~/poky/build/tmp/deploy/sdk
|
||
|
|
</literallayout>
|
||
|
|
For this example, the installer file is named
|
||
|
|
<filename>poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-&DISTRO;.sh</filename>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Install the Extensible SDK:</emphasis>
|
||
|
|
Use the following command to install the SDK.
|
||
|
|
For this example, install the SDK in the default
|
||
|
|
<filename>~/poky_sdk</filename> directory:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build/tmp/deploy/sdk
|
||
|
|
$ ./poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-&DISTRO;.sh
|
||
|
|
Poky (Yocto Project Reference Distro) Extensible SDK installer version &DISTRO;
|
||
|
|
============================================================================
|
||
|
|
Enter target directory for SDK (default: ~/poky_sdk):
|
||
|
|
You are about to install the SDK to "/home/scottrif/poky_sdk". Proceed[Y/n]? Y
|
||
|
|
Extracting SDK......................................done
|
||
|
|
Setting it up...
|
||
|
|
Extracting buildtools...
|
||
|
|
Preparing build system...
|
||
|
|
Parsing recipes: 100% |#################################################################| Time: 0:00:52
|
||
|
|
Initializing tasks: 100% |############## ###############################################| Time: 0:00:04
|
||
|
|
Checking sstate mirror object availability: 100% |######################################| Time: 0:00:00
|
||
|
|
Parsing recipes: 100% |#################################################################| Time: 0:00:33
|
||
|
|
Initializing tasks: 100% |##############################################################| Time: 0:00:00
|
||
|
|
done
|
||
|
|
SDK has been successfully set up and is ready to be used.
|
||
|
|
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
|
||
|
|
$ . /home/scottrif/poky_sdk/environment-setup-i586-poky-linux
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para id='setting-up-the-esdk-terminal'>
|
||
|
|
<emphasis>Set Up a New Terminal to Work With the
|
||
|
|
Extensible SDK:</emphasis>
|
||
|
|
You must set up a new terminal to work with the SDK.
|
||
|
|
You cannot use the same BitBake shell used to build the
|
||
|
|
installer.</para>
|
||
|
|
|
||
|
|
<para>After opening a new shell, run the SDK environment
|
||
|
|
setup script as directed by the output from installing
|
||
|
|
the SDK:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ source ~/poky_sdk/environment-setup-i586-poky-linux
|
||
|
|
"SDK environment now set up; additionally you may now run devtool to perform development tasks.
|
||
|
|
Run devtool --help for further details.
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
If you get a warning about attempting to use the
|
||
|
|
extensible SDK in an environment set up to run
|
||
|
|
BitBake, you did not use a new shell.
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Build the Clean Image:</emphasis>
|
||
|
|
The final step in preparing to work on the kernel is to
|
||
|
|
build an initial image using
|
||
|
|
<filename>devtool</filename> in the new terminal you
|
||
|
|
just set up and initialized for SDK work:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ devtool build-image
|
||
|
|
Parsing recipes: 100% |##########################################| Time: 0:00:05
|
||
|
|
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1299 targets, 47 skipped, 0 masked, 0 errors.
|
||
|
|
WARNING: No packages to add, building image core-image-minimal unmodified
|
||
|
|
Loading cache: 100% |############################################| Time: 0:00:00
|
||
|
|
Loaded 1299 entries from dependency cache.
|
||
|
|
NOTE: Resolving any missing task queue dependencies
|
||
|
|
Initializing tasks: 100% |#######################################| Time: 0:00:07
|
||
|
|
Checking sstate mirror object availability: 100% |###############| Time: 0:00:00
|
||
|
|
NOTE: Executing SetScene Tasks
|
||
|
|
NOTE: Executing RunQueue Tasks
|
||
|
|
NOTE: Tasks Summary: Attempted 2866 tasks of which 2604 didn't need to be rerun and all succeeded.
|
||
|
|
NOTE: Successfully built core-image-minimal. You can find output files in /home/scottrif/poky_sdk/tmp/deploy/images/qemux86
|
||
|
|
</literallayout>
|
||
|
|
If you were building for actual hardware and not for
|
||
|
|
emulation, you could flash the image to a USB stick
|
||
|
|
on <filename>/dev/sdd</filename> and boot your device.
|
||
|
|
For an example that uses a Minnowboard, see the
|
||
|
|
<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/KernelDevelopmentWithEsdk'>TipsAndTricks/KernelDevelopmentWithEsdk</ulink>
|
||
|
|
Wiki page.
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
At this point you have set up to start making modifications to
|
||
|
|
the kernel by using the extensible SDK.
|
||
|
|
For a continued example, see the
|
||
|
|
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
|
||
|
|
section.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='getting-ready-for-traditional-kernel-development'>
|
||
|
|
<title>Getting Ready for Traditional Kernel Development</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Getting ready for traditional kernel development using the Yocto
|
||
|
|
Project involves many of the same steps as described in the
|
||
|
|
previous section.
|
||
|
|
However, you need to establish a local copy of the kernel source
|
||
|
|
since you will be editing these files.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Follow these steps to prepare to update the kernel image using
|
||
|
|
traditional kernel development flow with the Yocto Project.
|
||
|
|
Completing this procedure leaves you ready to make modifications
|
||
|
|
to the kernel source as described in the
|
||
|
|
"<link linkend='using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</link>"
|
||
|
|
section:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Initialize the BitBake Environment:</emphasis>
|
||
|
|
Before you can do anything using BitBake, you need to
|
||
|
|
initialize the BitBake build environment by sourcing the
|
||
|
|
build environment script
|
||
|
|
(i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>oe-init-build-env</filename></ulink>).
|
||
|
|
Also, for this example, be sure that the local branch
|
||
|
|
you have checked out for <filename>poky</filename> is
|
||
|
|
the Yocto Project &DISTRO_NAME; branch.
|
||
|
|
If you need to checkout out the &DISTRO_NAME; branch,
|
||
|
|
see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking out by Branch in Poky</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks Manual.
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky
|
||
|
|
$ git branch
|
||
|
|
master
|
||
|
|
* &DISTRO_NAME;
|
||
|
|
$ source oe-init-build-env
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
The previous commands assume the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>
|
||
|
|
(i.e. <filename>poky</filename>) have been cloned
|
||
|
|
using Git and the local repository is named
|
||
|
|
"poky".
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Prepare Your <filename>local.conf</filename>
|
||
|
|
File:</emphasis>
|
||
|
|
By default, the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||
|
|
variable is set to "qemux86", which is fine if you are
|
||
|
|
building for the QEMU emulator in 32-bit mode.
|
||
|
|
However, if you are not, you need to set the
|
||
|
|
<filename>MACHINE</filename> variable appropriately in
|
||
|
|
your <filename>conf/local.conf</filename> file found
|
||
|
|
in the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
|
||
|
|
(i.e. <filename>~/poky/build</filename> in this
|
||
|
|
example).</para>
|
||
|
|
|
||
|
|
<para>Also, since you are preparing to work on the
|
||
|
|
kernel image, you need to set the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
|
||
|
|
variable to include kernel modules.</para>
|
||
|
|
|
||
|
|
<para>This example uses the default "qemux86" for the
|
||
|
|
<filename>MACHINE</filename> variable but needs to
|
||
|
|
add the "kernel-modules":
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create a Layer for Patches:</emphasis>
|
||
|
|
You need to create a layer to hold patches created
|
||
|
|
for the kernel image.
|
||
|
|
You can use the
|
||
|
|
<filename>bitbake-layers create-layer</filename>
|
||
|
|
command as follows:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake-layers create-layer ../../meta-mylayer
|
||
|
|
NOTE: Starting bitbake server...
|
||
|
|
Add your new layer with 'bitbake-layers add-layer ../../meta-mylayer'
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
For background information on working with
|
||
|
|
common and BSP layers, see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks
|
||
|
|
Manual and the
|
||
|
|
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
|
||
|
|
section in the Yocto Project Board Support (BSP)
|
||
|
|
Developer's Guide, respectively.
|
||
|
|
For information on how to use the
|
||
|
|
<filename>bitbake-layers create-layer</filename>
|
||
|
|
command, see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks
|
||
|
|
Manual.
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Inform the BitBake Build Environment About
|
||
|
|
Your Layer:</emphasis>
|
||
|
|
As directed when you created your layer, you need to add
|
||
|
|
the layer to the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
|
||
|
|
variable in the <filename>bblayers.conf</filename> file
|
||
|
|
as follows:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake-layers add-layer ../../meta-mylayer
|
||
|
|
NOTE: Starting bitbake server ...
|
||
|
|
$
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create a Local Copy of the Kernel Git
|
||
|
|
Repository:</emphasis>
|
||
|
|
You can find Git repositories of supported Yocto Project
|
||
|
|
kernels organized under "Yocto Linux Kernel" in the
|
||
|
|
Yocto Project Source Repositories at
|
||
|
|
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
For simplicity, it is recommended that you create your
|
||
|
|
copy of the kernel Git repository outside of the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>,
|
||
|
|
which is usually named <filename>poky</filename>.
|
||
|
|
Also, be sure you are in the
|
||
|
|
<filename>standard/base</filename> branch.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The following commands show how to create a local copy
|
||
|
|
of the <filename>linux-yocto-4.12</filename> kernel and
|
||
|
|
be in the <filename>standard/base</filename> branch.
|
||
|
|
<note>
|
||
|
|
The <filename>linux-yocto-4.12</filename> kernel
|
||
|
|
can be used with the Yocto Project 2.4 release
|
||
|
|
and forward.
|
||
|
|
You cannot use the
|
||
|
|
<filename>linux-yocto-4.12</filename> kernel with
|
||
|
|
releases prior to Yocto Project 2.4:
|
||
|
|
</note>
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~
|
||
|
|
$ git clone git://git.yoctoproject.org/linux-yocto-4.12 --branch standard/base
|
||
|
|
Cloning into 'linux-yocto-4.12'...
|
||
|
|
remote: Counting objects: 6097195, done.
|
||
|
|
remote: Compressing objects: 100% (901026/901026), done.
|
||
|
|
remote: Total 6097195 (delta 5152604), reused 6096847 (delta 5152256)
|
||
|
|
Receiving objects: 100% (6097195/6097195), 1.24 GiB | 7.81 MiB/s, done.
|
||
|
|
Resolving deltas: 100% (5152604/5152604), done.
|
||
|
|
Checking connectivity... done.
|
||
|
|
Checking out files: 100% (59846/59846), done.
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create a Local Copy of the Kernel Cache Git
|
||
|
|
Repository:</emphasis>
|
||
|
|
For simplicity, it is recommended that you create your
|
||
|
|
copy of the kernel cache Git repository outside of the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>,
|
||
|
|
which is usually named <filename>poky</filename>.
|
||
|
|
Also, for this example, be sure you are in the
|
||
|
|
<filename>yocto-4.12</filename> branch.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The following commands show how to create a local copy
|
||
|
|
of the <filename>yocto-kernel-cache</filename> and
|
||
|
|
be in the <filename>yocto-4.12</filename> branch:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~
|
||
|
|
$ git clone git://git.yoctoproject.org/yocto-kernel-cache --branch yocto-4.12
|
||
|
|
Cloning into 'yocto-kernel-cache'...
|
||
|
|
remote: Counting objects: 22639, done.
|
||
|
|
remote: Compressing objects: 100% (9761/9761), done.
|
||
|
|
remote: Total 22639 (delta 12400), reused 22586 (delta 12347)
|
||
|
|
Receiving objects: 100% (22639/22639), 22.34 MiB | 6.27 MiB/s, done.
|
||
|
|
Resolving deltas: 100% (12400/12400), done.
|
||
|
|
Checking connectivity... done.
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
At this point, you are ready to start making modifications to
|
||
|
|
the kernel using traditional kernel development steps.
|
||
|
|
For a continued example, see the
|
||
|
|
"<link linkend='using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</link>"
|
||
|
|
section.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='creating-and-preparing-a-layer'>
|
||
|
|
<title>Creating and Preparing a Layer</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
If you are going to be modifying kernel recipes, it is recommended
|
||
|
|
that you create and prepare your own layer in which to do your
|
||
|
|
work.
|
||
|
|
Your layer contains its own
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>
|
||
|
|
append files (<filename>.bbappend</filename>) and provides a
|
||
|
|
convenient mechanism to create your own recipe files
|
||
|
|
(<filename>.bb</filename>) as well as store and use kernel
|
||
|
|
patch files.
|
||
|
|
For background information on working with layers, see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks Manual.
|
||
|
|
<note><title>Tip</title>
|
||
|
|
The Yocto Project comes with many tools that simplify
|
||
|
|
tasks you need to perform.
|
||
|
|
One such tool is the
|
||
|
|
<filename>bitbake-layers create-layer</filename>
|
||
|
|
command, which simplifies creating a new layer.
|
||
|
|
See the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks Manual for
|
||
|
|
information on how to use this script.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To better understand the layer you create for kernel development,
|
||
|
|
the following section describes how to create a layer
|
||
|
|
without the aid of tools.
|
||
|
|
These steps assume creation of a layer named
|
||
|
|
<filename>mylayer</filename> in your home directory:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create Structure</emphasis>:
|
||
|
|
Create the layer's structure:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd $HOME
|
||
|
|
$ mkdir meta-mylayer
|
||
|
|
$ mkdir meta-mylayer/conf
|
||
|
|
$ mkdir meta-mylayer/recipes-kernel
|
||
|
|
$ mkdir meta-mylayer/recipes-kernel/linux
|
||
|
|
$ mkdir meta-mylayer/recipes-kernel/linux/linux-yocto
|
||
|
|
</literallayout>
|
||
|
|
The <filename>conf</filename> directory holds your
|
||
|
|
configuration files, while the
|
||
|
|
<filename>recipes-kernel</filename> directory holds your
|
||
|
|
append file and eventual patch files.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create the Layer Configuration File</emphasis>:
|
||
|
|
Move to the <filename>meta-mylayer/conf</filename>
|
||
|
|
directory and create the <filename>layer.conf</filename>
|
||
|
|
file as follows:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
# We have a conf and classes directory, add to BBPATH
|
||
|
|
BBPATH .= ":${LAYERDIR}"
|
||
|
|
|
||
|
|
# We have recipes-* directories, add to BBFILES
|
||
|
|
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
|
||
|
|
${LAYERDIR}/recipes-*/*/*.bbappend"
|
||
|
|
|
||
|
|
BBFILE_COLLECTIONS += "mylayer"
|
||
|
|
BBFILE_PATTERN_mylayer = "^${LAYERDIR}/"
|
||
|
|
BBFILE_PRIORITY_mylayer = "5"
|
||
|
|
</literallayout>
|
||
|
|
Notice <filename>mylayer</filename> as part of the last
|
||
|
|
three statements.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create the Kernel Recipe Append File</emphasis>:
|
||
|
|
Move to the
|
||
|
|
<filename>meta-mylayer/recipes-kernel/linux</filename>
|
||
|
|
directory and create the kernel's append file.
|
||
|
|
This example uses the
|
||
|
|
<filename>linux-yocto-4.12</filename> kernel.
|
||
|
|
Thus, the name of the append file is
|
||
|
|
<filename>linux-yocto_4.12.bbappend</filename>:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
|
|
||
|
|
SRC_URI_append += "file://<replaceable>patch-file-one</replaceable>"
|
||
|
|
SRC_URI_append += "file://<replaceable>patch-file-two</replaceable>"
|
||
|
|
SRC_URI_append += "file://<replaceable>patch-file-three</replaceable>"
|
||
|
|
</literallayout>
|
||
|
|
The
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||
|
|
and
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
statements enable the OpenEmbedded build system to find
|
||
|
|
patch files.
|
||
|
|
For more information on using append files, see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks Manual.
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='modifying-an-existing-recipe'>
|
||
|
|
<title>Modifying an Existing Recipe</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
In many cases, you can customize an existing linux-yocto recipe to
|
||
|
|
meet the needs of your project.
|
||
|
|
Each release of the Yocto Project provides a few Linux
|
||
|
|
kernel recipes from which you can choose.
|
||
|
|
These are located in the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
|
||
|
|
in <filename>meta/recipes-kernel/linux</filename>.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Modifying an existing recipe can consist of the following:
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>Creating the append file</para></listitem>
|
||
|
|
<listitem><para>Applying patches</para></listitem>
|
||
|
|
<listitem><para>Changing the configuration</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Before modifying an existing recipe, be sure that you have created
|
||
|
|
a minimal, custom layer from which you can work.
|
||
|
|
See the
|
||
|
|
"<link linkend='creating-and-preparing-a-layer'>Creating and Preparing a Layer</link>"
|
||
|
|
section for information.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<section id='creating-the-append-file'>
|
||
|
|
<title>Creating the Append File</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
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
|
||
|
|
<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.12.bbappend
|
||
|
|
</literallayout>
|
||
|
|
The append file should initially extend the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
|
||
|
|
search path by prepending the directory that contains your
|
||
|
|
files to the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||
|
|
variable as follows:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
|
</literallayout>
|
||
|
|
The path <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
|
||
|
|
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 <filename>FILESPATH</filename> as
|
||
|
|
described above, you must place the files in your layer in the
|
||
|
|
following area:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
<replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto/
|
||
|
|
</literallayout>
|
||
|
|
<note>If you are working on a new machine Board Support Package
|
||
|
|
(BSP), be sure to refer to the
|
||
|
|
<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.12.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 ?= "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"
|
||
|
|
COMPATIBLE_MACHINE_edgerouter = "edgerouter"
|
||
|
|
COMPATIBLE_MACHINE_beaglebone = "beaglebone"
|
||
|
|
COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
|
||
|
|
|
||
|
|
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.
|
||
|
|
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_REF_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'>
|
||
|
|
<title>Applying Patches</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
If you have a single patch or a small series of patches
|
||
|
|
that you want to apply to the Linux kernel source, you
|
||
|
|
can do so just as you would with any other recipe.
|
||
|
|
You first copy the patches to the path added to
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||
|
|
in your <filename>.bbappend</filename> file as described in
|
||
|
|
the previous section, and then reference them in
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
statements.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
For example, you can apply a three-patch series by adding the
|
||
|
|
following lines to your linux-yocto
|
||
|
|
<filename>.bbappend</filename> file in your layer:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
SRC_URI += "file://0001-first-change.patch"
|
||
|
|
SRC_URI += "file://0002-second-change.patch"
|
||
|
|
SRC_URI += "file://0003-third-change.patch"
|
||
|
|
</literallayout>
|
||
|
|
The next time you run BitBake to build the Linux kernel,
|
||
|
|
BitBake detects the change in the recipe and fetches and
|
||
|
|
applies the patches before building the kernel.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
For a detailed example showing how to patch the kernel using
|
||
|
|
<filename>devtool</filename>, see the
|
||
|
|
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
|
||
|
|
and
|
||
|
|
"<link linkend='using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</link>"
|
||
|
|
sections.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='changing-the-configuration'>
|
||
|
|
<title>Changing the Configuration</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
You can make wholesale or incremental changes to the final
|
||
|
|
<filename>.config</filename> file used for the eventual
|
||
|
|
Linux kernel configuration by including a
|
||
|
|
<filename>defconfig</filename> file and by specifying
|
||
|
|
configuration fragments in the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
to be applied to that file.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
If you have a complete, working Linux kernel
|
||
|
|
<filename>.config</filename>
|
||
|
|
file you want to use for the configuration, as before, copy
|
||
|
|
that file to the appropriate <filename>${PN}</filename>
|
||
|
|
directory in your layer's
|
||
|
|
<filename>recipes-kernel/linux</filename> directory,
|
||
|
|
and rename the copied file to "defconfig".
|
||
|
|
Then, add the following lines to the linux-yocto
|
||
|
|
<filename>.bbappend</filename> file in your layer:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
|
SRC_URI += "file://defconfig"
|
||
|
|
</literallayout>
|
||
|
|
The <filename>SRC_URI</filename> tells the build system how to
|
||
|
|
search for the file, while the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||
|
|
extends the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
|
||
|
|
variable (search directories) to include the
|
||
|
|
<filename>${PN}</filename> directory you created to hold the
|
||
|
|
configuration changes.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<note>
|
||
|
|
The build system applies the configurations from the
|
||
|
|
<filename>defconfig</filename> file before applying any
|
||
|
|
subsequent configuration fragments.
|
||
|
|
The final kernel configuration is a combination of the
|
||
|
|
configurations in the <filename>defconfig</filename> file and
|
||
|
|
any configuration fragments you provide.
|
||
|
|
You need to realize that if you have any configuration
|
||
|
|
fragments, the build system applies these on top of and
|
||
|
|
after applying the existing <filename>defconfig</filename>
|
||
|
|
file configurations.
|
||
|
|
</note>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Generally speaking, the preferred approach is to determine the
|
||
|
|
incremental change you want to make and add that as a
|
||
|
|
configuration fragment.
|
||
|
|
For example, if you want to add support for a basic serial
|
||
|
|
console, create a file named <filename>8250.cfg</filename> in
|
||
|
|
the <filename>${PN}</filename> directory with the following
|
||
|
|
content (without indentation):
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
CONFIG_SERIAL_8250=y
|
||
|
|
CONFIG_SERIAL_8250_CONSOLE=y
|
||
|
|
CONFIG_SERIAL_8250_PCI=y
|
||
|
|
CONFIG_SERIAL_8250_NR_UARTS=4
|
||
|
|
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
|
||
|
|
CONFIG_SERIAL_CORE=y
|
||
|
|
CONFIG_SERIAL_CORE_CONSOLE=y
|
||
|
|
</literallayout>
|
||
|
|
Next, include this configuration fragment and extend the
|
||
|
|
<filename>FILESPATH</filename> variable in your
|
||
|
|
<filename>.bbappend</filename> file:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
|
SRC_URI += "file://8250.cfg"
|
||
|
|
</literallayout>
|
||
|
|
The next time you run BitBake to build the Linux kernel, BitBake
|
||
|
|
detects the change in the recipe and fetches and applies the
|
||
|
|
new configuration before building the kernel.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
For a detailed example showing how to configure the kernel,
|
||
|
|
see the
|
||
|
|
"<link linkend='configuring-the-kernel'>Configuring the Kernel</link>"
|
||
|
|
section.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='using-an-in-tree-defconfig-file'>
|
||
|
|
<title>Using an "In-Tree" <filename>defconfig</filename> File</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
It might be desirable to have kernel configuration fragment
|
||
|
|
support through a <filename>defconfig</filename> file that
|
||
|
|
is pulled from the kernel source tree for the configured
|
||
|
|
machine.
|
||
|
|
By default, the OpenEmbedded build system looks for
|
||
|
|
<filename>defconfig</filename> files in the layer used for
|
||
|
|
Metadata, which is "out-of-tree", and then configures them
|
||
|
|
using the following:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
SRC_URI += "file://defconfig"
|
||
|
|
</literallayout>
|
||
|
|
If you do not want to maintain copies of
|
||
|
|
<filename>defconfig</filename> files in your layer but would
|
||
|
|
rather allow users to use the default configuration from the
|
||
|
|
kernel tree and still be able to add configuration fragments
|
||
|
|
to the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
through, for example, append files, you can direct the
|
||
|
|
OpenEmbedded build system to use a
|
||
|
|
<filename>defconfig</filename> file that is "in-tree".
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To specify an "in-tree" <filename>defconfig</filename> file,
|
||
|
|
use the following statement form:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
KBUILD_DEFCONFIG_<replaceable>KMACHINE</replaceable> ?= <replaceable>defconfig_file</replaceable>
|
||
|
|
</literallayout>
|
||
|
|
Here is an example that appends the
|
||
|
|
<filename>KBUILD_DEFCONFIG</filename> variable with
|
||
|
|
"common-pc" and provides the path to the "in-tree"
|
||
|
|
<filename>defconfig</filename> file:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
KBUILD_DEFCONFIG_common-pc ?= "/home/scottrif/configfiles/my_defconfig_file"
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Aside from modifying your kernel recipe and providing your own
|
||
|
|
<filename>defconfig</filename> file, you need to be sure no
|
||
|
|
files or statements set <filename>SRC_URI</filename> to use a
|
||
|
|
<filename>defconfig</filename> other than your "in-tree"
|
||
|
|
file (e.g. a kernel's
|
||
|
|
<filename>linux-</filename><replaceable>machine</replaceable><filename>.inc</filename>
|
||
|
|
file).
|
||
|
|
In other words, if the build system detects a statement
|
||
|
|
that identifies an "out-of-tree"
|
||
|
|
<filename>defconfig</filename> file, that statement
|
||
|
|
will override your
|
||
|
|
<filename>KBUILD_DEFCONFIG</filename> variable.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
See the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-KBUILD_DEFCONFIG'><filename>KBUILD_DEFCONFIG</filename></ulink>
|
||
|
|
variable description for more information.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id="using-devtool-to-patch-the-kernel">
|
||
|
|
<title>Using <filename>devtool</filename> to Patch the Kernel</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The steps in this procedure show you how you can patch the
|
||
|
|
kernel using the extensible SDK and <filename>devtool</filename>.
|
||
|
|
<note>
|
||
|
|
Before attempting this procedure, be sure you have performed
|
||
|
|
the steps to get ready for updating the kernel as described
|
||
|
|
in the
|
||
|
|
"<link linkend='getting-ready-to-develop-using-devtool'>Getting Ready to Develop Using <filename>devtool</filename></link>"
|
||
|
|
section.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Patching the kernel involves changing or adding configurations
|
||
|
|
to an existing kernel, changing or adding recipes to the kernel
|
||
|
|
that are needed to support specific hardware features, or even
|
||
|
|
altering the source code itself.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
This example creates a simple patch by adding some QEMU emulator
|
||
|
|
console output at boot time through <filename>printk</filename>
|
||
|
|
statements in the kernel's <filename>calibrate.c</filename> source
|
||
|
|
code file.
|
||
|
|
Applying the patch and booting the modified image causes the added
|
||
|
|
messages to appear on the emulator's console.
|
||
|
|
The example is a continuation of the setup procedure found in
|
||
|
|
the
|
||
|
|
"<link linkend='getting-ready-to-develop-using-devtool'>Getting Ready to Develop Using <filename>devtool</filename></link>"
|
||
|
|
Section.
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Check Out the Kernel Source Files:</emphasis>
|
||
|
|
First you must use <filename>devtool</filename> to checkout
|
||
|
|
the kernel source code in its workspace.
|
||
|
|
Be sure you are in the terminal set up to do work
|
||
|
|
with the extensible SDK.
|
||
|
|
<note>
|
||
|
|
See this
|
||
|
|
<link linkend='setting-up-the-esdk-terminal'>step</link>
|
||
|
|
in the
|
||
|
|
"<link linkend='getting-ready-to-develop-using-devtool'>Getting Ready to Develop Using <filename>devtool</filename></link>"
|
||
|
|
section for more information.
|
||
|
|
</note>
|
||
|
|
Use the following <filename>devtool</filename> command
|
||
|
|
to check out the code:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ devtool modify linux-yocto
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
During the checkout operation, a bug exists that could
|
||
|
|
cause errors such as the following to appear:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus
|
||
|
|
be3a89ce7c47178880ba7bf6293d7404 for
|
||
|
|
/path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack
|
||
|
|
</literallayout>
|
||
|
|
You can safely ignore these messages.
|
||
|
|
The source code is correctly checked out.
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Edit the Source Files</emphasis>
|
||
|
|
Follow these steps to make some simple changes to the source
|
||
|
|
files:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Change the working directory</emphasis>:
|
||
|
|
In the previous step, the output noted where you can find
|
||
|
|
the source files (e.g.
|
||
|
|
<filename>~/poky_sdk/workspace/sources/linux-yocto</filename>).
|
||
|
|
Change to where the kernel source code is before making
|
||
|
|
your edits to the <filename>calibrate.c</filename> file:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky_sdk/workspace/sources/linux-yocto
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Edit the source file</emphasis>:
|
||
|
|
Edit the <filename>init/calibrate.c</filename> file to have
|
||
|
|
the following changes:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
void calibrate_delay(void)
|
||
|
|
{
|
||
|
|
unsigned long lpj;
|
||
|
|
static bool printed;
|
||
|
|
int this_cpu = smp_processor_id();
|
||
|
|
|
||
|
|
printk("*************************************\n");
|
||
|
|
printk("* *\n");
|
||
|
|
printk("* HELLO YOCTO KERNEL *\n");
|
||
|
|
printk("* *\n");
|
||
|
|
printk("*************************************\n");
|
||
|
|
|
||
|
|
if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
|
||
|
|
.
|
||
|
|
.
|
||
|
|
.
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Build the Updated Kernel Source:</emphasis>
|
||
|
|
To build the updated kernel source, use
|
||
|
|
<filename>devtool</filename>:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ devtool build linux-yocto
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create the Image With the New Kernel:</emphasis>
|
||
|
|
Use the <filename>devtool build-image</filename> command
|
||
|
|
to create a new image that has the new kernel.
|
||
|
|
<note>
|
||
|
|
If the image you originally created resulted in a Wic
|
||
|
|
file, you can use an alternate method to create the new
|
||
|
|
image with the updated kernel.
|
||
|
|
For an example, see the steps in the
|
||
|
|
<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/KernelDevelopmentWithEsdk'>TipsAndTricks/KernelDevelopmentWithEsdk</ulink>
|
||
|
|
Wiki Page.
|
||
|
|
</note>
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~
|
||
|
|
$ devtool build-image core-image-minimal
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Test the New Image:</emphasis>
|
||
|
|
For this example, you can run the new image using QEMU
|
||
|
|
to verify your changes:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Boot the image</emphasis>:
|
||
|
|
Boot the modified image in the QEMU emulator
|
||
|
|
using this command:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ runqemu qemux86
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Verify the changes</emphasis>:
|
||
|
|
Log into the machine using <filename>root</filename>
|
||
|
|
with no password and then use the following shell
|
||
|
|
command to scroll through the console's boot output.
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
# dmesg | less
|
||
|
|
</literallayout>
|
||
|
|
You should see the results of your
|
||
|
|
<filename>printk</filename> statements
|
||
|
|
as part of the output when you scroll down the
|
||
|
|
console window.
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Stage and commit your changes</emphasis>:
|
||
|
|
Within your eSDK terminal, change your working directory to
|
||
|
|
where you modified the <filename>calibrate.c</filename>
|
||
|
|
file and use these Git commands to stage and commit your
|
||
|
|
changes:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky_sdk/workspace/sources/linux-yocto
|
||
|
|
$ git status
|
||
|
|
$ git add init/calibrate.c
|
||
|
|
$ git commit -m "calibrate: Add printk example"
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Export the Patches and Create an Append File:</emphasis>
|
||
|
|
To export your commits as patches and create a
|
||
|
|
<filename>.bbappend</filename> file, use the following
|
||
|
|
command in the terminal used to work with the extensible
|
||
|
|
SDK.
|
||
|
|
This example uses the previously established layer named
|
||
|
|
<filename>meta-mylayer</filename>.
|
||
|
|
<note>
|
||
|
|
See Step 3 of the
|
||
|
|
"<link linkend='getting-ready-to-develop-using-devtool'>Getting Ready to Develop Using devtool</link>"
|
||
|
|
section for information on setting up this layer.
|
||
|
|
</note>
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ devtool finish linux-yocto ~/meta-mylayer
|
||
|
|
</literallayout>
|
||
|
|
Once the command finishes, the patches and the
|
||
|
|
<filename>.bbappend</filename> file are located in the
|
||
|
|
<filename>~/meta-mylayer/recipes-kernel/linux</filename>
|
||
|
|
directory.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Build the Image With Your Modified Kernel:</emphasis>
|
||
|
|
You can now build an image that includes your kernel
|
||
|
|
patches.
|
||
|
|
Execute the following command from your
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
|
||
|
|
in the terminal set up to run BitBake:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake core-image-minimal
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id="using-traditional-kernel-development-to-patch-the-kernel">
|
||
|
|
<title>Using Traditional Kernel Development to Patch the Kernel</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The steps in this procedure show you how you can patch the
|
||
|
|
kernel using traditional kernel development (i.e. not using
|
||
|
|
<filename>devtool</filename> and the extensible SDK as
|
||
|
|
described in the
|
||
|
|
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
|
||
|
|
section).
|
||
|
|
<note>
|
||
|
|
Before attempting this procedure, be sure you have performed
|
||
|
|
the steps to get ready for updating the kernel as described
|
||
|
|
in the
|
||
|
|
"<link linkend='getting-ready-for-traditional-kernel-development'>Getting Ready for Traditional Kernel Development</link>"
|
||
|
|
section.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Patching the kernel involves changing or adding configurations
|
||
|
|
to an existing kernel, changing or adding recipes to the kernel
|
||
|
|
that are needed to support specific hardware features, or even
|
||
|
|
altering the source code itself.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The example in this section creates a simple patch by adding some
|
||
|
|
QEMU emulator console output at boot time through
|
||
|
|
<filename>printk</filename> statements in the kernel's
|
||
|
|
<filename>calibrate.c</filename> source code file.
|
||
|
|
Applying the patch and booting the modified image causes the added
|
||
|
|
messages to appear on the emulator's console.
|
||
|
|
The example is a continuation of the setup procedure found in
|
||
|
|
the
|
||
|
|
"<link linkend='getting-ready-for-traditional-kernel-development'>Getting Ready for Traditional Kernel Development</link>"
|
||
|
|
Section.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Although this example uses Git and shell commands to generate the
|
||
|
|
patch, you could use the <filename>yocto-kernel</filename> script
|
||
|
|
found in the <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
|
||
|
|
under <filename>scripts</filename> to add and manage kernel
|
||
|
|
patches and configuration.
|
||
|
|
See the "<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'>Managing kernel Patches and Config Items with yocto-kernel</ulink>"
|
||
|
|
section in the Yocto Project Board Support Packages (BSP)
|
||
|
|
Developer's Guide for more information on the
|
||
|
|
<filename>yocto-kernel</filename> script.
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Edit the Source Files</emphasis>
|
||
|
|
Prior to this step, you should have used Git to create a
|
||
|
|
local copy of the repository for your kernel.
|
||
|
|
Assuming you created the repository as directed in the
|
||
|
|
"<link linkend='getting-ready-for-traditional-kernel-development'>Getting Ready for Traditional Kernel Development</link>"
|
||
|
|
section, use the following commands to edit the
|
||
|
|
<filename>calibrate.c</filename> file:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Change the working directory</emphasis>:
|
||
|
|
You need to locate the source files in the
|
||
|
|
local copy of the kernel Git repository:
|
||
|
|
Change to where the kernel source code is before making
|
||
|
|
your edits to the <filename>calibrate.c</filename> file:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/linux-yocto-4.12/init
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Edit the source file</emphasis>:
|
||
|
|
Edit the <filename>calibrate.c</filename> file to have
|
||
|
|
the following changes:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
void calibrate_delay(void)
|
||
|
|
{
|
||
|
|
unsigned long lpj;
|
||
|
|
static bool printed;
|
||
|
|
int this_cpu = smp_processor_id();
|
||
|
|
|
||
|
|
printk("*************************************\n");
|
||
|
|
printk("* *\n");
|
||
|
|
printk("* HELLO YOCTO KERNEL *\n");
|
||
|
|
printk("* *\n");
|
||
|
|
printk("*************************************\n");
|
||
|
|
|
||
|
|
if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
|
||
|
|
.
|
||
|
|
.
|
||
|
|
.
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Stage and Commit Your Changes:</emphasis>
|
||
|
|
Use standard Git commands to stage and commit the changes
|
||
|
|
you just made:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git add calibrate.c
|
||
|
|
$ git commit -m "calibrate.c - Added some printk statements"
|
||
|
|
</literallayout>
|
||
|
|
If you do not stage and commit your changes, the OpenEmbedded
|
||
|
|
Build System will not pick up the changes.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Update Your <filename>local.conf</filename> File
|
||
|
|
to Point to Your Source Files:</emphasis>
|
||
|
|
In addition to your <filename>local.conf</filename> file
|
||
|
|
specifying to use "kernel-modules" and the "qemux86"
|
||
|
|
machine, it must also point to the updated kernel source
|
||
|
|
files.
|
||
|
|
Add
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
and
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
|
||
|
|
statements similar to the following to your
|
||
|
|
<filename>local.conf</filename>:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build/conf
|
||
|
|
</literallayout>
|
||
|
|
Add the following to the <filename>local.conf</filename>:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
SRC_URI_pn-linux-yocto = "git:///<replaceable>path-to</replaceable>/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \
|
||
|
|
git:///<replaceable>path-to</replaceable>/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
|
||
|
|
SRCREV_meta_qemux86 = "${AUTOREV}"
|
||
|
|
SRCREV_machine_qemux86 = "${AUTOREV}"
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
Be sure to replace
|
||
|
|
<replaceable>path-to</replaceable> with the pathname
|
||
|
|
to your local Git repositories.
|
||
|
|
Also, you must be sure to specify the correct branch
|
||
|
|
and machine types.
|
||
|
|
For this example, the branch is
|
||
|
|
<filename>standard/base</filename> and the machine is
|
||
|
|
"qemux86".
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Build the Image:</emphasis>
|
||
|
|
With the source modified, your changes staged and
|
||
|
|
committed, and the <filename>local.conf</filename> file
|
||
|
|
pointing to the kernel files, you can now use BitBake to
|
||
|
|
build the image:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake core-image-minimal
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Boot the image</emphasis>:
|
||
|
|
Boot the modified image in the QEMU emulator
|
||
|
|
using this command.
|
||
|
|
When prompted to login to the QEMU console, use "root"
|
||
|
|
with no password:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ runqemu qemux86
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Look for Your Changes:</emphasis>
|
||
|
|
As QEMU booted, you might have seen your changes rapidly
|
||
|
|
scroll by.
|
||
|
|
If not, use these commands to see your changes:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
# dmesg | less
|
||
|
|
</literallayout>
|
||
|
|
You should see the results of your
|
||
|
|
<filename>printk</filename> statements
|
||
|
|
as part of the output when you scroll down the
|
||
|
|
console window.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Generate the Patch File:</emphasis>
|
||
|
|
Once you are sure that your patch works correctly, you
|
||
|
|
can generate a <filename>*.patch</filename> file in the
|
||
|
|
kernel source repository:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/linux-yocto-4.12/init
|
||
|
|
$ git format-patch -1
|
||
|
|
0001-calibrate.c-Added-some-printk-statements.patch
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Move the Patch File to Your Layer:</emphasis>
|
||
|
|
In order for subsequent builds to pick up patches, you
|
||
|
|
need to move the patch file you created in the previous
|
||
|
|
step to your layer <filename>meta-mylayer</filename>.
|
||
|
|
For this example, the layer created earlier is located
|
||
|
|
in your home directory as <filename>meta-mylayer</filename>.
|
||
|
|
When the layer was created using the
|
||
|
|
<filename>yocto-create</filename> script, no additional
|
||
|
|
hierarchy was created to support patches.
|
||
|
|
Before moving the patch file, you need to add additional
|
||
|
|
structure to your layer using the following commands:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/meta-mylayer
|
||
|
|
$ mkdir recipes-kernel
|
||
|
|
$ mkdir recipes-kernel/linux
|
||
|
|
$ mkdir recipes-kernel/linux/linux-yocto
|
||
|
|
</literallayout>
|
||
|
|
Once you have created this hierarchy in your layer, you can
|
||
|
|
move the patch file using the following command:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ mv ~/linux-yocto-4.12/init/0001-calibrate.c-Added-some-printk-statements.patch ~/meta-mylayer/recipes-kernel/linux/linux-yocto
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create the Append File:</emphasis>
|
||
|
|
Finally, you need to create the
|
||
|
|
<filename>linux-yocto_4.12.bbappend</filename> file and
|
||
|
|
insert statements that allow the OpenEmbedded build
|
||
|
|
system to find the patch.
|
||
|
|
The append file needs to be in your layer's
|
||
|
|
<filename>recipes-kernel/linux</filename>
|
||
|
|
directory and it must be named
|
||
|
|
<filename>linux-yocto_4.12.bbappend</filename> and have
|
||
|
|
the following contents:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
|
|
||
|
|
SRC_URI_append = " file://0001-calibrate.c-Added-some-printk-statements.patch"
|
||
|
|
</literallayout>
|
||
|
|
The
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||
|
|
and
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
statements enable the OpenEmbedded build system to find
|
||
|
|
the patch file.</para>
|
||
|
|
|
||
|
|
<para>For more information on append files and patches,
|
||
|
|
see the
|
||
|
|
"<link linkend='creating-the-append-file'>Creating the Append File</link>"
|
||
|
|
and
|
||
|
|
"<link linkend='applying-patches'>Applying Patches</link>"
|
||
|
|
sections.
|
||
|
|
You can also see the
|
||
|
|
"<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer"</ulink>"
|
||
|
|
section in the Yocto Project Development Tasks Manual.
|
||
|
|
<note>
|
||
|
|
To build <filename>core-image-minimal</filename>
|
||
|
|
again and see the effects of your patch, you can
|
||
|
|
essentially eliminate the temporary source files
|
||
|
|
saved in <filename>poky/build/tmp/work/...</filename>
|
||
|
|
and residual effects of the build by entering the
|
||
|
|
following sequence of commands:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd ~/poky/build
|
||
|
|
$ bitbake -c cleanall yocto-linux
|
||
|
|
$ bitbake core-image-minimal -c cleanall
|
||
|
|
$ bitbake core-image-minimal
|
||
|
|
$ runqemu qemux86
|
||
|
|
</literallayout>
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='configuring-the-kernel'>
|
||
|
|
<title>Configuring the Kernel</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Configuring the Yocto Project kernel consists of making sure the
|
||
|
|
<filename>.config</filename> file has all the right information
|
||
|
|
in it for the image you are building.
|
||
|
|
You can use the <filename>menuconfig</filename> tool and
|
||
|
|
configuration fragments to make sure your
|
||
|
|
<filename>.config</filename> file is just how you need it.
|
||
|
|
You can also save known configurations in a
|
||
|
|
<filename>defconfig</filename> file that the build system can use
|
||
|
|
for kernel configuration.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
This section describes how to use <filename>menuconfig</filename>,
|
||
|
|
create and use configuration fragments, and how to interactively
|
||
|
|
modify your <filename>.config</filename> file to create the
|
||
|
|
leanest kernel configuration file possible.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
For more information on kernel configuration, see the
|
||
|
|
"<link linkend='changing-the-configuration'>Changing the Configuration</link>"
|
||
|
|
section.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<section id='using-menuconfig'>
|
||
|
|
<title>Using <filename>menuconfig</filename></title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The easiest way to define kernel configurations is to set
|
||
|
|
them through the <filename>menuconfig</filename> tool.
|
||
|
|
This tool provides an interactive method with which
|
||
|
|
to set kernel configurations.
|
||
|
|
For general information on <filename>menuconfig</filename>, see
|
||
|
|
<ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To use the <filename>menuconfig</filename> tool in the Yocto
|
||
|
|
Project development environment, you must launch it using
|
||
|
|
BitBake.
|
||
|
|
Thus, the environment must be set up using the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
|
||
|
|
script found in the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
|
||
|
|
You must also be sure of the state of your build's
|
||
|
|
configuration in the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
|
||
|
|
The following commands initialize the BitBake environment,
|
||
|
|
run the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configme'><filename>do_kernel_configme</filename></ulink>
|
||
|
|
task, and launch <filename>menuconfig</filename>.
|
||
|
|
These commands assume the Source Directory's top-level folder
|
||
|
|
is <filename>~/poky</filename>:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ cd poky
|
||
|
|
$ source oe-init-build-env
|
||
|
|
$ bitbake linux-yocto -c kernel_configme -f
|
||
|
|
$ bitbake linux-yocto -c menuconfig
|
||
|
|
</literallayout>
|
||
|
|
Once <filename>menuconfig</filename> comes up, its standard
|
||
|
|
interface allows you to interactively examine and configure
|
||
|
|
all the kernel configuration parameters.
|
||
|
|
After making your changes, simply exit the tool and save your
|
||
|
|
changes to create an updated version of the
|
||
|
|
<filename>.config</filename> configuration file.
|
||
|
|
<note>
|
||
|
|
You can use the entire <filename>.config</filename> file
|
||
|
|
as the <filename>defconfig</filename> file.
|
||
|
|
For information on <filename>defconfig</filename> files,
|
||
|
|
see the
|
||
|
|
"<link linkend='changing-the-configuration'>Changing the Configuration</link>",
|
||
|
|
"<link linkend='using-an-in-tree-defconfig-file'>Using an In-Tree <filename>defconfig</filename> File</link>,
|
||
|
|
and
|
||
|
|
"<link linkend='creating-a-defconfig-file'>Creating a <filename>defconfig</filename> File</link>"
|
||
|
|
sections.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Consider an example that configures the "CONFIG_SMP" setting
|
||
|
|
for the <filename>linux-yocto-4.12</filename> kernel.
|
||
|
|
<note>
|
||
|
|
The OpenEmbedded build system recognizes this kernel as
|
||
|
|
<filename>linux-yocto</filename> through Metadata (e.g.
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></ulink><filename>_linux-yocto ?= "12.4%"</filename>).
|
||
|
|
</note>
|
||
|
|
Once <filename>menuconfig</filename> launches, use the
|
||
|
|
interface to navigate through the selections to find the
|
||
|
|
configuration settings in which you are interested.
|
||
|
|
For this example, you deselect "CONFIG_SMP" by clearing the
|
||
|
|
"Symmetric Multi-Processing Support" option.
|
||
|
|
Using the interface, you can find the option under
|
||
|
|
"Processor Type and Features".
|
||
|
|
To deselect "CONFIG_SMP", use the arrow keys to
|
||
|
|
highlight "Symmetric Multi-Processing Support" and enter "N"
|
||
|
|
to clear the asterisk.
|
||
|
|
When you are finished, exit out and save the change.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Saving the selections updates the <filename>.config</filename>
|
||
|
|
configuration file.
|
||
|
|
This is the file that the OpenEmbedded build system uses to
|
||
|
|
configure the kernel during the build.
|
||
|
|
You can find and examine this file in the Build Directory in
|
||
|
|
<filename>tmp/work/</filename>.
|
||
|
|
The actual <filename>.config</filename> is located in the
|
||
|
|
area where the specific kernel is built.
|
||
|
|
For example, if you were building a Linux Yocto kernel based
|
||
|
|
on the <filename>linux-yocto-4.12</filename> kernel and you
|
||
|
|
were building a QEMU image targeted for
|
||
|
|
<filename>x86</filename> architecture, the
|
||
|
|
<filename>.config</filename> file would be:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+gitAUTOINC+eda4d18...
|
||
|
|
...967-r0/linux-qemux86-standard-build/.config
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
The previous example directory is artificially split and
|
||
|
|
many of the characters in the actual filename are omitted
|
||
|
|
in order to make it more readable.
|
||
|
|
Also, depending on the kernel you are using, the exact
|
||
|
|
pathname might differ.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Within the <filename>.config</filename> file, you can see the
|
||
|
|
kernel settings.
|
||
|
|
For example, the following entry shows that symmetric
|
||
|
|
multi-processor support is not set:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
# CONFIG_SMP is not set
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
A good method to isolate changed configurations is to use a
|
||
|
|
combination of the <filename>menuconfig</filename> tool and
|
||
|
|
simple shell commands.
|
||
|
|
Before changing configurations with
|
||
|
|
<filename>menuconfig</filename>, copy the existing
|
||
|
|
<filename>.config</filename> and rename it to something else,
|
||
|
|
use <filename>menuconfig</filename> to make as many changes as
|
||
|
|
you want and save them, then compare the renamed configuration
|
||
|
|
file against the newly created file.
|
||
|
|
You can use the resulting differences as your base to create
|
||
|
|
configuration fragments to permanently save in your kernel
|
||
|
|
layer.
|
||
|
|
<note>
|
||
|
|
Be sure to make a copy of the <filename>.config</filename>
|
||
|
|
file and do not just rename it.
|
||
|
|
The build system needs an existing
|
||
|
|
<filename>.config</filename> file from which to work.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='creating-a-defconfig-file'>
|
||
|
|
<title>Creating a <filename>defconfig</filename> File</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
A <filename>defconfig</filename> file is simply a
|
||
|
|
<filename>.config</filename> renamed to "defconfig".
|
||
|
|
You can use a <filename>defconfig</filename> file
|
||
|
|
to retain a known set of kernel configurations from which the
|
||
|
|
OpenEmbedded build system can draw to create the final
|
||
|
|
<filename>.config</filename> file.
|
||
|
|
<note>
|
||
|
|
Out-of-the-box, the Yocto Project never ships a
|
||
|
|
<filename>defconfig</filename> or
|
||
|
|
<filename>.config</filename> file.
|
||
|
|
The OpenEmbedded build system creates the final
|
||
|
|
<filename>.config</filename> file used to configure the
|
||
|
|
kernel.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To create a <filename>defconfig</filename>, start with a
|
||
|
|
complete, working Linux kernel <filename>.config</filename>
|
||
|
|
file.
|
||
|
|
Copy that file to the appropriate
|
||
|
|
<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
|
||
|
|
directory in your layer's
|
||
|
|
<filename>recipes-kernel/linux</filename> directory, and rename
|
||
|
|
the copied file to "defconfig" (e.g.
|
||
|
|
<filename>~/meta-mylayer/recipes-kernel/linux/linux-yocto/defconfig</filename>).
|
||
|
|
Then, add the following lines to the linux-yocto
|
||
|
|
<filename>.bbappend</filename> file in your layer:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
|
SRC_URI += "file://defconfig"
|
||
|
|
</literallayout>
|
||
|
|
The
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
tells the build system how to search for the file, while the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
|
||
|
|
extends the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
|
||
|
|
variable (search directories) to include the
|
||
|
|
<filename>${PN}</filename> directory you created to hold the
|
||
|
|
configuration changes.
|
||
|
|
<note>
|
||
|
|
The build system applies the configurations from the
|
||
|
|
<filename>defconfig</filename> file before applying any
|
||
|
|
subsequent configuration fragments.
|
||
|
|
The final kernel configuration is a combination of the
|
||
|
|
configurations in the <filename>defconfig</filename>
|
||
|
|
file and any configuration fragments you provide.
|
||
|
|
You need to realize that if you have any configuration
|
||
|
|
fragments, the build system applies these on top of and
|
||
|
|
after applying the existing defconfig file configurations.
|
||
|
|
</note>
|
||
|
|
For more information on configuring the kernel, see the
|
||
|
|
"<link link='changing-the-configuration'>Changing the Configuration</link>"
|
||
|
|
section.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='creating-config-fragments'>
|
||
|
|
<title>Creating Configuration Fragments</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Configuration fragments are simply kernel options that
|
||
|
|
appear in a file placed where the OpenEmbedded build system
|
||
|
|
can find and apply them.
|
||
|
|
The build system applies configuration fragments after
|
||
|
|
applying configurations from a <filename>defconfig</filename>
|
||
|
|
file.
|
||
|
|
Thus, the final kernel configuration is a combination of the
|
||
|
|
configurations in the <filename>defconfig</filename>
|
||
|
|
file and then any configuration fragments you provide.
|
||
|
|
The build system applies fragments on top of and
|
||
|
|
after applying the existing defconfig file configurations.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Syntactically, the configuration statement is identical to
|
||
|
|
what would appear in the <filename>.config</filename> file,
|
||
|
|
which is in the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
|
||
|
|
<note>
|
||
|
|
For more information about where the
|
||
|
|
<filename>.config</filename> file is located, see the
|
||
|
|
example in the
|
||
|
|
"<link linkend='using-menuconfig'>Using <filename>menuconfig</filename></link>"
|
||
|
|
section.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
It is simple to create a configuration fragment.
|
||
|
|
One method is to use shell commands.
|
||
|
|
For example, issuing the following from the shell creates a
|
||
|
|
configuration fragment file named
|
||
|
|
<filename>my_smp.cfg</filename> that enables multi-processor
|
||
|
|
support within the kernel:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ echo "CONFIG_SMP=y" >> my_smp.cfg
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
All configuration fragment files must use the
|
||
|
|
<filename>.cfg</filename> extension in order for the
|
||
|
|
OpenEmbedded build system to recognize them as a
|
||
|
|
configuration fragment.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Another method is to create a configuration fragment using the
|
||
|
|
differences between two configuration files: one previously
|
||
|
|
created and saved, and one freshly created using the
|
||
|
|
<filename>menuconfig</filename> tool.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To create a configuration fragment using this method, follow
|
||
|
|
these steps:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Complete a Build Through Kernel Configuration:</emphasis>
|
||
|
|
Complete a build at least through the kernel
|
||
|
|
configuration task as follows:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ bitbake linux-yocto -c kernel_configme -f
|
||
|
|
</literallayout>
|
||
|
|
This step ensures that you create a
|
||
|
|
<filename>.config</filename> file from a known state.
|
||
|
|
Because situations exist where your build state might
|
||
|
|
become unknown, it is best to run this task prior
|
||
|
|
to starting <filename>menuconfig</filename>.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Launch <filename>menuconfig</filename>:</emphasis>
|
||
|
|
Run the <filename>menuconfig</filename> command:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ bitbake linux-yocto -c menuconfig
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create the Configuration Fragment:</emphasis>
|
||
|
|
Run the <filename>diffconfig</filename>
|
||
|
|
command to prepare a configuration fragment.
|
||
|
|
The resulting file <filename>fragment.cfg</filename>
|
||
|
|
is placed in the
|
||
|
|
<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}</filename> directory:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ bitbake linux-yocto -c diffconfig
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The <filename>diffconfig</filename> command creates a file
|
||
|
|
that is a list of Linux kernel <filename>CONFIG_</filename>
|
||
|
|
assignments.
|
||
|
|
See the "<link linkend='changing-the-configuration'>Changing the Configuration</link>"
|
||
|
|
section for additional information on how to use the output
|
||
|
|
as a configuration fragment.
|
||
|
|
<note>
|
||
|
|
You can also use this method to create configuration
|
||
|
|
fragments for a BSP.
|
||
|
|
See the "<link linkend='bsp-descriptions'>BSP Descriptions</link>"
|
||
|
|
section for more information.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Where do you put your configuration fragment files?
|
||
|
|
You can place these files in an area pointed to by
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
as directed by your <filename>bblayers.conf</filename> file,
|
||
|
|
which is located in your layer.
|
||
|
|
The OpenEmbedded build system picks up the configuration and
|
||
|
|
adds it to the kernel's configuration.
|
||
|
|
For example, suppose you had a set of configuration options
|
||
|
|
in a file called <filename>myconfig.cfg</filename>.
|
||
|
|
If you put that file inside a directory named
|
||
|
|
<filename>linux-yocto</filename> that resides in the same
|
||
|
|
directory as the kernel's append file within your layer
|
||
|
|
and then add the following statements to the kernel's append
|
||
|
|
file, those configuration options will be picked up and applied
|
||
|
|
when the kernel is built:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
||
|
|
SRC_URI += "file://myconfig.cfg"
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
As mentioned earlier, you can group related configurations
|
||
|
|
into multiple files and name them all in the
|
||
|
|
<filename>SRC_URI</filename> statement as well.
|
||
|
|
For example, you could group separate configurations
|
||
|
|
specifically for Ethernet and graphics into their own files
|
||
|
|
and add those 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>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='validating-configuration'>
|
||
|
|
<title>Validating Configuration</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
You can use the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configcheck'><filename>do_kernel_configcheck</filename></ulink>
|
||
|
|
task to provide configuration validation:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ bitbake linux-yocto -c kernel_configcheck -f
|
||
|
|
</literallayout>
|
||
|
|
Running this task produces warnings for when a
|
||
|
|
requested configuration does not appear in the final
|
||
|
|
<filename>.config</filename> file or when you override a
|
||
|
|
policy configuration in a hardware configuration fragment.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
In order to run this task, you must have an existing
|
||
|
|
<filename>.config</filename> file.
|
||
|
|
See the
|
||
|
|
"<link linkend='using-menuconfig'>Using <filename>menuconfig</filename></link>"
|
||
|
|
section for information on how to create a configuration file.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Following is sample output from the
|
||
|
|
<filename>do_kernel_configcheck</filename> task:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
Loading cache: 100% |########################################################| Time: 0:00:00
|
||
|
|
Loaded 1275 entries from dependency cache.
|
||
|
|
NOTE: Resolving any missing task queue dependencies
|
||
|
|
|
||
|
|
Build Configuration:
|
||
|
|
.
|
||
|
|
.
|
||
|
|
.
|
||
|
|
|
||
|
|
NOTE: Executing SetScene Tasks
|
||
|
|
NOTE: Executing RunQueue Tasks
|
||
|
|
WARNING: linux-yocto-4.12.12+gitAUTOINC+eda4d18ce4_16de014967-r0 do_kernel_configcheck:
|
||
|
|
[kernel config]: specified values did not make it into the kernel's final configuration:
|
||
|
|
|
||
|
|
---------- CONFIG_X86_TSC -----------------
|
||
|
|
Config: CONFIG_X86_TSC
|
||
|
|
From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc-cpu.cfg
|
||
|
|
Requested value: CONFIG_X86_TSC=y
|
||
|
|
Actual value:
|
||
|
|
|
||
|
|
|
||
|
|
---------- CONFIG_X86_BIGSMP -----------------
|
||
|
|
Config: CONFIG_X86_BIGSMP
|
||
|
|
From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
|
||
|
|
/home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
|
||
|
|
Requested value: # CONFIG_X86_BIGSMP is not set
|
||
|
|
Actual value:
|
||
|
|
|
||
|
|
|
||
|
|
---------- CONFIG_NR_CPUS -----------------
|
||
|
|
Config: CONFIG_NR_CPUS
|
||
|
|
From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
|
||
|
|
/home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc.cfg
|
||
|
|
/home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
|
||
|
|
Requested value: CONFIG_NR_CPUS=8
|
||
|
|
Actual value: CONFIG_NR_CPUS=1
|
||
|
|
|
||
|
|
|
||
|
|
---------- CONFIG_SCHED_SMT -----------------
|
||
|
|
Config: CONFIG_SCHED_SMT
|
||
|
|
From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
|
||
|
|
/home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
|
||
|
|
Requested value: CONFIG_SCHED_SMT=y
|
||
|
|
Actual value:
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
NOTE: Tasks Summary: Attempted 288 tasks of which 285 didn't need to be rerun and all succeeded.
|
||
|
|
|
||
|
|
Summary: There were 3 WARNING messages shown.
|
||
|
|
</literallayout>
|
||
|
|
<note>
|
||
|
|
The previous output example has artificial line breaks
|
||
|
|
to make it more readable.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The output describes the various problems that you can
|
||
|
|
encounter along with where to find the offending configuration
|
||
|
|
items.
|
||
|
|
You can use the information in the logs to adjust your
|
||
|
|
configuration files and then repeat the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configme'><filename>do_kernel_configme</filename></ulink>
|
||
|
|
and
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configcheck'><filename>do_kernel_configcheck</filename></ulink>
|
||
|
|
tasks until they produce no warnings.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
For more information on how to use the
|
||
|
|
<filename>menuconfig</filename> tool, see the
|
||
|
|
"<link linkend='using-menuconfig'>Using <filename>menuconfig</filename></link>"
|
||
|
|
section.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='fine-tuning-the-kernel-configuration-file'>
|
||
|
|
<title>Fine-Tuning the Kernel Configuration File</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
You can make sure the <filename>.config</filename> file is as
|
||
|
|
lean or efficient as possible by reading the output of the
|
||
|
|
kernel configuration fragment audit, noting any issues, making
|
||
|
|
changes to correct the issues, and then repeating.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
As part of the kernel build process, the
|
||
|
|
<filename>do_kernel_configcheck</filename> task runs.
|
||
|
|
This task validates the kernel configuration by checking the
|
||
|
|
final <filename>.config</filename> file against the input
|
||
|
|
files.
|
||
|
|
During the check, the task produces warning messages for the
|
||
|
|
following issues:
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>
|
||
|
|
Requested options that did not make the final
|
||
|
|
<filename>.config</filename> file.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
Configuration items that appear twice in the same
|
||
|
|
configuration fragment.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
Configuration items tagged as "required" that were
|
||
|
|
overridden.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
A board overrides a non-board specific option.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
Listed options not valid for the kernel being
|
||
|
|
processed.
|
||
|
|
In other words, the option does not appear anywhere.
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
<note>
|
||
|
|
The <filename>do_kernel_configcheck</filename> task can
|
||
|
|
also optionally report if an option is overridden during
|
||
|
|
processing.
|
||
|
|
</note>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
For each output warning, a message points to the file
|
||
|
|
that contains a list of the options and a pointer to the
|
||
|
|
configuration fragment that defines them.
|
||
|
|
Collectively, the files are the key to streamlining the
|
||
|
|
configuration.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To streamline the configuration, do the following:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Use a Working Configuration:</emphasis>
|
||
|
|
Start with a full configuration that you
|
||
|
|
know works.
|
||
|
|
Be sure the configuration builds and boots
|
||
|
|
successfully.
|
||
|
|
Use this configuration file as your baseline.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Run Configure and Check Tasks:</emphasis>
|
||
|
|
Separately run the
|
||
|
|
<filename>do_kernel_configme</filename> and
|
||
|
|
<filename>do_kernel_configcheck</filename> tasks:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ bitbake linux-yocto -c kernel_configme -f
|
||
|
|
$ bitbake linux-yocto -c kernel_configcheck -f
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Process the Results:</emphasis>
|
||
|
|
Take the resulting list of files from the
|
||
|
|
<filename>do_kernel_configcheck</filename> task
|
||
|
|
warnings and do the following:
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>
|
||
|
|
Drop values that are redefined in the fragment
|
||
|
|
but do not change the final
|
||
|
|
<filename>.config</filename> file.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
Analyze and potentially drop values from the
|
||
|
|
<filename>.config</filename> file that override
|
||
|
|
required configurations.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
Analyze and potentially remove non-board
|
||
|
|
specific options.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
Remove repeated and invalid options.
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Re-Run Configure and Check Tasks:</emphasis>
|
||
|
|
After you have worked through the output of the kernel
|
||
|
|
configuration audit, you can re-run the
|
||
|
|
<filename>do_kernel_configme</filename> and
|
||
|
|
<filename>do_kernel_configcheck</filename> tasks to
|
||
|
|
see the results of your changes.
|
||
|
|
If you have more issues, you can deal with them as
|
||
|
|
described in the previous step.
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Iteratively working through steps two through four eventually
|
||
|
|
yields a minimal, streamlined configuration file.
|
||
|
|
Once you have the best <filename>.config</filename>, you can
|
||
|
|
build the Linux Yocto kernel.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='expanding-variables'>
|
||
|
|
<title>Expanding Variables</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Sometimes it is helpful to determine what a variable expands
|
||
|
|
to during a build.
|
||
|
|
You can do examine the values of variables by examining the
|
||
|
|
output of the <filename>bitbake -e</filename> command.
|
||
|
|
The output is long and is more easily managed in a text file,
|
||
|
|
which allows for easy searches:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ bitbake -e virtual/kernel > <replaceable>some_text_file</replaceable>
|
||
|
|
</literallayout>
|
||
|
|
Within the text file, you can see exactly how each variable is
|
||
|
|
expanded and used by the OpenEmbedded build system.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='working-with-a-dirty-kernel-version-string'>
|
||
|
|
<title>Working with a "Dirty" Kernel Version String</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
If you build a kernel image and the version string has a
|
||
|
|
"+" or a "-dirty" at the end, uncommitted modifications exist
|
||
|
|
in the kernel's source directory.
|
||
|
|
Follow these steps to clean up the version string:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Discover the Uncommitted Changes:</emphasis>
|
||
|
|
Go to the kernel's locally cloned Git repository
|
||
|
|
(source directory) and use the following Git command
|
||
|
|
to list the files that have been changed, added, or
|
||
|
|
removed:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git status
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Commit the Changes:</emphasis>
|
||
|
|
You should commit those changes to the kernel source
|
||
|
|
tree regardless of whether or not you will save,
|
||
|
|
export, or use the changes:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git add
|
||
|
|
$ git commit -s -a -m "getting rid of -dirty"
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Rebuild the Kernel Image:</emphasis>
|
||
|
|
Once you commit the changes, rebuild the kernel.</para>
|
||
|
|
|
||
|
|
<para>Depending on your particular kernel development
|
||
|
|
workflow, the commands you use to rebuild the
|
||
|
|
kernel might differ.
|
||
|
|
For information on building the kernel image when
|
||
|
|
using <filename>devtool</filename>, see the
|
||
|
|
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
|
||
|
|
section.
|
||
|
|
For information on building the kernel image when
|
||
|
|
using Bitbake, see the
|
||
|
|
"<link linkend='using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</link>"
|
||
|
|
section.
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='working-with-your-own-sources'>
|
||
|
|
<title>Working With Your Own Sources</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
If you cannot work with one of the Linux kernel
|
||
|
|
versions supported by existing linux-yocto recipes, you can
|
||
|
|
still make use of the Yocto Project Linux kernel tooling by
|
||
|
|
working with your own sources.
|
||
|
|
When you use your own sources, you will not be able to
|
||
|
|
leverage the existing kernel
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> and
|
||
|
|
stabilization work of the linux-yocto sources.
|
||
|
|
However, you will be able to manage your own Metadata in the same
|
||
|
|
format as the linux-yocto sources.
|
||
|
|
Maintaining format compatibility facilitates converging with
|
||
|
|
linux-yocto on a future, mutually-supported kernel version.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To help you use your own sources, the Yocto Project provides a
|
||
|
|
linux-yocto custom recipe
|
||
|
|
(<filename>linux-yocto-custom.bb</filename>) that uses
|
||
|
|
<filename>kernel.org</filename> sources
|
||
|
|
and the Yocto Project Linux kernel tools for managing
|
||
|
|
kernel Metadata.
|
||
|
|
You can find this recipe in the
|
||
|
|
<filename>poky</filename> Git repository of the
|
||
|
|
Yocto Project <ulink url='&YOCTO_GIT_URL;'>Source Repository</ulink>
|
||
|
|
at:
|
||
|
|
<literallayout class="monospaced">
|
||
|
|
poky/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Here are some basic steps you can use to work with your own
|
||
|
|
sources:
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create a Copy of the Kernel Recipe:</emphasis>
|
||
|
|
Copy the <filename>linux-yocto-custom.bb</filename>
|
||
|
|
recipe to your layer and give it a meaningful name.
|
||
|
|
The name should include the version of the Yocto Linux
|
||
|
|
kernel you are using (e.g.
|
||
|
|
<filename>linux-yocto-myproject_4.12.bb</filename>,
|
||
|
|
where "4.12" is the base version of the Linux kernel
|
||
|
|
with which you would be working).
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create a Directory for Your Patches:</emphasis>
|
||
|
|
In the same directory inside your layer, create a matching
|
||
|
|
directory to store your patches and configuration files
|
||
|
|
(e.g. <filename>linux-yocto-myproject</filename>).
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Ensure You Have Configurations:</emphasis>
|
||
|
|
Make sure you have either a <filename>defconfig</filename>
|
||
|
|
file or configuration fragment files in your layer.
|
||
|
|
When you use the <filename>linux-yocto-custom.bb</filename>
|
||
|
|
recipe, you must specify a configuration.
|
||
|
|
If you do not have a <filename>defconfig</filename> file,
|
||
|
|
you can run the following:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ make defconfig
|
||
|
|
</literallayout>
|
||
|
|
After running the command, copy the resulting
|
||
|
|
<filename>.config</filename> file to the
|
||
|
|
<filename>files</filename> directory in your layer
|
||
|
|
as "defconfig" and then add it to the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
variable in the recipe.</para>
|
||
|
|
|
||
|
|
<para>Running the <filename>make defconfig</filename>
|
||
|
|
command results in the default configuration for your
|
||
|
|
architecture as defined by your kernel.
|
||
|
|
However, no guarantee exists that this configuration is
|
||
|
|
valid for your use case, or that your board will even boot.
|
||
|
|
This is particularly true for non-x86 architectures.</para>
|
||
|
|
|
||
|
|
<para>To use non-x86 <filename>defconfig</filename> files,
|
||
|
|
you need to be more specific and find one that matches your
|
||
|
|
board (i.e. for arm, you look in
|
||
|
|
<filename>arch/arm/configs</filename> and use the one that
|
||
|
|
is the best starting point for your board).
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Edit the Recipe:</emphasis>
|
||
|
|
Edit the following variables in your recipe as appropriate
|
||
|
|
for your project:
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>:
|
||
|
|
The <filename>SRC_URI</filename> should specify
|
||
|
|
a Git repository that uses one of the supported Git
|
||
|
|
fetcher protocols (i.e. <filename>file</filename>,
|
||
|
|
<filename>git</filename>, <filename>http</filename>,
|
||
|
|
and so forth).
|
||
|
|
The <filename>SRC_URI</filename> variable should
|
||
|
|
also specify either a <filename>defconfig</filename>
|
||
|
|
file or some configuration fragment files.
|
||
|
|
The skeleton recipe provides an example
|
||
|
|
<filename>SRC_URI</filename> as a syntax reference.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION'><filename>LINUX_VERSION</filename></ulink>:
|
||
|
|
The Linux kernel version you are using (e.g.
|
||
|
|
"4.12").
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION_EXTENSION'><filename>LINUX_VERSION_EXTENSION</filename></ulink>:
|
||
|
|
The Linux kernel
|
||
|
|
<filename>CONFIG_LOCALVERSION</filename> that is
|
||
|
|
compiled into the resulting kernel and visible
|
||
|
|
through the <filename>uname</filename> command.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>:
|
||
|
|
The commit ID from which you want to build.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>:
|
||
|
|
Treat this variable the same as you would in any
|
||
|
|
other recipe.
|
||
|
|
Increment the variable to indicate to the
|
||
|
|
OpenEmbedded build system that the recipe has
|
||
|
|
changed.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>:
|
||
|
|
The default <filename>PV</filename> assignment is
|
||
|
|
typically adequate.
|
||
|
|
It combines the <filename>LINUX_VERSION</filename>
|
||
|
|
with the Source Control Manager (SCM) revision
|
||
|
|
as derived from the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRCPV'><filename>SRCPV</filename></ulink>
|
||
|
|
variable.
|
||
|
|
The combined results are a string with the
|
||
|
|
following form:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
|
||
|
|
</literallayout>
|
||
|
|
While lengthy, the extra verbosity in
|
||
|
|
<filename>PV</filename> helps ensure you are using
|
||
|
|
the exact sources from which you intend to build.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>:
|
||
|
|
A list of the machines supported by your new recipe.
|
||
|
|
This variable in the example recipe is set
|
||
|
|
by default to a regular expression that matches
|
||
|
|
only the empty string, "(^$)".
|
||
|
|
This default setting triggers an explicit build
|
||
|
|
failure.
|
||
|
|
You must change it to match a list of the machines
|
||
|
|
that your new recipe supports.
|
||
|
|
For example, to support the
|
||
|
|
<filename>qemux86</filename> and
|
||
|
|
<filename>qemux86-64</filename> machines, use
|
||
|
|
the following form:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
COMPATIBLE_MACHINE = "qemux86|qemux86-64"
|
||
|
|
</literallayout>
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Customize Your Recipe as Needed:</emphasis>
|
||
|
|
Provide further customizations to your recipe
|
||
|
|
as needed just as you would customize an existing
|
||
|
|
linux-yocto recipe.
|
||
|
|
See the
|
||
|
|
"<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
|
||
|
|
section for information.
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='working-with-out-of-tree-modules'>
|
||
|
|
<title>Working with Out-of-Tree Modules</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
This section describes steps to build out-of-tree modules on
|
||
|
|
your target and describes how to incorporate out-of-tree modules
|
||
|
|
in the build.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<section id='building-out-of-tree-modules-on-the-target'>
|
||
|
|
<title>Building Out-of-Tree Modules on the Target</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
While the traditional Yocto Project development model would be
|
||
|
|
to include kernel modules as part of the normal build
|
||
|
|
process, you might find it useful to build modules on the
|
||
|
|
target.
|
||
|
|
This could be the case if your target system is capable
|
||
|
|
and powerful enough to handle the necessary compilation.
|
||
|
|
Before deciding to build on your target, however, you should
|
||
|
|
consider the benefits of using a proper cross-development
|
||
|
|
environment from your build host.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
If you want to be able to build out-of-tree modules on
|
||
|
|
the target, there are some steps you need to take
|
||
|
|
on the target that is running your SDK image.
|
||
|
|
Briefly, the <filename>kernel-dev</filename> package
|
||
|
|
is installed by default on all
|
||
|
|
<filename>*.sdk</filename> images and the
|
||
|
|
<filename>kernel-devsrc</filename> package is installed
|
||
|
|
on many of the <filename>*.sdk</filename> images.
|
||
|
|
However, you need to create some scripts prior to
|
||
|
|
attempting to build the out-of-tree modules on the target
|
||
|
|
that is running that image.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Prior to attempting to build the out-of-tree modules,
|
||
|
|
you need to be on the target as root and you need to
|
||
|
|
change to the <filename>/usr/src/kernel</filename> directory.
|
||
|
|
Next, <filename>make</filename> the scripts:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
# cd /usr/src/kernel
|
||
|
|
# make scripts
|
||
|
|
</literallayout>
|
||
|
|
Because all SDK image recipes include
|
||
|
|
<filename>dev-pkgs</filename>, the
|
||
|
|
<filename>kernel-dev</filename> packages will be installed
|
||
|
|
as part of the SDK image and the
|
||
|
|
<filename>kernel-devsrc</filename> packages will be installed
|
||
|
|
as part of applicable SDK images.
|
||
|
|
The SDK uses the scripts when building out-of-tree
|
||
|
|
modules.
|
||
|
|
Once you have switched to that directory and created the
|
||
|
|
scripts, you should be able to build your out-of-tree modules
|
||
|
|
on the target.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='incorporating-out-of-tree-modules'>
|
||
|
|
<title>Incorporating Out-of-Tree Modules</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
While it is always preferable to work with sources integrated
|
||
|
|
into the Linux kernel sources, if you need an external kernel
|
||
|
|
module, the <filename>hello-mod.bb</filename> recipe is
|
||
|
|
available as a template from which you can create your
|
||
|
|
own out-of-tree Linux kernel module recipe.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
This template recipe is located in the
|
||
|
|
<filename>poky</filename> Git repository of the
|
||
|
|
Yocto Project <ulink url='&YOCTO_GIT_URL;'>Source Repository</ulink>
|
||
|
|
at:
|
||
|
|
<literallayout class="monospaced">
|
||
|
|
poky/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To get started, copy this recipe to your layer and give it a
|
||
|
|
meaningful name (e.g. <filename>mymodule_1.0.bb</filename>).
|
||
|
|
In the same directory, create a new directory named
|
||
|
|
<filename>files</filename> where you can store any source files,
|
||
|
|
patches, or other files necessary for building
|
||
|
|
the module that do not come with the sources.
|
||
|
|
Finally, update the recipe as needed for the module.
|
||
|
|
Typically, you will need to set the following variables:
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-DESCRIPTION'><filename>DESCRIPTION</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE*</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Depending on the build system used by the module sources,
|
||
|
|
you might need to make some adjustments.
|
||
|
|
For example, a typical module <filename>Makefile</filename>
|
||
|
|
looks much like the one provided with the
|
||
|
|
<filename>hello-mod</filename> template:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
obj-m := hello.o
|
||
|
|
|
||
|
|
SRC := $(shell pwd)
|
||
|
|
|
||
|
|
all:
|
||
|
|
$(MAKE) -C $(KERNEL_SRC) M=$(SRC)
|
||
|
|
|
||
|
|
modules_install:
|
||
|
|
$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
|
||
|
|
...
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
The important point to note here is the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_SRC'><filename>KERNEL_SRC</filename></ulink>
|
||
|
|
variable.
|
||
|
|
The
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-module'><filename>module</filename></ulink>
|
||
|
|
class sets this variable and the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_PATH'><filename>KERNEL_PATH</filename></ulink>
|
||
|
|
variable to
|
||
|
|
<filename>${<ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></ulink>}</filename>
|
||
|
|
with the necessary Linux kernel build information to build
|
||
|
|
modules.
|
||
|
|
If your module <filename>Makefile</filename> uses a different
|
||
|
|
variable, you might want to override the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile()</filename></ulink>
|
||
|
|
step, or create a patch to
|
||
|
|
the <filename>Makefile</filename> to work with the more typical
|
||
|
|
<filename>KERNEL_SRC</filename> or
|
||
|
|
<filename>KERNEL_PATH</filename> variables.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
After you have prepared your recipe, you will likely want to
|
||
|
|
include the module in your images.
|
||
|
|
To do this, see the documentation for the following variables in
|
||
|
|
the Yocto Project Reference Manual and set one of them
|
||
|
|
appropriately for your machine configuration file:
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RDEPENDS'><filename>MACHINE_EXTRA_RDEPENDS</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS'><filename>MACHINE_EXTRA_RRECOMMENDS</filename></ulink>
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Modules are often not required for boot and can be excluded from
|
||
|
|
certain build configurations.
|
||
|
|
The following allows for the most flexibility:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
|
||
|
|
</literallayout>
|
||
|
|
The value is derived by appending the module filename without
|
||
|
|
the <filename>.ko</filename> extension to the string
|
||
|
|
"kernel-module-".
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Because the variable is
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>
|
||
|
|
and not a
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
|
||
|
|
variable, the build will not fail if this module is not
|
||
|
|
available to include in the image.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
|
||
|
|
<section id='inspecting-changes-and-commits'>
|
||
|
|
<title>Inspecting Changes and Commits</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
A common question when working with a kernel is:
|
||
|
|
"What changes have been applied to this tree?"
|
||
|
|
Rather than using "grep" across directories to see what has
|
||
|
|
changed, you can use Git to inspect or search the kernel tree.
|
||
|
|
Using Git is an efficient way to see what has changed in the tree.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<section id='what-changed-in-a-kernel'>
|
||
|
|
<title>What Changed in a Kernel?</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Following are a few examples that show how to use Git
|
||
|
|
commands to examine changes.
|
||
|
|
These examples are by no means the only way to see changes.
|
||
|
|
<note>
|
||
|
|
In the following examples, unless you provide a commit
|
||
|
|
range, <filename>kernel.org</filename> history is blended
|
||
|
|
with Yocto Project kernel changes.
|
||
|
|
You can form ranges by using branch names from the
|
||
|
|
kernel tree as the upper and lower commit markers with
|
||
|
|
the Git commands.
|
||
|
|
You can see the branch names through the web interface
|
||
|
|
to the Yocto Project source repositories at
|
||
|
|
<ulink url='http://git.yoctoproject.org/cgit.cgi'></ulink>.
|
||
|
|
</note>
|
||
|
|
To see a full range of the changes, use the
|
||
|
|
<filename>git whatchanged</filename> command and specify a
|
||
|
|
commit range for the branch
|
||
|
|
(<replaceable>commit</replaceable><filename>..</filename><replaceable>commit</replaceable>).
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Here is an example that looks at what has changed in the
|
||
|
|
<filename>emenlow</filename> branch of the
|
||
|
|
<filename>linux-yocto-3.19</filename> kernel.
|
||
|
|
The lower commit range is the commit associated with the
|
||
|
|
<filename>standard/base</filename> branch, while
|
||
|
|
the upper commit range is the commit associated with the
|
||
|
|
<filename>standard/emenlow</filename> branch.
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git whatchanged origin/standard/base..origin/standard/emenlow
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
To see short, one line summaries of changes use the
|
||
|
|
<filename>git log</filename> command:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git log --oneline origin/standard/base..origin/standard/emenlow
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Use this command to see code differences for the changes:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git diff origin/standard/base..origin/standard/emenlow
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Use this command to see the commit log messages and the
|
||
|
|
text differences:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git show origin/standard/base..origin/standard/emenlow
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Use this command to create individual patches for
|
||
|
|
each change.
|
||
|
|
Here is an example that that creates patch files for each
|
||
|
|
commit and places them in your <filename>Documents</filename>
|
||
|
|
directory:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='showing-a-particular-feature-or-branch-change'>
|
||
|
|
<title>Showing a Particular Feature or Branch Change</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Tags in the Yocto Project kernel tree divide changes for
|
||
|
|
significant features or branches.
|
||
|
|
The <filename>git show</filename> <replaceable>tag</replaceable>
|
||
|
|
command shows changes based on a tag.
|
||
|
|
Here is an example that shows <filename>systemtap</filename>
|
||
|
|
changes:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git show systemtap
|
||
|
|
</literallayout>
|
||
|
|
You can use the
|
||
|
|
<filename>git branch --contains</filename> <replaceable>tag</replaceable>
|
||
|
|
command to show the branches that contain a particular feature.
|
||
|
|
This command shows the branches that contain the
|
||
|
|
<filename>systemtap</filename> feature:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
$ git branch --contains systemtap
|
||
|
|
</literallayout>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section id='adding-recipe-space-kernel-features'>
|
||
|
|
<title>Adding Recipe-Space Kernel Features</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
You can add kernel features in the
|
||
|
|
<link linkend='recipe-space-metadata'>recipe-space</link> by
|
||
|
|
using the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
|
||
|
|
variable and by specifying the feature's <filename>.scc</filename>
|
||
|
|
file path in the
|
||
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
||
|
|
statement.
|
||
|
|
When you add features using this method, the OpenEmbedded build
|
||
|
|
system checks to be sure the features are present.
|
||
|
|
If the features are not present, the build stops.
|
||
|
|
Kernel features are the last elements processed for configuring
|
||
|
|
and patching the kernel.
|
||
|
|
Therefore, adding features in this manner is a way
|
||
|
|
to enforce specific features are present and enabled
|
||
|
|
without needing to do a full audit of any other layer's additions
|
||
|
|
to the <filename>SRC_URI</filename> statement.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
You add a kernel feature by providing the feature as part of the
|
||
|
|
<filename>KERNEL_FEATURES</filename> variable and by providing the
|
||
|
|
path to the feature's <filename>.scc</filename> file, which is
|
||
|
|
relative to the root of the kernel Metadata.
|
||
|
|
The OpenEmbedded build system searches all forms of kernel
|
||
|
|
Metadata on the <filename>SRC_URI</filename> statement regardless
|
||
|
|
of whether the Metadata is in the "kernel-cache", system kernel
|
||
|
|
Metadata, or a recipe-space Metadata (i.e. part of the kernel
|
||
|
|
recipe).
|
||
|
|
See the
|
||
|
|
"<link linkend='kernel-metadata-location'>Kernel Metadata Location</link>"
|
||
|
|
section for additional information.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
When you specify the feature's <filename>.scc</filename> file
|
||
|
|
on the <filename>SRC_URI</filename> statement, the OpenEmbedded
|
||
|
|
build system adds the directory of that
|
||
|
|
<filename>.scc</filename> file along with all its subdirectories
|
||
|
|
to the kernel feature search path.
|
||
|
|
Because subdirectories are searched, you can reference a single
|
||
|
|
<filename>.scc</filename> file in the
|
||
|
|
<filename>SRC_URI</filename> statement to reference multiple kernel
|
||
|
|
features.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Consider the following example that adds the "test.scc" feature
|
||
|
|
to the build.
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Create the Feature File:</emphasis>
|
||
|
|
Create a <filename>.scc</filename> file and locate it
|
||
|
|
just as you would any other patch file,
|
||
|
|
<filename>.cfg</filename> file, or fetcher item
|
||
|
|
you specify in the <filename>SRC_URI</filename>
|
||
|
|
statement.
|
||
|
|
<note><title>Notes</title>
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>
|
||
|
|
You must add the directory of the
|
||
|
|
<filename>.scc</filename> file to the fetcher's
|
||
|
|
search path in the same manner as you would
|
||
|
|
add a <filename>.patch</filename> file.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
You can create additional
|
||
|
|
<filename>.scc</filename> files beneath the
|
||
|
|
directory that contains the file you are
|
||
|
|
adding.
|
||
|
|
All subdirectories are searched during the
|
||
|
|
build as potential feature directories.
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</note>
|
||
|
|
Continuing with the example, suppose the "test.scc"
|
||
|
|
feature you are adding has a
|
||
|
|
<filename>test.scc</filename> file in the following
|
||
|
|
directory:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
<replaceable>my_recipe</replaceable>
|
||
|
|
|
|
||
|
|
+-linux-yocto
|
||
|
|
|
|
||
|
|
+-test.cfg
|
||
|
|
+-test.scc
|
||
|
|
</literallayout>
|
||
|
|
In this example, the <filename>linux-yocto</filename>
|
||
|
|
directory has both the feature
|
||
|
|
<filename>test.scc</filename> file and a similarly
|
||
|
|
named configuration fragment file
|
||
|
|
<filename>test.cfg</filename>.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Add the Feature File to <filename>SRC_URI</filename>:</emphasis>
|
||
|
|
Add the <filename>.scc</filename> file to the
|
||
|
|
recipe's <filename>SRC_URI</filename> statement:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
SRC_URI_append = " file://test.scc"
|
||
|
|
</literallayout>
|
||
|
|
The leading space before the path is important as the
|
||
|
|
path is appended to the existing path.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Specify the Feature as a Kernel Feature:</emphasis>
|
||
|
|
Use the <filename>KERNEL_FEATURES</filename> statement
|
||
|
|
to specify the feature as a kernel feature:
|
||
|
|
<literallayout class='monospaced'>
|
||
|
|
KERNEL_FEATURES_append = " test.scc"
|
||
|
|
</literallayout>
|
||
|
|
The OpenEmbedded build system processes the kernel feature
|
||
|
|
when it builds the kernel.
|
||
|
|
<note>
|
||
|
|
If other features are contained below "test.scc",
|
||
|
|
then their directories are relative to the directory
|
||
|
|
containing the <filename>test.scc</filename> file.
|
||
|
|
</note>
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</chapter>
|
||
|
|
<!--
|
||
|
|
vim: expandtab tw=80 ts=4
|
||
|
|
-->
|