mirror of
https://git.yoctoproject.org/poky
synced 2026-04-05 08:02:25 +02:00
sphinx: kernel-dev: Various URL, code block and other fixes to imported data
(From yocto-docs rev: 4888b49ccc5d133b4096e5a9b808f14d1afc7deb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Richard Purdie
@@ -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
|
||||
BSPs and Linux kernel types.
|
||||
|
||||
Kernel Metadata exists in many places. One area in the Yocto Project
|
||||
`Source Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ is the
|
||||
``yocto-kernel-cache`` Git repository. You can find this repository
|
||||
Kernel Metadata exists in many places. One area in the
|
||||
:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
|
||||
is the ``yocto-kernel-cache`` Git repository. You can find this repository
|
||||
grouped under the "Yocto Linux Kernel" heading in the
|
||||
:yocto_git:`Yocto Project Source Repositories <>`.
|
||||
|
||||
@@ -79,10 +79,14 @@ to indicate the branch.
|
||||
::
|
||||
|
||||
KBRANCH_edgerouter = "standard/edgerouter"
|
||||
|
||||
|
||||
|
||||
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`
|
||||
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
|
||||
``LINUX_KERNEL_TYPE`` variable combination. For example, to include a
|
||||
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,
|
||||
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
|
||||
within the kernel Metadata itself. The examples here are taken from the
|
||||
``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``
|
||||
[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
|
||||
the three file types. The description files are used to aggregate all
|
||||
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
|
||||
of configuration fragments, patches, features or kernel types, best
|
||||
practices dictate a logical separation of these types of Metadata. The
|
||||
following Metadata file hierarchy is recommended: base/ bsp/ cfg/
|
||||
features/ ktypes/ patches/
|
||||
following Metadata file hierarchy is recommended:
|
||||
::
|
||||
|
||||
base/
|
||||
bsp/
|
||||
cfg/
|
||||
features/
|
||||
ktypes/
|
||||
patches/
|
||||
|
||||
The ``bsp`` directory contains the `BSP
|
||||
descriptions <#bsp-descriptions>`__. The remaining directories all
|
||||
@@ -192,6 +212,11 @@ or the top level of
|
||||
if you are creating `Metadata outside of the
|
||||
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
|
||||
-------------
|
||||
|
||||
@@ -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
|
||||
two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the
|
||||
``cfg`` directory of the ``yocto-4.12`` branch in the
|
||||
``yocto-kernel-cache`` Git repository: cfg/smp.scc: define
|
||||
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
|
||||
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
|
||||
``yocto-kernel-cache`` Git repository:
|
||||
::
|
||||
|
||||
cfg/smp.scc:
|
||||
define 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 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
|
||||
Fragments <#creating-config-fragments>`__" section.
|
||||
|
||||
@@ -238,8 +275,10 @@ non-hardware fragment.
|
||||
|
||||
As described in the "`Validating
|
||||
Configuration <#validating-configuration>`__" section, you can use the
|
||||
following BitBake command to audit your configuration: $ bitbake
|
||||
linux-yocto -c kernel_configcheck -f
|
||||
following BitBake command to audit your configuration:
|
||||
::
|
||||
|
||||
$ bitbake linux-yocto -c kernel_configcheck -f
|
||||
|
||||
Patches
|
||||
-------
|
||||
@@ -258,20 +297,38 @@ in the ``patches/build`` directory of the ``yocto-4.12`` branch in the
|
||||
``yocto-kernel-cache`` Git repository.
|
||||
|
||||
The following listings show the ``build.scc`` file and part of the
|
||||
``modpost-mask-trivial-warnings.patch`` file: patches/build/build.scc:
|
||||
patch arm-serialize-build-targets.patch patch
|
||||
powerpc-serialize-image-targets.patch patch
|
||||
kbuild-exclude-meta-directory-from-distclean-processi.patch # applied by
|
||||
kgit # patch kbuild-add-meta-files-to-the-ignore-li.patch patch
|
||||
modpost-mask-trivial-warnings.patch patch
|
||||
menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch
|
||||
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
|
||||
``modpost-mask-trivial-warnings.patch`` file:
|
||||
::
|
||||
|
||||
patches/build/build.scc:
|
||||
patch arm-serialize-build-targets.patch
|
||||
patch powerpc-serialize-image-targets.patch
|
||||
patch kbuild-exclude-meta-directory-from-distclean-processi.patch
|
||||
|
||||
# applied by kgit
|
||||
# patch kbuild-add-meta-files-to-the-ignore-li.patch
|
||||
|
||||
patch modpost-mask-trivial-warnings.patch
|
||||
patch menuconfig-check-lxdiaglog.sh-Allow-specification-of.patch
|
||||
|
||||
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
|
||||
patch. In the example ``build.scc`` file, five patch statements exist
|
||||
for the five patches in the directory.
|
||||
@@ -289,11 +346,19 @@ Features
|
||||
|
||||
Features are complex kernel Metadata types that consist of configuration
|
||||
fragments, patches, and possibly other feature description files. As an
|
||||
example, consider the following generic listing: features/myfeature.scc
|
||||
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
|
||||
example, consider the following generic listing:
|
||||
::
|
||||
|
||||
features/myfeature.scc
|
||||
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
|
||||
``include`` command.
|
||||
|
||||
@@ -319,11 +384,16 @@ the ``linux-yocto_4.12.bb`` kernel recipe found in
|
||||
:ref:`require <bitbake:require-inclusion>` directive
|
||||
includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
|
||||
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.
|
||||
``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::
|
||||
|
||||
@@ -358,16 +428,36 @@ for Linux Yocto kernels:
|
||||
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``
|
||||
file, which is found in the ``ktypes/standard`` directory of the
|
||||
``yocto-kernel-cache`` Git repository: # Include this kernel type
|
||||
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
|
||||
# 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
|
||||
``yocto-kernel-cache`` Git repository:
|
||||
::
|
||||
|
||||
# Include this kernel type 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
|
||||
# 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
|
||||
``.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
|
||||
concepts, and presents a detailed example using a BSP supported by the
|
||||
Yocto Project (i.e. BeagleBone Board). For complete information on BSP
|
||||
layer file hierarchy, see the `Yocto Project Board Support Package (BSP)
|
||||
Developer's Guide <&YOCTO_DOCS_BSP_URL;>`__.
|
||||
layer file hierarchy, see the :doc:`../bsp-guide/bsp-guide`.
|
||||
|
||||
.. _bsp-description-file-overview:
|
||||
|
||||
Overview
|
||||
~~~~~~~~
|
||||
Description Overview
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For simplicity, consider the following root BSP layer description files
|
||||
for the BeagleBone board. These files employ both a structure and naming
|
||||
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
|
||||
Yocto Project: beaglebone-standard.scc beaglebone-preempt-rt.scc Each
|
||||
file uses the root name (i.e "beaglebone") BSP name followed by the
|
||||
Yocto Project:
|
||||
::
|
||||
|
||||
beaglebone-standard.scc
|
||||
beaglebone-preempt-rt.scc
|
||||
|
||||
Each file uses the root name (i.e "beaglebone") BSP name followed by the
|
||||
kernel type.
|
||||
|
||||
Examine the ``beaglebone-standard.scc`` file: define KMACHINE beaglebone
|
||||
define KTYPE standard 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
|
||||
Examine the ``beaglebone-standard.scc`` file:
|
||||
::
|
||||
|
||||
define KMACHINE beaglebone
|
||||
define KTYPE standard
|
||||
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`,
|
||||
:term:`KTYPE`, and
|
||||
:term:`KARCH` variables. These
|
||||
@@ -450,27 +560,52 @@ description file match.
|
||||
|
||||
To separate your kernel policy from your hardware configuration, you
|
||||
include a kernel type (``ktype``), such as "standard". In the previous
|
||||
example, this is done using the following: include
|
||||
ktypes/standard/standard.scc This file aggregates all the configuration
|
||||
example, this is done using the following:
|
||||
::
|
||||
|
||||
include ktypes/standard/standard.scc
|
||||
|
||||
This file aggregates all the configuration
|
||||
fragments, patches, and features that make up your standard kernel
|
||||
policy. See the "`Kernel Types <#kernel-types>`__" section for more
|
||||
information.
|
||||
|
||||
To aggregate common configurations and features specific to the kernel
|
||||
for mybsp, use the following: 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
|
||||
for mybsp, use the following:
|
||||
::
|
||||
|
||||
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
|
||||
Fragments <#creating-config-fragments>`__" section.
|
||||
|
||||
Finally, if you have any configurations specific to the hardware that
|
||||
are not in a ``*.scc`` file, you can include them as follows: kconf
|
||||
hardware mybsp-extra.cfg The BeagleBone example does not include these
|
||||
are not in a ``*.scc`` file, you can include them as follows:
|
||||
::
|
||||
|
||||
kconf hardware mybsp-extra.cfg
|
||||
|
||||
The BeagleBone example does not include these
|
||||
types of configurations. However, the Malta 32-bit board does
|
||||
("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:
|
||||
|
||||
@@ -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
|
||||
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 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
|
||||
::
|
||||
|
||||
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 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
|
||||
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
|
||||
supported kernel types (i.e. "standard", "preempt-rt", and "tiny").
|
||||
Consider the "minnow" description for the "standard" kernel type (i.e.
|
||||
``minnow-standard.scc``: define KMACHINE minnow define KTYPE standard
|
||||
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
|
||||
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
|
||||
``minnow-standard.scc``:
|
||||
::
|
||||
|
||||
define KMACHINE minnow
|
||||
define KTYPE standard
|
||||
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 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
|
||||
kernel types. Using this command significantly reduces duplication.
|
||||
|
||||
Now consider the "minnow" description for the "tiny" kernel type (i.e.
|
||||
``minnow-tiny.scc``): define KMACHINE minnow define KTYPE tiny define
|
||||
KARCH i386 include ktypes/tiny include minnow.scc As you might expect,
|
||||
``minnow-tiny.scc``):
|
||||
::
|
||||
|
||||
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
|
||||
only the minimal policy defined by the "tiny" kernel type and the
|
||||
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.
|
||||
|
||||
Here is an example that shows a trivial tree of kernel Metadata stored
|
||||
in recipe-space within a BSP layer: meta-my_bsp_layer/ \`--
|
||||
recipes-kernel \`-- linux \`-- linux-yocto \|-- bsp-standard.scc \|--
|
||||
bsp.cfg \`-- standard.cfg
|
||||
in recipe-space within a BSP layer:
|
||||
::
|
||||
|
||||
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
|
||||
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
|
||||
``*.scc`` in the ``SRC_URI`` statement. You need to use the following
|
||||
form from your kernel append file: SRC_URI_append_myplatform = " \\
|
||||
file://myplatform;type=kmeta;destsuffix=myplatform \\ "
|
||||
form from your kernel append file:
|
||||
::
|
||||
|
||||
SRC_URI_append_myplatform = " \
|
||||
file://myplatform;type=kmeta;destsuffix=myplatform \
|
||||
"
|
||||
|
||||
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
|
||||
:term:`SRC_URI` variable. As an
|
||||
example, consider the following ``SRC_URI`` statement from the
|
||||
``linux-yocto_4.12.bb`` kernel recipe: 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}"
|
||||
``linux-yocto_4.12.bb`` kernel recipe:
|
||||
::
|
||||
|
||||
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
|
||||
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.
|
||||
@@ -684,21 +874,43 @@ patches into a feature.
|
||||
|
||||
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
|
||||
new branch as the ``KBRANCH`` to use for the board as follows: KBRANCH =
|
||||
"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
|
||||
mybsp-hw.scc
|
||||
new branch as the ``KBRANCH`` to use for the board as follows:
|
||||
::
|
||||
|
||||
KBRANCH = "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 mybsp-hw.scc
|
||||
|
||||
If you find yourself with numerous branches, you might consider using a
|
||||
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
|
||||
machines, and common as ``mydir``, the branches in your Git repository
|
||||
might look like this: mydir/base mydir/standard/base
|
||||
mydir/standard/machine_a mydir/standard/machine_b
|
||||
mydir/standard/machine_c mydir/small/base mydir/small/machine_a
|
||||
might look like this:
|
||||
:
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
To merge a feature branch into a BSP, insert the ``git merge`` command
|
||||
after any ``branch`` commands: mybsp.scc: define KMACHINE mybsp define
|
||||
KTYPE standard define KARCH i386 include standard.scc branch mynewbranch
|
||||
git merge myfeature include mybsp-hw.scc
|
||||
after any ``branch`` commands:
|
||||
::
|
||||
|
||||
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:
|
||||
|
||||
@@ -758,7 +980,4 @@ within an SCC description file (``.scc``):
|
||||
|
||||
- ``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.
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -36,47 +36,46 @@ and custom features. These additions result in a commercially released
|
||||
Yocto Project Linux kernel that caters to specific embedded designer
|
||||
needs for targeted hardware.
|
||||
|
||||
You can find a web interface to the Yocto Linux kernels in the `Source
|
||||
Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ at
|
||||
:yocto_git:`/`. If you look at the interface, you will see to
|
||||
You can find a web interface to the Yocto Linux kernels in the
|
||||
:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
|
||||
at :yocto_git:`/`. If you look at the interface, you will see to
|
||||
the left a grouping of Git repositories titled "Yocto Linux Kernel".
|
||||
Within this group, you will find several Linux Yocto kernels developed
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
- *``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.
|
||||
|
||||
- *``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
|
||||
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
|
||||
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
|
||||
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
|
||||
is useful when working on the linux-yocto kernel. For more
|
||||
information on this "Advanced Kernel Metadata", see the "`Working
|
||||
With Advanced Metadata
|
||||
(``yocto-kernel-cache``) <#kernel-dev-advanced>`__" Chapter.
|
||||
information on this "Advanced Kernel Metadata", see the
|
||||
":doc:`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.
|
||||
|
||||
.. note::
|
||||
@@ -164,7 +163,7 @@ implemented by the Yocto Project team using the Source Code Manager
|
||||
- You can find documentation on Git at
|
||||
http://git-scm.com/documentation. You can also get an
|
||||
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 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
|
||||
@@ -295,17 +294,16 @@ available on your host system.
|
||||
Kernel source code is available on your host system several different
|
||||
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
|
||||
modify the kernel. See the "`Kernel Modification
|
||||
Workflow <#kernel-modification-workflow>`__" section.
|
||||
modify the kernel. See the ":ref:`kernel-dev/kernel-dev-intro:kernel modification workflow`" section.
|
||||
|
||||
- *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
|
||||
the Yocto Linux kernel tree. For information on how to clone a Yocto
|
||||
Linux kernel Git repository, see the "`Preparing the Build Host to
|
||||
Work on the
|
||||
Kernel <#preparing-the-build-host-to-work-on-the-kernel>`__" section.
|
||||
Linux kernel Git repository, see the
|
||||
":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
|
||||
section.
|
||||
|
||||
- *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
|
||||
@@ -331,13 +329,12 @@ source files used during the build.
|
||||
:align: center
|
||||
|
||||
Again, for additional information on the Yocto Project kernel's
|
||||
architecture and its branching strategy, see the "`Yocto Linux Kernel
|
||||
Architecture and Branching
|
||||
Strategies <#yocto-linux-kernel-architecture-and-branching-strategies>`__"
|
||||
section. You can also reference the "`Using ``devtool`` to Patch the
|
||||
Kernel <#using-devtool-to-patch-the-kernel>`__" and "`Using Traditional
|
||||
Kernel Development to Patch the
|
||||
Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
|
||||
architecture and its branching strategy, see the
|
||||
":ref:`kernel-dev/kernel-dev-concepts-appx:yocto linux kernel architecture and branching strategies`"
|
||||
section. You can also reference the
|
||||
":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
|
||||
and
|
||||
":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
|
||||
sections for detailed example that modifies the kernel.
|
||||
|
||||
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
|
||||
most developers can ignore. For general information on kernel
|
||||
configuration including ``menuconfig``, ``defconfig`` files, and
|
||||
configuration fragments, see the "`Configuring the
|
||||
Kernel <#configuring-the-kernel>`__" section.
|
||||
configuration fragments, see the
|
||||
":ref:`kernel-dev/kernel-dev-common:configuring the kernel`" section.
|
||||
|
||||
During this part of the audit phase, the contents of the final
|
||||
``.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
|
||||
or non-hardware. To better show this, consider a situation where the
|
||||
``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/bsp/mti-malta32/hardware.cfg
|
||||
yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg
|
||||
yocto-kernel-cache/bsp/qemuarma9/hardware.cfg
|
||||
yocto-kernel-cache/bsp/mti-malta64/hardware.cfg
|
||||
yocto-kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
|
||||
yocto-kernel-cache/bsp/common-pc/hardware.cfg
|
||||
yocto-kernel-cache/bsp/common-pc-64/hardware.cfg
|
||||
yocto-kernel-cache/features/rfkill/non-hardware.cfg
|
||||
yocto-kernel-cache/ktypes/base/non-hardware.cfg
|
||||
yocto-kernel-cache/features/aufs/non-hardware.kcf
|
||||
yocto-kernel-cache/features/ocf/non-hardware.kcf
|
||||
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
|
||||
::
|
||||
|
||||
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/bsp/mti-malta32/hardware.cfg
|
||||
yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg
|
||||
yocto-kernel-cache/bsp/qemuarma9/hardware.cfg
|
||||
yocto-kernel-cache/bsp/mti-malta64/hardware.cfg
|
||||
yocto-kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
|
||||
yocto-kernel-cache/bsp/common-pc/hardware.cfg
|
||||
yocto-kernel-cache/bsp/common-pc-64/hardware.cfg
|
||||
yocto-kernel-cache/features/rfkill/non-hardware.cfg
|
||||
yocto-kernel-cache/ktypes/base/non-hardware.cfg
|
||||
yocto-kernel-cache/features/aufs/non-hardware.kcf
|
||||
yocto-kernel-cache/features/ocf/non-hardware.kcf
|
||||
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:
|
||||
|
||||
- ``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``).
|
||||
|
||||
Here is a specific example using the
|
||||
``kernel-cache/bsp/mti-malta32/hardware.cfg``: 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
|
||||
``kernel-cache/bsp/mti-malta32/hardware.cfg``:
|
||||
::
|
||||
|
||||
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),
|
||||
and uses them as inputs when generating warnings about the final
|
||||
``.config`` file.
|
||||
|
||||
@@ -9,23 +9,46 @@ Kernel Development FAQ
|
||||
Common Questions and Solutions
|
||||
==============================
|
||||
|
||||
The following lists some solutions for common questions. How do I use my
|
||||
own Linux kernel ``.config`` file? Refer to the "`Changing the
|
||||
Configuration <#changing-the-configuration>`__" section for information.
|
||||
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
|
||||
"`Working With Your Own Sources <#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
|
||||
The following lists some solutions for common questions.
|
||||
|
||||
How do I use my own Linux kernel ``.config`` file?
|
||||
--------------------------------------------------
|
||||
|
||||
Refer to the
|
||||
":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
|
||||
section for information.
|
||||
|
||||
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
|
||||
specify whether or not the kernel image is installed in the generated
|
||||
root filesystem, override ``RDEPENDS_kernel-base`` to include or not
|
||||
include "kernel-image". See the "`Using .bbappend Files in Your
|
||||
Layer <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in the
|
||||
include "kernel-image". See 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
|
||||
append file to override metadata. How do I install a specific kernel
|
||||
module? Linux kernel modules are packaged individually. To ensure a
|
||||
append file to override metadata.
|
||||
|
||||
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
|
||||
appropriate machine
|
||||
:term:`RRECOMMENDS` variable.
|
||||
@@ -36,10 +59,23 @@ These other variables are useful for installing specific modules:
|
||||
:term:`MACHINE_EXTRA_RRECOMMENDS`
|
||||
For example, set the following in the ``qemux86.conf`` file to include
|
||||
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
|
||||
Modules <#incorporating-out-of-tree-modules>`__" section. How do I
|
||||
change the Linux kernel command line? The Linux kernel command line is
|
||||
Modules <#incorporating-out-of-tree-modules>`__" section.
|
||||
|
||||
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.
|
||||
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"
|
||||
|
||||
|
||||
@@ -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
|
||||
align, these previous releases are updated to include the latest from
|
||||
the Long Term Support Initiative (LTSI) project. You can learn more
|
||||
about Yocto Linux kernels and LTSI in the "`Yocto Project Kernel
|
||||
Development and Maintenance <#kernel-big-picture>`__" section.
|
||||
about Yocto Linux kernels and LTSI in the ":ref:`Yocto Project Kernel
|
||||
Development and Maintenance <kernel-big-picture>`" section.
|
||||
|
||||
Also included is a Yocto Linux kernel development recipe
|
||||
(``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
|
||||
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``
|
||||
workflow <&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow>`__
|
||||
- :ref:`devtool
|
||||
workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
|
||||
as described in the Yocto Project Application Development and the
|
||||
Extensible Software Development Kit (eSDK) manual.
|
||||
|
||||
- The "`Understanding and Creating
|
||||
Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__"
|
||||
- The ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
|
||||
section in the Yocto Project Development Tasks Manual.
|
||||
|
||||
- The "`Kernel Modification
|
||||
@@ -114,8 +113,7 @@ general information and references for further information.
|
||||
:align: center
|
||||
|
||||
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 <&YOCTO_DOCS_DEV_URL;#dev-manual-start>`__" section in
|
||||
Yocto Project*: See the ":doc:`../dev-manual/dev-manual-start`" section in
|
||||
the Yocto Project Development Tasks Manual for options on how to get
|
||||
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
|
||||
of the image and that you are set up with the appropriate eSDK. For
|
||||
more information, see the "`Getting Ready to Develop Using
|
||||
``devtool`` <#getting-ready-to-develop-using-devtool>`__" section.
|
||||
more information, see the
|
||||
":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
|
||||
section.
|
||||
|
||||
Using traditional kernel development requires that you have the
|
||||
kernel source available in an isolated local Git repository. For more
|
||||
information, see the "`Getting Ready for Traditional Kernel
|
||||
Development <#getting-ready-for-traditional-kernel-development>`__"
|
||||
information, see the
|
||||
":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
|
||||
section.
|
||||
|
||||
3. *Make Changes to the Kernel Source Code if applicable:* Modifying the
|
||||
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
|
||||
eSDK's Build Directory if you are using ``devtool``. For more
|
||||
information, see the "`Using ``devtool`` to Patch the
|
||||
Kernel <#using-devtool-to-patch-the-kernel>`__" section.
|
||||
information, see the
|
||||
":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
|
||||
section.
|
||||
|
||||
If you are using traditional kernel development, you edit the source
|
||||
files in the kernel's local Git repository. For more information, see
|
||||
the "`Using Traditional Kernel Development to Patch the
|
||||
Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
|
||||
files in the kernel's local Git repository. For more information, see the
|
||||
":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
|
||||
section.
|
||||
|
||||
4. *Make Kernel Configuration Changes if Applicable:* If your situation
|
||||
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
|
||||
making to the kernel. Saving changes you make with ``menuconfig``
|
||||
updates the kernel's ``.config`` 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
|
||||
example, the following commands clone the Yocto Project baseline Linux
|
||||
kernel that branches off ``linux.org`` version 4.12 and the
|
||||
``yocto-kernel-cache``, which contains stores of kernel Metadata: $ git
|
||||
clone git://git.yoctoproject.org/linux-yocto-4.12 $ git clone
|
||||
git://git.yoctoproject.org/linux-kernel-cache For more information on
|
||||
``yocto-kernel-cache``, which contains stores of kernel Metadata:
|
||||
::
|
||||
|
||||
$ 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
|
||||
files, see the "`Preparing the Build Host to Work on the
|
||||
Kernel <#preparing-the-build-host-to-work-on-the-kernel>`__" section.
|
||||
files, see the
|
||||
":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
|
||||
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
|
||||
kernel. For example, the following commands check out the
|
||||
"standard/beagleboard" branch of the Yocto Linux kernel repository and
|
||||
the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository: $ 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
|
||||
the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository:
|
||||
::
|
||||
|
||||
$ 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::
|
||||
|
||||
@@ -102,7 +110,9 @@ patch, or BSP:
|
||||
For a typical build, the target of the search is a feature
|
||||
description in an ``.scc`` file whose name follows this format (e.g.
|
||||
``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
|
||||
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
|
||||
the following form, where ``${MACHINE}`` is the metadata name of the
|
||||
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
|
||||
functionality.
|
||||
|
||||
Reference in New Issue
Block a user