summaryrefslogtreecommitdiff
path: root/poky/documentation/kernel-dev/common.rst
diff options
context:
space:
mode:
Diffstat (limited to 'poky/documentation/kernel-dev/common.rst')
-rw-r--r--poky/documentation/kernel-dev/common.rst29
1 files changed, 19 insertions, 10 deletions
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index 3f35d8412..f64cbab56 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -338,7 +338,7 @@ section:
the ``yocto-4.12`` branch.
The following commands show how to create a local copy of the
- ``yocto-kernel-cache`` and be in the ``yocto-4.12`` branch::
+ ``yocto-kernel-cache`` and switch to the ``yocto-4.12`` branch::
$ cd ~
$ git clone git://git.yoctoproject.org/yocto-kernel-cache --branch yocto-4.12
@@ -491,7 +491,7 @@ As an example, consider the following append file used by the BSPs in
meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend
-The following listing shows the file. Be aware that the actual commit ID
+Here are the contents of this file. Be aware that the actual commit ID
strings in this example listing might be different than the actual
strings in the file from the ``meta-yocto-bsp`` layer upstream.
::
@@ -578,7 +578,7 @@ recipe is processed.
.. note::
- Other methods exist to accomplish grouping and defining configuration
+ There are other ways of grouping and defining configuration
options. For example, if you are working with a local clone of the
kernel repository, you could checkout the kernel's ``meta`` branch,
make your changes, and then push the changes to the local bare clone
@@ -589,8 +589,8 @@ recipe is processed.
In general, however, the Yocto Project maintainers take care of
moving the ``SRC_URI``-specified configuration options to the
- kernel's ``meta`` branch. Not only is it easier for BSP developers to
- not have to worry about putting those configurations in the branch,
+ kernel's ``meta`` branch. Not only is it easier for BSP developers
+ not to have to put 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
@@ -650,6 +650,15 @@ extends the :term:`FILESPATH`
variable (search directories) to include the ``${PN}`` directory you
created to hold the configuration changes.
+You can also use a regular ``defconfig`` file, as generated by the
+:ref:`ref-tasks-savedefconfig`
+task instead of a complete ``.config`` file. This only specifies the
+non-default configuration values. You need to additionally set
+:term:`KCONFIG_MODE`
+in the linux-yocto ``.bbappend`` file in your layer::
+
+ KCONFIG_MODE = "alldefconfig"
+
.. note::
The build system applies the configurations from the ``defconfig``
@@ -772,8 +781,8 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
.. note::
- During the checkout operation, a bug exists that could cause
- errors such as the following to appear:
+ During the checkout operation, there is a bug that could cause
+ errors such as the following:
.. code-block:: none
@@ -1297,7 +1306,7 @@ steps:
$ bitbake linux-yocto -c kernel_configme -f
This step ensures that you create a
- ``.config`` file from a known state. Because situations exist where
+ ``.config`` file from a known state. Because there are situations where
your build state might become unknown, it is best to run this task
prior to starting ``menuconfig``.
@@ -1527,7 +1536,7 @@ Working with a "Dirty" Kernel Version String
============================================
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
+"-dirty" at the end, it means there are uncommitted modifications in the kernel's
source directory. Follow these steps to clean up the version string:
1. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned
@@ -1606,7 +1615,7 @@ Here are some basic steps you can use to work with your own sources:
Running the ``make defconfig`` command results in the default
configuration for your architecture as defined by your kernel.
- However, no guarantee exists that this configuration is valid for
+ However, there is no guarantee that this configuration is valid for
your use case, or that your board will even boot. This is
particularly true for non-x86 architectures.