mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-09-13 09:49:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

sphinx: kernel-dev: Various URL, code block and other fixes to imported data

Browse Source 
(From yocto-docs rev: 4888b49ccc5d133b4096e5a9b808f14d1afc7deb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Richard Purdie
2020-09-14 16:19:23 +01:00
parent de89b5a0b6
commit cb37a15cf5
6 changed files with 1181 additions and 555 deletions
Download Patch File Download Diff File Expand all files Collapse all files

461
documentation/kernel-dev/kernel-dev-advanced.rst
View File

@@ -17,9 +17,9 @@ the Metadata and the tools that manage it is to help you manage the
complexity of the configuration and sources used to support multiple complexity of the configuration and sources used to support multiple
BSPs and Linux kernel types. BSPs and Linux kernel types.
Kernel Metadata exists in many places. One area in the Yocto Project Kernel Metadata exists in many places. One area in the
`Source Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ is the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
``yocto-kernel-cache`` Git repository. You can find this repository is the ``yocto-kernel-cache`` Git repository. You can find this repository
grouped under the "Yocto Linux Kernel" heading in the grouped under the "Yocto Linux Kernel" heading in the
:yocto_git:`Yocto Project Source Repositories <>`. :yocto_git:`Yocto Project Source Repositories <>`.
@@ -82,7 +82,11 @@ to indicate the branch.
The linux-yocto style recipes can optionally define the following The linux-yocto style recipes can optionally define the following
variables: KERNEL_FEATURES LINUX_KERNEL_TYPE variables:
- :term:`KERNEL_FEATURES`
- :term:`LINUX_KERNEL_TYPE`
:term:`LINUX_KERNEL_TYPE` :term:`LINUX_KERNEL_TYPE`
defines the kernel type to be used in assembling the configuration. If defines the kernel type to be used in assembling the configuration. If
@@ -111,9 +115,18 @@ variable to include features (configuration fragments, patches, or both)
that are not already included by the ``KMACHINE`` and that are not already included by the ``KMACHINE`` and
``LINUX_KERNEL_TYPE`` variable combination. For example, to include a ``LINUX_KERNEL_TYPE`` variable combination. For example, to include a
feature specified as "features/netfilter/netfilter.scc", specify: feature specified as "features/netfilter/netfilter.scc", specify:
KERNEL_FEATURES += "features/netfilter/netfilter.scc" To include a ::
KERNEL_FEATURES += "features/netfilter/netfilter.scc"
To include a
feature called "cfg/sound.scc" just for the ``qemux86`` machine, feature called "cfg/sound.scc" just for the ``qemux86`` machine,
specify: KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc" The value of specify:
::
KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
The value of
the entries in ``KERNEL_FEATURES`` are dependent on their location the entries in ``KERNEL_FEATURES`` are dependent on their location
within the kernel Metadata itself. The examples here are taken from the within the kernel Metadata itself. The examples here are taken from the
``yocto-kernel-cache`` repository. Each branch of this repository ``yocto-kernel-cache`` repository. Each branch of this repository
@@ -125,7 +138,7 @@ Kernel Metadata Syntax
====================== ======================
The kernel Metadata consists of three primary types of files: ``scc`` The kernel Metadata consists of three primary types of files: ``scc``
[1]_ description files, configuration fragments, and patches. The [1]_ description files, configuration fragments, and patches. The
``scc`` files define variables and include or otherwise reference any of ``scc`` files define variables and include or otherwise reference any of
the three file types. The description files are used to aggregate all the three file types. The description files are used to aggregate all
types of kernel Metadata into what ultimately describes the sources and types of kernel Metadata into what ultimately describes the sources and
@@ -152,8 +165,15 @@ types to form the final description of what will be assembled and built.
While the kernel Metadata syntax does not enforce any logical separation While the kernel Metadata syntax does not enforce any logical separation
of configuration fragments, patches, features or kernel types, best of configuration fragments, patches, features or kernel types, best
practices dictate a logical separation of these types of Metadata. The practices dictate a logical separation of these types of Metadata. The
following Metadata file hierarchy is recommended: base/ bsp/ cfg/ following Metadata file hierarchy is recommended:
features/ ktypes/ patches/ ::
base/
bsp/
cfg/
features/
ktypes/
patches/
The ``bsp`` directory contains the `BSP The ``bsp`` directory contains the `BSP
descriptions <#bsp-descriptions>`__. The remaining directories all descriptions <#bsp-descriptions>`__. The remaining directories all
@@ -192,6 +212,11 @@ or the top level of
if you are creating `Metadata outside of the if you are creating `Metadata outside of the
recipe-space <#metadata-outside-the-recipe-space>`__. recipe-space <#metadata-outside-the-recipe-space>`__.
.. [1]
``scc`` stands for Series Configuration Control, but the naming has
less significance in the current implementation of the tooling than
it had in the past. Consider ``scc`` files to be description files.
Configuration Configuration
------------- -------------
@@ -205,15 +230,27 @@ used with the ``linux-yocto-4.12`` kernel as defined outside of the
recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of
two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the
``cfg`` directory of the ``yocto-4.12`` branch in the ``cfg`` directory of the ``yocto-4.12`` branch in the
``yocto-kernel-cache`` Git repository: cfg/smp.scc: define ``yocto-kernel-cache`` Git repository:
KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds" define ::
KFEATURE_COMPATIBILITY all kconf hardware smp.cfg cfg/smp.cfg:
CONFIG_SMP=y CONFIG_SCHED_SMT=y # Increase default NR_CPUS from 8 to 64 cfg/smp.scc:
so that platform with # more than 8 processors can be all activated at define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds"
boot time CONFIG_NR_CPUS=64 # The following is needed when setting define KFEATURE_COMPATIBILITY all
NR_CPUS to something # greater than 8 on x86 architectures, it should be
automatically # disregarded by Kconfig when using a different arch kconf hardware smp.cfg
CONFIG_X86_BIGSMP=y You can find general information on configuration
cfg/smp.cfg:
CONFIG_SMP=y
CONFIG_SCHED_SMT=y
# Increase default NR_CPUS from 8 to 64 so that platform with
# more than 8 processors can be all activated at boot time
CONFIG_NR_CPUS=64
# The following is needed when setting NR_CPUS to something
# greater than 8 on x86 architectures, it should be automatically
# disregarded by Kconfig when using a different arch
CONFIG_X86_BIGSMP=y
You can find general information on configuration
fragment files in the "`Creating Configuration fragment files in the "`Creating Configuration
Fragments <#creating-config-fragments>`__" section. Fragments <#creating-config-fragments>`__" section.
@@ -238,8 +275,10 @@ non-hardware fragment.
As described in the "`Validating As described in the "`Validating
Configuration <#validating-configuration>`__" section, you can use the Configuration <#validating-configuration>`__" section, you can use the
following BitBake command to audit your configuration: $ bitbake following BitBake command to audit your configuration:
linux-yocto -c kernel_configcheck -f ::
$ bitbake linux-yocto -c kernel_configcheck -f
Patches Patches
------- -------
@@ -258,20 +297,38 @@ in the ``patches/build`` directory of the ``yocto-4.12`` branch in the
``yocto-kernel-cache`` Git repository. ``yocto-kernel-cache`` Git repository.
The following listings show the ``build.scc`` file and part of the The following listings show the ``build.scc`` file and part of the
``modpost-mask-trivial-warnings.patch`` file: patches/build/build.scc: ``modpost-mask-trivial-warnings.patch`` file:
patch arm-serialize-build-targets.patch patch ::
powerpc-serialize-image-targets.patch patch
kbuild-exclude-meta-directory-from-distclean-processi.patch # applied by patches/build/build.scc:
kgit # patch kbuild-add-meta-files-to-the-ignore-li.patch patch patch arm-serialize-build-targets.patch
modpost-mask-trivial-warnings.patch patch patch powerpc-serialize-image-targets.patch
menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch patch kbuild-exclude-meta-directory-from-distclean-processi.patch
patches/build/modpost-mask-trivial-warnings.patch: From
bd48931bc142bdd104668f3a062a1f22600aae61 Mon Sep 17 00:00:00 2001 From: # applied by kgit
Paul Gortmaker <paul.gortmaker@windriver.com> Date: Sun, 25 Jan 2009 # patch kbuild-add-meta-files-to-the-ignore-li.patch
17:58:09 -0500 Subject: [PATCH] modpost: mask trivial warnings Newer
HOSTCC will complain about various stdio fcns because . . . char patch modpost-mask-trivial-warnings.patch
\*dump_write = NULL, \*files_source = NULL; int opt; -- 2.10.1 generated patch menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch
by cgit v0.10.2 at 2017-09-28 15:23:23 (GMT) The description file can
patches/build/modpost-mask-trivial-warnings.patch:
From bd48931bc142bdd104668f3a062a1f22600aae61 Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Sun, 25 Jan 2009 17:58:09 -0500
Subject: [PATCH] modpost: mask trivial warnings
Newer HOSTCC will complain about various stdio fcns because
.
.
.
char *dump_write = NULL, *files_source = NULL;
int opt;
--
2.10.1
generated by cgit v0.10.2 at 2017-09-28 15:23:23 (GMT)
The description file can
include multiple patch statements where each statement handles a single include multiple patch statements where each statement handles a single
patch. In the example ``build.scc`` file, five patch statements exist patch. In the example ``build.scc`` file, five patch statements exist
for the five patches in the directory. for the five patches in the directory.
@@ -289,11 +346,19 @@ Features
Features are complex kernel Metadata types that consist of configuration Features are complex kernel Metadata types that consist of configuration
fragments, patches, and possibly other feature description files. As an fragments, patches, and possibly other feature description files. As an
example, consider the following generic listing: features/myfeature.scc example, consider the following generic listing:
define KFEATURE_DESCRIPTION "Enable myfeature" patch ::
0001-myfeature-core.patch patch 0002-myfeature-interface.patch include
cfg/myfeature_dependency.scc kconf non-hardware myfeature.cfg This features/myfeature.scc
example shows how the ``patch`` and ``kconf`` commands are used as well define KFEATURE_DESCRIPTION "Enable myfeature"
patch 0001-myfeature-core.patch
patch 0002-myfeature-interface.patch
include cfg/myfeature_dependency.scc
kconf non-hardware myfeature.cfg
This example shows how the ``patch`` and ``kconf`` commands are used as well
as how an additional feature description file is included with the as how an additional feature description file is included with the
``include`` command. ``include`` command.
@@ -319,11 +384,16 @@ the ``linux-yocto_4.12.bb`` kernel recipe found in
:ref:`require <bitbake:require-inclusion>` directive :ref:`require <bitbake:require-inclusion>` directive
includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file, includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
which has the following statement that defines the default kernel type: which has the following statement that defines the default kernel type:
LINUX_KERNEL_TYPE ??= "standard" ::
LINUX_KERNEL_TYPE ??= "standard"
Another example would be the real-time kernel (i.e. Another example would be the real-time kernel (i.e.
``linux-yocto-rt_4.12.bb``). This kernel recipe directly sets the kernel ``linux-yocto-rt_4.12.bb``). This kernel recipe directly sets the kernel
type as follows: LINUX_KERNEL_TYPE = "preempt-rt" type as follows:
::
LINUX_KERNEL_TYPE = "preempt-rt"
.. note:: .. note::
@@ -358,16 +428,36 @@ for Linux Yocto kernels:
For any given kernel type, the Metadata is defined by the ``.scc`` (e.g. For any given kernel type, the Metadata is defined by the ``.scc`` (e.g.
``standard.scc``). Here is a partial listing for the ``standard.scc`` ``standard.scc``). Here is a partial listing for the ``standard.scc``
file, which is found in the ``ktypes/standard`` directory of the file, which is found in the ``ktypes/standard`` directory of the
``yocto-kernel-cache`` Git repository: # Include this kernel type ``yocto-kernel-cache`` Git repository:
fragment to get the standard features and # configuration values. # ::
Note: if only the features are desired, but not the configuration # then
this should be included as: # include ktypes/standard/standard.scc nocfg # Include this kernel type fragment to get the standard features and
# if no chained configuration is desired, include it as: # include # configuration values.
ktypes/standard/standard.scc nocfg inherit include ktypes/base/base.scc
branch standard kconf non-hardware standard.cfg include # Note: if only the features are desired, but not the configuration
features/kgdb/kgdb.scc . . . include cfg/net/ip6_nf.scc include # then this should be included as:
cfg/net/bridge.scc include cfg/systemd.scc include # include ktypes/standard/standard.scc nocfg
features/rfkill/rfkill.scc # if no chained configuration is desired, include it as:
# include ktypes/standard/standard.scc nocfg inherit
include ktypes/base/base.scc
branch standard
kconf non-hardware standard.cfg
include features/kgdb/kgdb.scc
.
.
.
include cfg/net/ip6_nf.scc
include cfg/net/bridge.scc
include cfg/systemd.scc
include features/rfkill/rfkill.scc
As with any ``.scc`` file, a kernel type definition can aggregate other As with any ``.scc`` file, a kernel type definition can aggregate other
``.scc`` files with ``include`` commands. These definitions can also ``.scc`` files with ``include`` commands. These definitions can also
@@ -409,29 +499,49 @@ supported kernel type.
This section overviews the BSP description structure, the aggregation This section overviews the BSP description structure, the aggregation
concepts, and presents a detailed example using a BSP supported by the concepts, and presents a detailed example using a BSP supported by the
Yocto Project (i.e. BeagleBone Board). For complete information on BSP Yocto Project (i.e. BeagleBone Board). For complete information on BSP
layer file hierarchy, see the `Yocto Project Board Support Package (BSP) layer file hierarchy, see the :doc:`../bsp-guide/bsp-guide`.
Developer's Guide <&YOCTO_DOCS_BSP_URL;>`__.
.. _bsp-description-file-overview: .. _bsp-description-file-overview:
Overview Description Overview
~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
For simplicity, consider the following root BSP layer description files For simplicity, consider the following root BSP layer description files
for the BeagleBone board. These files employ both a structure and naming for the BeagleBone board. These files employ both a structure and naming
convention for consistency. The naming convention for the file is as convention for consistency. The naming convention for the file is as
follows: bsp_root_name-kernel_type.scc Here are some example root layer follows:
::
bsp_root_name-kernel_type.scc
Here are some example root layer
BSP filenames for the BeagleBone Board BSP, which is supported by the BSP filenames for the BeagleBone Board BSP, which is supported by the
Yocto Project: beaglebone-standard.scc beaglebone-preempt-rt.scc Each Yocto Project:
file uses the root name (i.e "beaglebone") BSP name followed by the ::
beaglebone-standard.scc
beaglebone-preempt-rt.scc
Each file uses the root name (i.e "beaglebone") BSP name followed by the
kernel type. kernel type.
Examine the ``beaglebone-standard.scc`` file: define KMACHINE beaglebone Examine the ``beaglebone-standard.scc`` file:
define KTYPE standard define KARCH arm include ::
ktypes/standard/standard.scc branch beaglebone include beaglebone.scc #
default policy for standard kernels include define KMACHINE beaglebone
features/latencytop/latencytop.scc include define KTYPE standard
features/profiling/profiling.scc Every top-level BSP description file define KARCH arm
include ktypes/standard/standard.scc
branch beaglebone
include beaglebone.scc
# default policy for standard kernels
include features/latencytop/latencytop.scc
include features/profiling/profiling.scc
Every top-level BSP description file
should define the :term:`KMACHINE`, should define the :term:`KMACHINE`,
:term:`KTYPE`, and :term:`KTYPE`, and
:term:`KARCH` variables. These :term:`KARCH` variables. These
@@ -450,27 +560,52 @@ description file match.
To separate your kernel policy from your hardware configuration, you To separate your kernel policy from your hardware configuration, you
include a kernel type (``ktype``), such as "standard". In the previous include a kernel type (``ktype``), such as "standard". In the previous
example, this is done using the following: include example, this is done using the following:
ktypes/standard/standard.scc This file aggregates all the configuration ::
include ktypes/standard/standard.scc
This file aggregates all the configuration
fragments, patches, and features that make up your standard kernel fragments, patches, and features that make up your standard kernel
policy. See the "`Kernel Types <#kernel-types>`__" section for more policy. See the "`Kernel Types <#kernel-types>`__" section for more
information. information.
To aggregate common configurations and features specific to the kernel To aggregate common configurations and features specific to the kernel
for mybsp, use the following: include mybsp.scc You can see that in the for mybsp, use the following:
BeagleBone example with the following: include beaglebone.scc For ::
information on how to break a complete ``.config`` file into the various
include mybsp.scc
You can see that in the BeagleBone example with the following:
::
include beaglebone.scc
For information on how to break a complete ``.config`` file into the various
configuration fragments, see the "`Creating Configuration configuration fragments, see the "`Creating Configuration
Fragments <#creating-config-fragments>`__" section. Fragments <#creating-config-fragments>`__" section.
Finally, if you have any configurations specific to the hardware that Finally, if you have any configurations specific to the hardware that
are not in a ``*.scc`` file, you can include them as follows: kconf are not in a ``*.scc`` file, you can include them as follows:
hardware mybsp-extra.cfg The BeagleBone example does not include these ::
kconf hardware mybsp-extra.cfg
The BeagleBone example does not include these
types of configurations. However, the Malta 32-bit board does types of configurations. However, the Malta 32-bit board does
("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file: ("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file:
define KMACHINE mti-malta32-le define KMACHINE qemumipsel define KTYPE ::
standard define KARCH mips include ktypes/standard/standard.scc branch
mti-malta32 include mti-malta32.scc kconf hardware mti-malta32-le.cfg define KMACHINE mti-malta32-le
define KMACHINE qemumipsel
define KTYPE standard
define KARCH mips
include ktypes/standard/standard.scc
branch mti-malta32
include mti-malta32.scc
kconf hardware mti-malta32-le.cfg
.. _bsp-description-file-example-minnow: .. _bsp-description-file-example-minnow:
@@ -488,15 +623,28 @@ definition given the ``linux-yocto-4.4`` branch of the
Although the Minnow Board BSP is unused, the Metadata remains and is Although the Minnow Board BSP is unused, the Metadata remains and is
being used here just as an example. being used here just as an example.
include cfg/x86.scc include features/eg20t/eg20t.scc include ::
cfg/dmaengine.scc include features/power/intel.scc include cfg/efi.scc
include features/usb/ehci-hcd.scc include features/usb/ohci-hcd.scc include cfg/x86.scc
include features/usb/usb-gadgets.scc include include features/eg20t/eg20t.scc
features/usb/touchscreen-composite.scc include cfg/timer/hpet.scc include cfg/dmaengine.scc
include features/leds/leds.scc include features/spi/spidev.scc include include features/power/intel.scc
features/i2c/i2cdev.scc include features/mei/mei-txe.scc # Earlyprintk include cfg/efi.scc
and port debug requires 8250 kconf hardware cfg/8250.cfg kconf hardware include features/usb/ehci-hcd.scc
minnow.cfg kconf hardware minnow-dev.cfg include features/usb/ohci-hcd.scc
include features/usb/usb-gadgets.scc
include features/usb/touchscreen-composite.scc
include cfg/timer/hpet.scc
include features/leds/leds.scc
include features/spi/spidev.scc
include features/i2c/i2cdev.scc
include features/mei/mei-txe.scc
# Earlyprintk and port debug requires 8250
kconf hardware cfg/8250.cfg
kconf hardware minnow.cfg
kconf hardware minnow-dev.cfg
The ``minnow.scc`` description file includes a hardware configuration The ``minnow.scc`` description file includes a hardware configuration
fragment (``minnow.cfg``) specific to the Minnow BSP as well as several fragment (``minnow.cfg``) specific to the Minnow BSP as well as several
@@ -505,23 +653,51 @@ found on the machine. This ``minnow.scc`` description file is then
included in each of the three "minnow" description files for the included in each of the three "minnow" description files for the
supported kernel types (i.e. "standard", "preempt-rt", and "tiny"). supported kernel types (i.e. "standard", "preempt-rt", and "tiny").
Consider the "minnow" description for the "standard" kernel type (i.e. Consider the "minnow" description for the "standard" kernel type (i.e.
``minnow-standard.scc``: define KMACHINE minnow define KTYPE standard ``minnow-standard.scc``:
define KARCH i386 include ktypes/standard include minnow.scc # Extra ::
minnow configs above the minimal defined in minnow.scc include
cfg/efi-ext.scc include features/media/media-all.scc include define KMACHINE minnow
features/sound/snd_hda_intel.scc # The following should really be in define KTYPE standard
standard.scc # USB live-image support include cfg/usb-mass-storage.scc define KARCH i386
include cfg/boot-live.scc # Basic profiling include
features/latencytop/latencytop.scc include include ktypes/standard
features/profiling/profiling.scc # Requested drivers that don't have an
existing scc kconf hardware minnow-drivers-extra.cfg The ``include`` include minnow.scc
command midway through the file includes the ``minnow.scc`` description
# Extra minnow configs above the minimal defined in minnow.scc
include cfg/efi-ext.scc
include features/media/media-all.scc
include features/sound/snd_hda_intel.scc
# The following should really be in standard.scc
# USB live-image support
include cfg/usb-mass-storage.scc
include cfg/boot-live.scc
# Basic profiling
include features/latencytop/latencytop.scc
include features/profiling/profiling.scc
# Requested drivers that don't have an existing scc
kconf hardware minnow-drivers-extra.cfg
The ``include`` command midway through the file includes the ``minnow.scc`` description
that defines all enabled hardware for the BSP that is common to all that defines all enabled hardware for the BSP that is common to all
kernel types. Using this command significantly reduces duplication. kernel types. Using this command significantly reduces duplication.
Now consider the "minnow" description for the "tiny" kernel type (i.e. Now consider the "minnow" description for the "tiny" kernel type (i.e.
``minnow-tiny.scc``): define KMACHINE minnow define KTYPE tiny define ``minnow-tiny.scc``):
KARCH i386 include ktypes/tiny include minnow.scc As you might expect, ::
define KMACHINE minnow
define KTYPE tiny
define KARCH i386
include ktypes/tiny
include minnow.scc
As you might expect,
the "tiny" description includes quite a bit less. In fact, it includes the "tiny" description includes quite a bit less. In fact, it includes
only the minimal policy defined by the "tiny" kernel type and the only the minimal policy defined by the "tiny" kernel type and the
hardware-specific configuration required for booting the machine along hardware-specific configuration required for booting the machine along
@@ -574,9 +750,16 @@ See the "`Modifying an Existing
Recipe <#modifying-an-existing-recipe>`__" section for more information. Recipe <#modifying-an-existing-recipe>`__" section for more information.
Here is an example that shows a trivial tree of kernel Metadata stored Here is an example that shows a trivial tree of kernel Metadata stored
in recipe-space within a BSP layer: meta-my_bsp_layer/ \`-- in recipe-space within a BSP layer:
recipes-kernel \`-- linux \`-- linux-yocto \|-- bsp-standard.scc \|-- ::
bsp.cfg \`-- standard.cfg
meta-my_bsp_layer/
`-- recipes-kernel
`-- linux
`-- linux-yocto
|-- bsp-standard.scc
|-- bsp.cfg
`-- standard.cfg
When the Metadata is stored in recipe-space, you must take steps to When the Metadata is stored in recipe-space, you must take steps to
ensure BitBake has the necessary information to decide what files to ensure BitBake has the necessary information to decide what files to
@@ -591,8 +774,12 @@ value when changing the content of files not explicitly listed in the
If the BSP description is in recipe space, you cannot simply list the If the BSP description is in recipe space, you cannot simply list the
``*.scc`` in the ``SRC_URI`` statement. You need to use the following ``*.scc`` in the ``SRC_URI`` statement. You need to use the following
form from your kernel append file: SRC_URI_append_myplatform = " \\ form from your kernel append file:
file://myplatform;type=kmeta;destsuffix=myplatform \\ " ::
SRC_URI_append_myplatform = " \
file://myplatform;type=kmeta;destsuffix=myplatform \
"
Metadata Outside the Recipe-Space Metadata Outside the Recipe-Space
--------------------------------- ---------------------------------
@@ -602,10 +789,13 @@ reside in a separate repository. The OpenEmbedded build system adds the
Metadata to the build as a "type=kmeta" repository through the Metadata to the build as a "type=kmeta" repository through the
:term:`SRC_URI` variable. As an :term:`SRC_URI` variable. As an
example, consider the following ``SRC_URI`` statement from the example, consider the following ``SRC_URI`` statement from the
``linux-yocto_4.12.bb`` kernel recipe: SRC_URI = ``linux-yocto_4.12.bb`` kernel recipe:
"git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; ::
\\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
``${KMETA}``, in this context, is simply used to name the directory into ``${KMETA}``, in this context, is simply used to name the directory into
which the Git fetcher places the Metadata. This behavior is no different which the Git fetcher places the Metadata. This behavior is no different
than any multi-repository ``SRC_URI`` statement used in a recipe (e.g. than any multi-repository ``SRC_URI`` statement used in a recipe (e.g.
@@ -684,21 +874,43 @@ patches into a feature.
Once you have a new branch, you can set up your kernel Metadata to use Once you have a new branch, you can set up your kernel Metadata to use
the branch a couple different ways. In the recipe, you can specify the the branch a couple different ways. In the recipe, you can specify the
new branch as the ``KBRANCH`` to use for the board as follows: KBRANCH = new branch as the ``KBRANCH`` to use for the board as follows:
"mynewbranch" Another method is to use the ``branch`` command in the BSP ::
description: mybsp.scc: define KMACHINE mybsp define KTYPE standard
define KARCH i386 include standard.scc branch mynewbranch include KBRANCH = "mynewbranch"
mybsp-hw.scc
Another method is to use the ``branch`` command in the BSP
description:
mybsp.scc:
define KMACHINE mybsp
define KTYPE standard
define KARCH i386
include standard.scc
branch mynewbranch
include mybsp-hw.scc
If you find yourself with numerous branches, you might consider using a If you find yourself with numerous branches, you might consider using a
hierarchical branching system similar to what the Yocto Linux Kernel Git hierarchical branching system similar to what the Yocto Linux Kernel Git
repositories use: common/kernel_type/machine repositories use:
::
common/kernel_type/machine
If you had two kernel types, "standard" and "small" for instance, three If you had two kernel types, "standard" and "small" for instance, three
machines, and common as ``mydir``, the branches in your Git repository machines, and common as ``mydir``, the branches in your Git repository
might look like this: mydir/base mydir/standard/base might look like this:
mydir/standard/machine_a mydir/standard/machine_b :
mydir/standard/machine_c mydir/small/base mydir/small/machine_a
mydir/base
mydir/standard/base
mydir/standard/machine_a
mydir/standard/machine_b
mydir/standard/machine_c
mydir/small/base
mydir/small/machine_a
This organization can help clarify the branch relationships. In this This organization can help clarify the branch relationships. In this
case, ``mydir/standard/machine_a`` includes everything in ``mydir/base`` case, ``mydir/standard/machine_a`` includes everything in ``mydir/base``
@@ -725,9 +937,19 @@ that have to be regularly updated. The Yocto Project Linux kernel tools
provide for this with the ``git merge`` command. provide for this with the ``git merge`` command.
To merge a feature branch into a BSP, insert the ``git merge`` command To merge a feature branch into a BSP, insert the ``git merge`` command
after any ``branch`` commands: mybsp.scc: define KMACHINE mybsp define after any ``branch`` commands:
KTYPE standard define KARCH i386 include standard.scc branch mynewbranch ::
git merge myfeature include mybsp-hw.scc
mybsp.scc:
define KMACHINE mybsp
define KTYPE standard
define KARCH i386
include standard.scc
branch mynewbranch
git merge myfeature
include mybsp-hw.scc
.. _scc-reference: .. _scc-reference:
@@ -758,7 +980,4 @@ within an SCC description file (``.scc``):
- ``patch PATCH_FILE``: Applies the patch to the current Git branch. - ``patch PATCH_FILE``: Applies the patch to the current Git branch.
.. [1]
``scc`` stands for Series Configuration Control, but the naming has
less significance in the current implementation of the tooling than
it had in the past. Consider ``scc`` files to be description files.

1011
documentation/kernel-dev/kernel-dev-common.rst
View File

File diff suppressed because it is too large Load Diff

113
documentation/kernel-dev/kernel-dev-concepts-appx.rst
View File

@@ -36,47 +36,46 @@ and custom features. These additions result in a commercially released
Yocto Project Linux kernel that caters to specific embedded designer Yocto Project Linux kernel that caters to specific embedded designer
needs for targeted hardware. needs for targeted hardware.
You can find a web interface to the Yocto Linux kernels in the `Source You can find a web interface to the Yocto Linux kernels in the
Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ at :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
:yocto_git:`/`. If you look at the interface, you will see to at :yocto_git:`/`. If you look at the interface, you will see to
the left a grouping of Git repositories titled "Yocto Linux Kernel". the left a grouping of Git repositories titled "Yocto Linux Kernel".
Within this group, you will find several Linux Yocto kernels developed Within this group, you will find several Linux Yocto kernels developed
and included with Yocto Project releases: and included with Yocto Project releases:
- *``linux-yocto-4.1``:* The stable Yocto Project kernel to use with - *linux-yocto-4.1:* The stable Yocto Project kernel to use with
the Yocto Project Release 2.0. This kernel is based on the Linux 4.1 the Yocto Project Release 2.0. This kernel is based on the Linux 4.1
released kernel. released kernel.
- *``linux-yocto-4.4``:* The stable Yocto Project kernel to use with - *linux-yocto-4.4:* The stable Yocto Project kernel to use with
the Yocto Project Release 2.1. This kernel is based on the Linux 4.4 the Yocto Project Release 2.1. This kernel is based on the Linux 4.4
released kernel. released kernel.
- *``linux-yocto-4.6``:* A temporary kernel that is not tied to any - *linux-yocto-4.6:* A temporary kernel that is not tied to any
Yocto Project release. Yocto Project release.
- *``linux-yocto-4.8``:* The stable yocto Project kernel to use with - *linux-yocto-4.8:* The stable yocto Project kernel to use with
the Yocto Project Release 2.2. the Yocto Project Release 2.2.
- *``linux-yocto-4.9``:* The stable Yocto Project kernel to use with - *linux-yocto-4.9:* The stable Yocto Project kernel to use with
the Yocto Project Release 2.3. This kernel is based on the Linux 4.9 the Yocto Project Release 2.3. This kernel is based on the Linux 4.9
released kernel. released kernel.
- *``linux-yocto-4.10``:* The default stable Yocto Project kernel to - *linux-yocto-4.10:* The default stable Yocto Project kernel to
use with the Yocto Project Release 2.3. This kernel is based on the use with the Yocto Project Release 2.3. This kernel is based on the
Linux 4.10 released kernel. Linux 4.10 released kernel.
- *``linux-yocto-4.12``:* The default stable Yocto Project kernel to - *linux-yocto-4.12:* The default stable Yocto Project kernel to
use with the Yocto Project Release 2.4. This kernel is based on the use with the Yocto Project Release 2.4. This kernel is based on the
Linux 4.12 released kernel. Linux 4.12 released kernel.
- *``yocto-kernel-cache``:* The ``linux-yocto-cache`` contains patches - *yocto-kernel-cache:* The ``linux-yocto-cache`` contains patches
and configurations for the linux-yocto kernel tree. This repository and configurations for the linux-yocto kernel tree. This repository
is useful when working on the linux-yocto kernel. For more is useful when working on the linux-yocto kernel. For more
information on this "Advanced Kernel Metadata", see the "`Working information on this "Advanced Kernel Metadata", see the
With Advanced Metadata ":doc:`kernel-dev-advanced`" Chapter.
(``yocto-kernel-cache``) <#kernel-dev-advanced>`__" Chapter.
- *``linux-yocto-dev``:* A development kernel based on the latest - *linux-yocto-dev:* A development kernel based on the latest
upstream release candidate available. upstream release candidate available.
.. note:: .. note::
@@ -164,7 +163,7 @@ implemented by the Yocto Project team using the Source Code Manager
- You can find documentation on Git at - You can find documentation on Git at
http://git-scm.com/documentation. You can also get an http://git-scm.com/documentation. You can also get an
introduction to Git as it applies to the Yocto Project in the introduction to Git as it applies to the Yocto Project in the
"`Git <&YOCTO_DOCS_OM_URL;#git>`__" section in the Yocto Project ":ref:`overview-manual/overview-manual-development-environment:git`" section in the Yocto Project
Overview and Concepts Manual. The latter reference provides an Overview and Concepts Manual. The latter reference provides an
overview of Git and presents a minimal set of Git commands that overview of Git and presents a minimal set of Git commands that
allows you to be functional using Git. You can use as much, or as allows you to be functional using Git. You can use as much, or as
@@ -295,17 +294,16 @@ available on your host system.
Kernel source code is available on your host system several different Kernel source code is available on your host system several different
ways: ways:
- *Files Accessed While using ``devtool``:* ``devtool``, which is - *Files Accessed While using devtool:* ``devtool``, which is
available with the Yocto Project, is the preferred method by which to available with the Yocto Project, is the preferred method by which to
modify the kernel. See the "`Kernel Modification modify the kernel. See the ":ref:`kernel-dev/kernel-dev-intro:kernel modification workflow`" section.
Workflow <#kernel-modification-workflow>`__" section.
- *Cloned Repository:* If you are working in the kernel all the time, - *Cloned Repository:* If you are working in the kernel all the time,
you probably would want to set up your own local Git repository of you probably would want to set up your own local Git repository of
the Yocto Linux kernel tree. For information on how to clone a Yocto the Yocto Linux kernel tree. For information on how to clone a Yocto
Linux kernel Git repository, see the "`Preparing the Build Host to Linux kernel Git repository, see the
Work on the ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
Kernel <#preparing-the-build-host-to-work-on-the-kernel>`__" section. section.
- *Temporary Source Files from a Build:* If you just need to make some - *Temporary Source Files from a Build:* If you just need to make some
patches to the kernel using a traditional BitBake workflow (i.e. not patches to the kernel using a traditional BitBake workflow (i.e. not
@@ -331,13 +329,12 @@ source files used during the build.
:align: center :align: center
Again, for additional information on the Yocto Project kernel's Again, for additional information on the Yocto Project kernel's
architecture and its branching strategy, see the "`Yocto Linux Kernel architecture and its branching strategy, see the
Architecture and Branching ":ref:`kernel-dev/kernel-dev-concepts-appx:yocto linux kernel architecture and branching strategies`"
Strategies <#yocto-linux-kernel-architecture-and-branching-strategies>`__" section. You can also reference the
section. You can also reference the "`Using ``devtool`` to Patch the ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
Kernel <#using-devtool-to-patch-the-kernel>`__" and "`Using Traditional and
Kernel Development to Patch the ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
sections for detailed example that modifies the kernel. sections for detailed example that modifies the kernel.
Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase
@@ -346,8 +343,8 @@ Determining Hardware and Non-Hardware Features for the Kernel Configuration Audi
This section describes part of the kernel configuration audit phase that This section describes part of the kernel configuration audit phase that
most developers can ignore. For general information on kernel most developers can ignore. For general information on kernel
configuration including ``menuconfig``, ``defconfig`` files, and configuration including ``menuconfig``, ``defconfig`` files, and
configuration fragments, see the "`Configuring the configuration fragments, see the
Kernel <#configuring-the-kernel>`__" section. ":ref:`kernel-dev/kernel-dev-common:configuring the kernel`" section.
During this part of the audit phase, the contents of the final During this part of the audit phase, the contents of the final
``.config`` file are compared against the fragments specified by the ``.config`` file are compared against the fragments specified by the
@@ -366,23 +363,27 @@ To determine whether or not a given option is "hardware" or
files that classify individual or groups of options as either hardware files that classify individual or groups of options as either hardware
or non-hardware. To better show this, consider a situation where the or non-hardware. To better show this, consider a situation where the
``yocto-kernel-cache`` contains the following files: ``yocto-kernel-cache`` contains the following files:
yocto-kernel-cache/features/drm-psb/hardware.cfg ::
yocto-kernel-cache/features/kgdb/hardware.cfg
yocto-kernel-cache/ktypes/base/hardware.cfg yocto-kernel-cache/features/drm-psb/hardware.cfg
yocto-kernel-cache/bsp/mti-malta32/hardware.cfg yocto-kernel-cache/features/kgdb/hardware.cfg
yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg yocto-kernel-cache/ktypes/base/hardware.cfg
yocto-kernel-cache/bsp/qemuarma9/hardware.cfg yocto-kernel-cache/bsp/mti-malta32/hardware.cfg
yocto-kernel-cache/bsp/mti-malta64/hardware.cfg yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg
yocto-kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg yocto-kernel-cache/bsp/qemuarma9/hardware.cfg
yocto-kernel-cache/bsp/common-pc/hardware.cfg yocto-kernel-cache/bsp/mti-malta64/hardware.cfg
yocto-kernel-cache/bsp/common-pc-64/hardware.cfg yocto-kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
yocto-kernel-cache/features/rfkill/non-hardware.cfg yocto-kernel-cache/bsp/common-pc/hardware.cfg
yocto-kernel-cache/ktypes/base/non-hardware.cfg yocto-kernel-cache/bsp/common-pc-64/hardware.cfg
yocto-kernel-cache/features/aufs/non-hardware.kcf yocto-kernel-cache/features/rfkill/non-hardware.cfg
yocto-kernel-cache/features/ocf/non-hardware.kcf yocto-kernel-cache/ktypes/base/non-hardware.cfg
yocto-kernel-cache/ktypes/base/non-hardware.kcf yocto-kernel-cache/features/aufs/non-hardware.kcf
yocto-kernel-cache/ktypes/base/hardware.kcf yocto-kernel-cache/features/ocf/non-hardware.kcf
yocto-kernel-cache/bsp/qemu-ppc32/hardware.kcf The following list yocto-kernel-cache/ktypes/base/non-hardware.kcf
yocto-kernel-cache/ktypes/base/hardware.kcf
yocto-kernel-cache/bsp/qemu-ppc32/hardware.kcf
The following list
provides explanations for the various files: provides explanations for the various files:
- ``hardware.kcf``: Specifies a list of kernel Kconfig files that - ``hardware.kcf``: Specifies a list of kernel Kconfig files that
@@ -402,10 +403,18 @@ provides explanations for the various files:
(i.e. ``hardware.kcf`` or ``non-hardware.kcf``). (i.e. ``hardware.kcf`` or ``non-hardware.kcf``).
Here is a specific example using the Here is a specific example using the
``kernel-cache/bsp/mti-malta32/hardware.cfg``: CONFIG_SERIAL_8250 ``kernel-cache/bsp/mti-malta32/hardware.cfg``:
CONFIG_SERIAL_8250_CONSOLE CONFIG_SERIAL_8250_NR_UARTS ::
CONFIG_SERIAL_8250_PCI CONFIG_SERIAL_CORE CONFIG_SERIAL_CORE_CONSOLE
CONFIG_VGA_ARB The kernel configuration audit automatically detects CONFIG_SERIAL_8250
CONFIG_SERIAL_8250_CONSOLE
CONFIG_SERIAL_8250_NR_UARTS
CONFIG_SERIAL_8250_PCI
CONFIG_SERIAL_CORE
CONFIG_SERIAL_CORE_CONSOLE
CONFIG_VGA_ARB
The kernel configuration audit automatically detects
these files (hence the names must be exactly the ones discussed here), these files (hence the names must be exactly the ones discussed here),
and uses them as inputs when generating warnings about the final and uses them as inputs when generating warnings about the final
``.config`` file. ``.config`` file.

70
documentation/kernel-dev/kernel-dev-faq.rst
View File

@@ -9,23 +9,46 @@ Kernel Development FAQ
Common Questions and Solutions Common Questions and Solutions
============================== ==============================
The following lists some solutions for common questions. How do I use my The following lists some solutions for common questions.
own Linux kernel ``.config`` file? Refer to the "`Changing the
Configuration <#changing-the-configuration>`__" section for information. How do I use my own Linux kernel ``.config`` file?
How do I create configuration fragments? Refer to the "`Creating --------------------------------------------------
Configuration Fragments <#creating-config-fragments>`__" section for
information. How do I use my own Linux kernel sources? Refer to the Refer to the
"`Working With Your Own Sources <#working-with-your-own-sources>`__" ":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
section for information. How do I install/not-install the kernel image section for information.
on the rootfs? The kernel image (e.g. ``vmlinuz``) is provided by the
How do I create configuration fragments?
----------------------------------------
A: Refer to the
":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
section for information.
How do I use my own Linux kernel sources?
-----------------------------------------
Refer to the
":ref:`kernel-dev/kernel-dev-common:working with your own sources`"
section for information.
How do I install/not-install the kernel image on the rootfs?
------------------------------------------------------------
The kernel image (e.g. ``vmlinuz``) is provided by the
``kernel-image`` package. Image recipes depend on ``kernel-base``. To ``kernel-image`` package. Image recipes depend on ``kernel-base``. To
specify whether or not the kernel image is installed in the generated specify whether or not the kernel image is installed in the generated
root filesystem, override ``RDEPENDS_kernel-base`` to include or not root filesystem, override ``RDEPENDS_kernel-base`` to include or not
include "kernel-image". See the "`Using .bbappend Files in Your include "kernel-image". See the
Layer <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in the ":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
section in the
Yocto Project Development Tasks Manual for information on how to use an Yocto Project Development Tasks Manual for information on how to use an
append file to override metadata. How do I install a specific kernel append file to override metadata.
module? Linux kernel modules are packaged individually. To ensure a
How do I install a specific kernel module?
------------------------------------------
Linux kernel modules are packaged individually. To ensure a
specific kernel module is included in an image, include it in the specific kernel module is included in an image, include it in the
appropriate machine appropriate machine
:term:`RRECOMMENDS` variable. :term:`RRECOMMENDS` variable.
@@ -36,10 +59,23 @@ These other variables are useful for installing specific modules:
:term:`MACHINE_EXTRA_RRECOMMENDS` :term:`MACHINE_EXTRA_RRECOMMENDS`
For example, set the following in the ``qemux86.conf`` file to include For example, set the following in the ``qemux86.conf`` file to include
the ``ab123`` kernel modules with images built for the ``qemux86`` the ``ab123`` kernel modules with images built for the ``qemux86``
machine: MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123" For more machine:
::
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
For more
information, see the "`Incorporating Out-of-Tree information, see the "`Incorporating Out-of-Tree
Modules <#incorporating-out-of-tree-modules>`__" section. How do I Modules <#incorporating-out-of-tree-modules>`__" section.
change the Linux kernel command line? The Linux kernel command line is
How do I change the Linux kernel command line?
----------------------------------------------
The Linux kernel command line is
typically specified in the machine config using the ``APPEND`` variable. typically specified in the machine config using the ``APPEND`` variable.
For example, you can add some helpful debug information doing the For example, you can add some helpful debug information doing the
following: APPEND += "printk.time=y initcall_debug debug" following:
::
APPEND += "printk.time=y initcall_debug debug"

40
documentation/kernel-dev/kernel-dev-intro.rst
View File

@@ -28,8 +28,8 @@ newly-supported platforms. Previous recipes in the release are refreshed
and supported for at least one additional Yocto Project release. As they and supported for at least one additional Yocto Project release. As they
align, these previous releases are updated to include the latest from align, these previous releases are updated to include the latest from
the Long Term Support Initiative (LTSI) project. You can learn more the Long Term Support Initiative (LTSI) project. You can learn more
about Yocto Linux kernels and LTSI in the "`Yocto Project Kernel about Yocto Linux kernels and LTSI in the ":ref:`Yocto Project Kernel
Development and Maintenance <#kernel-big-picture>`__" section. Development and Maintenance <kernel-big-picture>`" section.
Also included is a Yocto Linux kernel development recipe Also included is a Yocto Linux kernel development recipe
(``linux-yocto-dev.bb``) should you want to work with the very latest in (``linux-yocto-dev.bb``) should you want to work with the very latest in
@@ -81,17 +81,16 @@ facilitate the process of working with the kernel recipes. If you find
you need some additional background, please be sure to review and you need some additional background, please be sure to review and
understand the following documentation: understand the following documentation:
- `Yocto Project Quick Build <&YOCTO_DOCS_BRIEF_URL;>`__ document. - :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
- `Yocto Project Overview and Concepts Manual <&YOCTO_DOCS_OM_URL;>`__. - :doc:`../overview-manual/overview-manual`.
- ```devtool`` - :ref:`devtool
workflow <&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow>`__ workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
as described in the Yocto Project Application Development and the as described in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual. Extensible Software Development Kit (eSDK) manual.
- The "`Understanding and Creating - The ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__"
section in the Yocto Project Development Tasks Manual. section in the Yocto Project Development Tasks Manual.
- The "`Kernel Modification - The "`Kernel Modification
@@ -114,8 +113,7 @@ general information and references for further information.
:align: center :align: center
1. *Set up Your Host Development System to Support Development Using the 1. *Set up Your Host Development System to Support Development Using the
Yocto Project*: See the "`Setting Up the Development Host to Use the Yocto Project*: See the ":doc:`../dev-manual/dev-manual-start`" section in
Yocto Project <&YOCTO_DOCS_DEV_URL;#dev-manual-start>`__" section in
the Yocto Project Development Tasks Manual for options on how to get the Yocto Project Development Tasks Manual for options on how to get
a build host ready to use the Yocto Project. a build host ready to use the Yocto Project.
@@ -127,31 +125,33 @@ general information and references for further information.
Using ``devtool`` and the eSDK requires that you have a clean build Using ``devtool`` and the eSDK requires that you have a clean build
of the image and that you are set up with the appropriate eSDK. For of the image and that you are set up with the appropriate eSDK. For
more information, see the "`Getting Ready to Develop Using more information, see the
``devtool`` <#getting-ready-to-develop-using-devtool>`__" section. ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
section.
Using traditional kernel development requires that you have the Using traditional kernel development requires that you have the
kernel source available in an isolated local Git repository. For more kernel source available in an isolated local Git repository. For more
information, see the "`Getting Ready for Traditional Kernel information, see the
Development <#getting-ready-for-traditional-kernel-development>`__" ":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
section. section.
3. *Make Changes to the Kernel Source Code if applicable:* Modifying the 3. *Make Changes to the Kernel Source Code if applicable:* Modifying the
kernel does not always mean directly changing source files. However, kernel does not always mean directly changing source files. However,
if you have to do this, you make the changes to the files in the if you have to do this, you make the changes to the files in the
eSDK's Build Directory if you are using ``devtool``. For more eSDK's Build Directory if you are using ``devtool``. For more
information, see the "`Using ``devtool`` to Patch the information, see the
Kernel <#using-devtool-to-patch-the-kernel>`__" section. ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
section.
If you are using traditional kernel development, you edit the source If you are using traditional kernel development, you edit the source
files in the kernel's local Git repository. For more information, see files in the kernel's local Git repository. For more information, see the
the "`Using Traditional Kernel Development to Patch the ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
section. section.
4. *Make Kernel Configuration Changes if Applicable:* If your situation 4. *Make Kernel Configuration Changes if Applicable:* If your situation
calls for changing the kernel's configuration, you can use calls for changing the kernel's configuration, you can use
```menuconfig`` <#using-menuconfig>`__, which allows you to :ref:`menuconfig <kernel-dev/kernel-dev-common:using \`\`menuconfig\`\`>`,
which allows you to
interactively develop and test the configuration changes you are interactively develop and test the configuration changes you are
making to the kernel. Saving changes you make with ``menuconfig`` making to the kernel. Saving changes you make with ``menuconfig``
updates the kernel's ``.config`` file. updates the kernel's ``.config`` file.

35
documentation/kernel-dev/kernel-dev-maint-appx.rst
View File

@@ -28,12 +28,17 @@ in the Yocto Project Linux kernel in any clone of the Yocto Project
Linux kernel source repository and ``yocto-kernel-cache`` Git trees. For Linux kernel source repository and ``yocto-kernel-cache`` Git trees. For
example, the following commands clone the Yocto Project baseline Linux example, the following commands clone the Yocto Project baseline Linux
kernel that branches off ``linux.org`` version 4.12 and the kernel that branches off ``linux.org`` version 4.12 and the
``yocto-kernel-cache``, which contains stores of kernel Metadata: $ git ``yocto-kernel-cache``, which contains stores of kernel Metadata:
clone git://git.yoctoproject.org/linux-yocto-4.12 $ git clone ::
git://git.yoctoproject.org/linux-kernel-cache For more information on
$ git clone git://git.yoctoproject.org/linux-yocto-4.12
$ git clone git://git.yoctoproject.org/linux-kernel-cache
For more information on
how to set up a local Git repository of the Yocto Project Linux kernel how to set up a local Git repository of the Yocto Project Linux kernel
files, see the "`Preparing the Build Host to Work on the files, see the
Kernel <#preparing-the-build-host-to-work-on-the-kernel>`__" section. ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
section.
Once you have cloned the kernel Git repository and the cache of Metadata Once you have cloned the kernel Git repository and the cache of Metadata
on your local machine, you can discover the branches that are available on your local machine, you can discover the branches that are available
@@ -41,10 +46,13 @@ in the repository using the following Git command: $ git branch -a
Checking out a branch allows you to work with a particular Yocto Linux Checking out a branch allows you to work with a particular Yocto Linux
kernel. For example, the following commands check out the kernel. For example, the following commands check out the
"standard/beagleboard" branch of the Yocto Linux kernel repository and "standard/beagleboard" branch of the Yocto Linux kernel repository and
the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository: $ cd the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository:
~/linux-yocto-4.12 $ git checkout -b my-kernel-4.12 ::
remotes/origin/standard/beagleboard $ cd ~/linux-kernel-cache $ git
checkout -b my-4.12-metadata remotes/origin/yocto-4.12 $ cd ~/linux-yocto-4.12
$ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard
$ cd ~/linux-kernel-cache
$ git checkout -b my-4.12-metadata remotes/origin/yocto-4.12
.. note:: .. note::
@@ -102,7 +110,9 @@ patch, or BSP:
For a typical build, the target of the search is a feature For a typical build, the target of the search is a feature
description in an ``.scc`` file whose name follows this format (e.g. description in an ``.scc`` file whose name follows this format (e.g.
``beaglebone-standard.scc`` and ``beaglebone-preempt-rt.scc``): ``beaglebone-standard.scc`` and ``beaglebone-preempt-rt.scc``):
bsp_root_name-kernel_type.scc ::
bsp_root_name-kernel_type.scc
3. *Expand Feature:* Once located, the feature description is either 3. *Expand Feature:* Once located, the feature description is either
expanded into a simple script of actions, or into an existing expanded into a simple script of actions, or into an existing
@@ -212,7 +222,10 @@ build process generates a build tree that is separate from your kernel's
local Git source repository tree. This build tree has a name that uses local Git source repository tree. This build tree has a name that uses
the following form, where ``${MACHINE}`` is the metadata name of the the following form, where ``${MACHINE}`` is the metadata name of the
machine (BSP) and "kernel_type" is one of the Yocto Project supported machine (BSP) and "kernel_type" is one of the Yocto Project supported
kernel types (e.g. "standard"): linux-${MACHINE}-kernel_type-build kernel types (e.g. "standard"):
::
linux-${MACHINE}-kernel_type-build
The existing support in the ``kernel.org`` tree achieves this default The existing support in the ``kernel.org`` tree achieves this default
functionality. functionality.