summaryrefslogtreecommitdiffstats
path: root/documentation/kernel-dev
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/kernel-dev')
-rw-r--r--documentation/kernel-dev/advanced.rst87
-rw-r--r--documentation/kernel-dev/common.rst225
-rw-r--r--documentation/kernel-dev/concepts-appx.rst6
-rw-r--r--documentation/kernel-dev/faq.rst6
-rw-r--r--documentation/kernel-dev/maint-appx.rst15
5 files changed, 113 insertions, 226 deletions
diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst
index fb6dfca85f..b0d03851b3 100644
--- a/documentation/kernel-dev/advanced.rst
+++ b/documentation/kernel-dev/advanced.rst
@@ -67,8 +67,7 @@ to indicate the branch.
67.. note:: 67.. note::
68 68
69 You can use the ``KBRANCH`` value to define an alternate branch typically 69 You can use the ``KBRANCH`` value to define an alternate branch typically
70 with a machine override as shown here from the ``meta-yocto-bsp`` layer: 70 with a machine override as shown here from the ``meta-yocto-bsp`` layer::
71 ::
72 71
73 KBRANCH_edgerouter = "standard/edgerouter" 72 KBRANCH_edgerouter = "standard/edgerouter"
74 73
@@ -106,15 +105,13 @@ You can use the
106variable to include features (configuration fragments, patches, or both) 105variable to include features (configuration fragments, patches, or both)
107that are not already included by the ``KMACHINE`` and 106that are not already included by the ``KMACHINE`` and
108``LINUX_KERNEL_TYPE`` variable combination. For example, to include a 107``LINUX_KERNEL_TYPE`` variable combination. For example, to include a
109feature specified as "features/netfilter/netfilter.scc", specify: 108feature specified as "features/netfilter/netfilter.scc", specify::
110::
111 109
112 KERNEL_FEATURES += "features/netfilter/netfilter.scc" 110 KERNEL_FEATURES += "features/netfilter/netfilter.scc"
113 111
114To include a 112To include a
115feature called "cfg/sound.scc" just for the ``qemux86`` machine, 113feature called "cfg/sound.scc" just for the ``qemux86`` machine,
116specify: 114specify::
117::
118 115
119 KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc" 116 KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc"
120 117
@@ -157,8 +154,7 @@ types to form the final description of what will be assembled and built.
157While the kernel Metadata syntax does not enforce any logical separation 154While the kernel Metadata syntax does not enforce any logical separation
158of configuration fragments, patches, features or kernel types, best 155of configuration fragments, patches, features or kernel types, best
159practices dictate a logical separation of these types of Metadata. The 156practices dictate a logical separation of these types of Metadata. The
160following Metadata file hierarchy is recommended: 157following Metadata file hierarchy is recommended::
161::
162 158
163 base/ 159 base/
164 bsp/ 160 bsp/
@@ -222,8 +218,7 @@ used with the ``linux-yocto-4.12`` kernel as defined outside of the
222recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of 218recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of
223two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the 219two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the
224``cfg`` directory of the ``yocto-4.12`` branch in the 220``cfg`` directory of the ``yocto-4.12`` branch in the
225``yocto-kernel-cache`` Git repository: 221``yocto-kernel-cache`` Git repository::
226::
227 222
228 cfg/smp.scc: 223 cfg/smp.scc:
229 define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds" 224 define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds"
@@ -265,8 +260,7 @@ non-hardware fragment.
265 260
266As described in the 261As described in the
267":ref:`kernel-dev/common:validating configuration`" section, you can 262":ref:`kernel-dev/common:validating configuration`" section, you can
268use the following BitBake command to audit your configuration: 263use the following BitBake command to audit your configuration::
269::
270 264
271 $ bitbake linux-yocto -c kernel_configcheck -f 265 $ bitbake linux-yocto -c kernel_configcheck -f
272 266
@@ -287,8 +281,7 @@ in the ``patches/build`` directory of the ``yocto-4.12`` branch in the
287``yocto-kernel-cache`` Git repository. 281``yocto-kernel-cache`` Git repository.
288 282
289The following listings show the ``build.scc`` file and part of the 283The following listings show the ``build.scc`` file and part of the
290``modpost-mask-trivial-warnings.patch`` file: 284``modpost-mask-trivial-warnings.patch`` file::
291::
292 285
293 patches/build/build.scc: 286 patches/build/build.scc:
294 patch arm-serialize-build-targets.patch 287 patch arm-serialize-build-targets.patch
@@ -334,8 +327,7 @@ Features
334 327
335Features are complex kernel Metadata types that consist of configuration 328Features are complex kernel Metadata types that consist of configuration
336fragments, patches, and possibly other feature description files. As an 329fragments, patches, and possibly other feature description files. As an
337example, consider the following generic listing: 330example, consider the following generic listing::
338::
339 331
340 features/myfeature.scc 332 features/myfeature.scc
341 define KFEATURE_DESCRIPTION "Enable myfeature" 333 define KFEATURE_DESCRIPTION "Enable myfeature"
@@ -371,15 +363,13 @@ the ``linux-yocto_4.12.bb`` kernel recipe found in
371``poky/meta/recipes-kernel/linux``, a 363``poky/meta/recipes-kernel/linux``, a
372:ref:`require <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` directive 364:ref:`require <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` directive
373includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file, 365includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
374which has the following statement that defines the default kernel type: 366which has the following statement that defines the default kernel type::
375::
376 367
377 LINUX_KERNEL_TYPE ??= "standard" 368 LINUX_KERNEL_TYPE ??= "standard"
378 369
379Another example would be the real-time kernel (i.e. 370Another example would be the real-time kernel (i.e.
380``linux-yocto-rt_4.12.bb``). This kernel recipe directly sets the kernel 371``linux-yocto-rt_4.12.bb``). This kernel recipe directly sets the kernel
381type as follows: 372type as follows::
382::
383 373
384 LINUX_KERNEL_TYPE = "preempt-rt" 374 LINUX_KERNEL_TYPE = "preempt-rt"
385 375
@@ -412,8 +402,7 @@ for Linux Yocto kernels:
412For any given kernel type, the Metadata is defined by the ``.scc`` (e.g. 402For any given kernel type, the Metadata is defined by the ``.scc`` (e.g.
413``standard.scc``). Here is a partial listing for the ``standard.scc`` 403``standard.scc``). Here is a partial listing for the ``standard.scc``
414file, which is found in the ``ktypes/standard`` directory of the 404file, which is found in the ``ktypes/standard`` directory of the
415``yocto-kernel-cache`` Git repository: 405``yocto-kernel-cache`` Git repository::
416::
417 406
418 # Include this kernel type fragment to get the standard features and 407 # Include this kernel type fragment to get the standard features and
419 # configuration values. 408 # configuration values.
@@ -482,15 +471,13 @@ Description Overview
482For simplicity, consider the following root BSP layer description files 471For simplicity, consider the following root BSP layer description files
483for the BeagleBone board. These files employ both a structure and naming 472for the BeagleBone board. These files employ both a structure and naming
484convention for consistency. The naming convention for the file is as 473convention for consistency. The naming convention for the file is as
485follows: 474follows::
486::
487 475
488 bsp_root_name-kernel_type.scc 476 bsp_root_name-kernel_type.scc
489 477
490Here are some example root layer 478Here are some example root layer
491BSP filenames for the BeagleBone Board BSP, which is supported by the 479BSP filenames for the BeagleBone Board BSP, which is supported by the
492Yocto Project: 480Yocto Project::
493::
494 481
495 beaglebone-standard.scc 482 beaglebone-standard.scc
496 beaglebone-preempt-rt.scc 483 beaglebone-preempt-rt.scc
@@ -498,8 +485,7 @@ Yocto Project:
498Each file uses the root name (i.e "beaglebone") BSP name followed by the 485Each file uses the root name (i.e "beaglebone") BSP name followed by the
499kernel type. 486kernel type.
500 487
501Examine the ``beaglebone-standard.scc`` file: 488Examine the ``beaglebone-standard.scc`` file::
502::
503 489
504 define KMACHINE beaglebone 490 define KMACHINE beaglebone
505 define KTYPE standard 491 define KTYPE standard
@@ -533,8 +519,7 @@ description file match.
533 519
534To separate your kernel policy from your hardware configuration, you 520To separate your kernel policy from your hardware configuration, you
535include a kernel type (``ktype``), such as "standard". In the previous 521include a kernel type (``ktype``), such as "standard". In the previous
536example, this is done using the following: 522example, this is done using the following::
537::
538 523
539 include ktypes/standard/standard.scc 524 include ktypes/standard/standard.scc
540 525
@@ -544,13 +529,11 @@ policy. See the ":ref:`kernel-dev/advanced:kernel types`" section for more
544information. 529information.
545 530
546To aggregate common configurations and features specific to the kernel 531To aggregate common configurations and features specific to the kernel
547for `mybsp`, use the following: 532for `mybsp`, use the following::
548::
549 533
550 include mybsp.scc 534 include mybsp.scc
551 535
552You can see that in the BeagleBone example with the following: 536You can see that in the BeagleBone example with the following::
553::
554 537
555 include beaglebone.scc 538 include beaglebone.scc
556 539
@@ -558,15 +541,13 @@ For information on how to break a complete ``.config`` file into the various
558configuration fragments, see the ":ref:`kernel-dev/common:creating configuration fragments`" section. 541configuration fragments, see the ":ref:`kernel-dev/common:creating configuration fragments`" section.
559 542
560Finally, if you have any configurations specific to the hardware that 543Finally, if you have any configurations specific to the hardware that
561are not in a ``*.scc`` file, you can include them as follows: 544are not in a ``*.scc`` file, you can include them as follows::
562::
563 545
564 kconf hardware mybsp-extra.cfg 546 kconf hardware mybsp-extra.cfg
565 547
566The BeagleBone example does not include these 548The BeagleBone example does not include these
567types of configurations. However, the Malta 32-bit board does 549types of configurations. However, the Malta 32-bit board does
568("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file: 550("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file::
569::
570 551
571 define KMACHINE mti-malta32-le 552 define KMACHINE mti-malta32-le
572 define KMACHINE qemumipsel 553 define KMACHINE qemumipsel
@@ -623,8 +604,7 @@ found on the machine. This ``minnow.scc`` description file is then
623included in each of the three "minnow" description files for the 604included in each of the three "minnow" description files for the
624supported kernel types (i.e. "standard", "preempt-rt", and "tiny"). 605supported kernel types (i.e. "standard", "preempt-rt", and "tiny").
625Consider the "minnow" description for the "standard" kernel type (i.e. 606Consider the "minnow" description for the "standard" kernel type (i.e.
626``minnow-standard.scc``): 607``minnow-standard.scc``)::
627::
628 608
629 define KMACHINE minnow 609 define KMACHINE minnow
630 define KTYPE standard 610 define KTYPE standard
@@ -656,8 +636,7 @@ that defines all enabled hardware for the BSP that is common to all
656kernel types. Using this command significantly reduces duplication. 636kernel types. Using this command significantly reduces duplication.
657 637
658Now consider the "minnow" description for the "tiny" kernel type (i.e. 638Now consider the "minnow" description for the "tiny" kernel type (i.e.
659``minnow-tiny.scc``): 639``minnow-tiny.scc``)::
660::
661 640
662 define KMACHINE minnow 641 define KMACHINE minnow
663 define KTYPE tiny 642 define KTYPE tiny
@@ -720,8 +699,7 @@ See the ":ref:`kernel-dev/common:modifying an existing recipe`"
720section for more information. 699section for more information.
721 700
722Here is an example that shows a trivial tree of kernel Metadata stored 701Here is an example that shows a trivial tree of kernel Metadata stored
723in recipe-space within a BSP layer: 702in recipe-space within a BSP layer::
724::
725 703
726 meta-my_bsp_layer/ 704 meta-my_bsp_layer/
727 `-- recipes-kernel 705 `-- recipes-kernel
@@ -744,8 +722,7 @@ value when changing the content of files not explicitly listed in the
744 722
745If the BSP description is in recipe space, you cannot simply list the 723If the BSP description is in recipe space, you cannot simply list the
746``*.scc`` in the ``SRC_URI`` statement. You need to use the following 724``*.scc`` in the ``SRC_URI`` statement. You need to use the following
747form from your kernel append file: 725form from your kernel append file::
748::
749 726
750 SRC_URI_append_myplatform = " \ 727 SRC_URI_append_myplatform = " \
751 file://myplatform;type=kmeta;destsuffix=myplatform \ 728 file://myplatform;type=kmeta;destsuffix=myplatform \
@@ -759,8 +736,7 @@ reside in a separate repository. The OpenEmbedded build system adds the
759Metadata to the build as a "type=kmeta" repository through the 736Metadata to the build as a "type=kmeta" repository through the
760:term:`SRC_URI` variable. As an 737:term:`SRC_URI` variable. As an
761example, consider the following ``SRC_URI`` statement from the 738example, consider the following ``SRC_URI`` statement from the
762``linux-yocto_4.12.bb`` kernel recipe: 739``linux-yocto_4.12.bb`` kernel recipe::
763::
764 740
765 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \ 741 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH}; \
766 git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}" 742 git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
@@ -844,14 +820,12 @@ patches into a feature.
844 820
845Once you have a new branch, you can set up your kernel Metadata to use 821Once you have a new branch, you can set up your kernel Metadata to use
846the branch a couple different ways. In the recipe, you can specify the 822the branch a couple different ways. In the recipe, you can specify the
847new branch as the ``KBRANCH`` to use for the board as follows: 823new branch as the ``KBRANCH`` to use for the board as follows::
848::
849 824
850 KBRANCH = "mynewbranch" 825 KBRANCH = "mynewbranch"
851 826
852Another method is to use the ``branch`` command in the BSP 827Another method is to use the ``branch`` command in the BSP
853description: 828description::
854::
855 829
856 mybsp.scc: 830 mybsp.scc:
857 define KMACHINE mybsp 831 define KMACHINE mybsp
@@ -865,15 +839,13 @@ description:
865 839
866If you find yourself with numerous branches, you might consider using a 840If you find yourself with numerous branches, you might consider using a
867hierarchical branching system similar to what the Yocto Linux Kernel Git 841hierarchical branching system similar to what the Yocto Linux Kernel Git
868repositories use: 842repositories use::
869::
870 843
871 common/kernel_type/machine 844 common/kernel_type/machine
872 845
873If you had two kernel types, "standard" and "small" for instance, three 846If you had two kernel types, "standard" and "small" for instance, three
874machines, and common as ``mydir``, the branches in your Git repository 847machines, and common as ``mydir``, the branches in your Git repository
875might look like this: 848might look like this::
876::
877 849
878 mydir/base 850 mydir/base
879 mydir/standard/base 851 mydir/standard/base
@@ -905,8 +877,7 @@ that have to be regularly updated. The Yocto Project Linux kernel tools
905provide for this with the ``git merge`` command. 877provide for this with the ``git merge`` command.
906 878
907To merge a feature branch into a BSP, insert the ``git merge`` command 879To merge a feature branch into a BSP, insert the ``git merge`` command
908after any ``branch`` commands: 880after any ``branch`` commands::
909::
910 881
911 mybsp.scc: 882 mybsp.scc:
912 define KMACHINE mybsp 883 define KMACHINE mybsp
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index 56217b9d38..3f35d8412f 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -54,8 +54,7 @@ section:
54 54
551. *Initialize the BitBake Environment:* Before building an extensible 551. *Initialize the BitBake Environment:* Before building an extensible
56 SDK, you need to initialize the BitBake build environment by sourcing 56 SDK, you need to initialize the BitBake build environment by sourcing
57 the build environment script (i.e. :ref:`structure-core-script`): 57 the build environment script (i.e. :ref:`structure-core-script`)::
58 ::
59 58
60 $ cd poky 59 $ cd poky
61 $ source oe-init-build-env 60 $ source oe-init-build-env
@@ -83,16 +82,14 @@ section:
83 82
84 In this example we wish to build for qemux86 so we must set the 83 In this example we wish to build for qemux86 so we must set the
85 ``MACHINE`` variable to "qemux86" and also add the "kernel-modules". 84 ``MACHINE`` variable to "qemux86" and also add the "kernel-modules".
86 As described we do this by appending to ``conf/local.conf``: 85 As described we do this by appending to ``conf/local.conf``::
87 ::
88 86
89 MACHINE = "qemux86" 87 MACHINE = "qemux86"
90 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" 88 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
91 89
923. *Create a Layer for Patches:* You need to create a layer to hold 903. *Create a Layer for Patches:* You need to create a layer to hold
93 patches created for the kernel image. You can use the 91 patches created for the kernel image. You can use the
94 ``bitbake-layers create-layer`` command as follows: 92 ``bitbake-layers create-layer`` command as follows::
95 ::
96 93
97 $ cd poky/build 94 $ cd poky/build
98 $ bitbake-layers create-layer ../../meta-mylayer 95 $ bitbake-layers create-layer ../../meta-mylayer
@@ -116,8 +113,7 @@ section:
1164. *Inform the BitBake Build Environment About Your Layer:* As directed 1134. *Inform the BitBake Build Environment About Your Layer:* As directed
117 when you created your layer, you need to add the layer to the 114 when you created your layer, you need to add the layer to the
118 :term:`BBLAYERS` variable in the 115 :term:`BBLAYERS` variable in the
119 ``bblayers.conf`` file as follows: 116 ``bblayers.conf`` file as follows::
120 ::
121 117
122 $ cd poky/build 118 $ cd poky/build
123 $ bitbake-layers add-layer ../../meta-mylayer 119 $ bitbake-layers add-layer ../../meta-mylayer
@@ -125,16 +121,14 @@ section:
125 $ 121 $
126 122
1275. *Build the Extensible SDK:* Use BitBake to build the extensible SDK 1235. *Build the Extensible SDK:* Use BitBake to build the extensible SDK
128 specifically for use with images to be run using QEMU: 124 specifically for use with images to be run using QEMU::
129 ::
130 125
131 $ cd poky/build 126 $ cd poky/build
132 $ bitbake core-image-minimal -c populate_sdk_ext 127 $ bitbake core-image-minimal -c populate_sdk_ext
133 128
134 Once 129 Once
135 the build finishes, you can find the SDK installer file (i.e. 130 the build finishes, you can find the SDK installer file (i.e.
136 ``*.sh`` file) in the following directory: 131 ``*.sh`` file) in the following directory::
137 ::
138 132
139 poky/build/tmp/deploy/sdk 133 poky/build/tmp/deploy/sdk
140 134
@@ -143,8 +137,7 @@ section:
143 137
1446. *Install the Extensible SDK:* Use the following command to install 1386. *Install the Extensible SDK:* Use the following command to install
145 the SDK. For this example, install the SDK in the default 139 the SDK. For this example, install the SDK in the default
146 ``poky_sdk`` directory: 140 ``poky_sdk`` directory::
147 ::
148 141
149 $ cd poky/build/tmp/deploy/sdk 142 $ cd poky/build/tmp/deploy/sdk
150 $ ./poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-&DISTRO;.sh 143 $ ./poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-&DISTRO;.sh
@@ -172,8 +165,7 @@ section:
172 BitBake shell used to build the installer. 165 BitBake shell used to build the installer.
173 166
174 After opening a new shell, run the SDK environment setup script as 167 After opening a new shell, run the SDK environment setup script as
175 directed by the output from installing the SDK: 168 directed by the output from installing the SDK::
176 ::
177 169
178 $ source poky_sdk/environment-setup-i586-poky-linux 170 $ source poky_sdk/environment-setup-i586-poky-linux
179 "SDK environment now set up; additionally you may now run devtool to perform development tasks. 171 "SDK environment now set up; additionally you may now run devtool to perform development tasks.
@@ -186,8 +178,7 @@ section:
186 178
1878. *Build the Clean Image:* The final step in preparing to work on the 1798. *Build the Clean Image:* The final step in preparing to work on the
188 kernel is to build an initial image using ``devtool`` in the new 180 kernel is to build an initial image using ``devtool`` in the new
189 terminal you just set up and initialized for SDK work: 181 terminal you just set up and initialized for SDK work::
190 ::
191 182
192 $ devtool build-image 183 $ devtool build-image
193 Parsing recipes: 100% |##########################################| Time: 0:00:05 184 Parsing recipes: 100% |##########################################| Time: 0:00:05
@@ -269,16 +260,14 @@ section:
269 260
270 In this example we wish to build for qemux86 so we must set the 261 In this example we wish to build for qemux86 so we must set the
271 ``MACHINE`` variable to "qemux86" and also add the "kernel-modules". 262 ``MACHINE`` variable to "qemux86" and also add the "kernel-modules".
272 As described we do this by appending to ``conf/local.conf``: 263 As described we do this by appending to ``conf/local.conf``::
273 ::
274 264
275 MACHINE = "qemux86" 265 MACHINE = "qemux86"
276 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" 266 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
277 267
2783. *Create a Layer for Patches:* You need to create a layer to hold 2683. *Create a Layer for Patches:* You need to create a layer to hold
279 patches created for the kernel image. You can use the 269 patches created for the kernel image. You can use the
280 ``bitbake-layers create-layer`` command as follows: 270 ``bitbake-layers create-layer`` command as follows::
281 ::
282 271
283 $ cd poky/build 272 $ cd poky/build
284 $ bitbake-layers create-layer ../../meta-mylayer 273 $ bitbake-layers create-layer ../../meta-mylayer
@@ -301,8 +290,7 @@ section:
3014. *Inform the BitBake Build Environment About Your Layer:* As directed 2904. *Inform the BitBake Build Environment About Your Layer:* As directed
302 when you created your layer, you need to add the layer to the 291 when you created your layer, you need to add the layer to the
303 :term:`BBLAYERS` variable in the 292 :term:`BBLAYERS` variable in the
304 ``bblayers.conf`` file as follows: 293 ``bblayers.conf`` file as follows::
305 ::
306 294
307 $ cd poky/build 295 $ cd poky/build
308 $ bitbake-layers add-layer ../../meta-mylayer 296 $ bitbake-layers add-layer ../../meta-mylayer
@@ -350,8 +338,7 @@ section:
350 the ``yocto-4.12`` branch. 338 the ``yocto-4.12`` branch.
351 339
352 The following commands show how to create a local copy of the 340 The following commands show how to create a local copy of the
353 ``yocto-kernel-cache`` and be in the ``yocto-4.12`` branch: 341 ``yocto-kernel-cache`` and be in the ``yocto-4.12`` branch::
354 ::
355 342
356 $ cd ~ 343 $ cd ~
357 $ git clone git://git.yoctoproject.org/yocto-kernel-cache --branch yocto-4.12 344 $ git clone git://git.yoctoproject.org/yocto-kernel-cache --branch yocto-4.12
@@ -394,8 +381,7 @@ following section describes how to create a layer without the aid of
394tools. These steps assume creation of a layer named ``mylayer`` in your 381tools. These steps assume creation of a layer named ``mylayer`` in your
395home directory: 382home directory:
396 383
3971. *Create Structure*: Create the layer's structure: 3841. *Create Structure*: Create the layer's structure::
398 ::
399 385
400 $ mkdir meta-mylayer 386 $ mkdir meta-mylayer
401 $ mkdir meta-mylayer/conf 387 $ mkdir meta-mylayer/conf
@@ -409,8 +395,7 @@ home directory:
409 395
4102. *Create the Layer Configuration File*: Move to the 3962. *Create the Layer Configuration File*: Move to the
411 ``meta-mylayer/conf`` directory and create the ``layer.conf`` file as 397 ``meta-mylayer/conf`` directory and create the ``layer.conf`` file as
412 follows: 398 follows::
413 ::
414 399
415 # We have a conf and classes directory, add to BBPATH 400 # We have a conf and classes directory, add to BBPATH
416 BBPATH .= ":${LAYERDIR}" 401 BBPATH .= ":${LAYERDIR}"
@@ -429,8 +414,7 @@ home directory:
429 ``meta-mylayer/recipes-kernel/linux`` directory and create the 414 ``meta-mylayer/recipes-kernel/linux`` directory and create the
430 kernel's append file. This example uses the ``linux-yocto-4.12`` 415 kernel's append file. This example uses the ``linux-yocto-4.12``
431 kernel. Thus, the name of the append file is 416 kernel. Thus, the name of the append file is
432 ``linux-yocto_4.12.bbappend``: 417 ``linux-yocto_4.12.bbappend``::
433 ::
434 418
435 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 419 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
436 420
@@ -483,8 +467,7 @@ The append file should initially extend the
483:term:`FILESPATH` search path by 467:term:`FILESPATH` search path by
484prepending the directory that contains your files to the 468prepending the directory that contains your files to the
485:term:`FILESEXTRAPATHS` 469:term:`FILESEXTRAPATHS`
486variable as follows: 470variable as follows::
487::
488 471
489 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 472 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
490 473
@@ -492,8 +475,7 @@ The path ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``
492expands to "linux-yocto" in the current directory for this example. If 475expands to "linux-yocto" in the current directory for this example. If
493you add any new files that modify the kernel recipe and you have 476you add any new files that modify the kernel recipe and you have
494extended ``FILESPATH`` as described above, you must place the files in 477extended ``FILESPATH`` as described above, you must place the files in
495your layer in the following area: 478your layer in the following area::
496::
497 479
498 your-layer/recipes-kernel/linux/linux-yocto/ 480 your-layer/recipes-kernel/linux/linux-yocto/
499 481
@@ -582,8 +564,7 @@ To group related configurations into multiple files, you perform a
582similar procedure. Here is an example that groups separate 564similar procedure. Here is an example that groups separate
583configurations specifically for Ethernet and graphics into their own 565configurations specifically for Ethernet and graphics into their own
584files and adds the configurations by using a ``SRC_URI`` statement like 566files and adds the configurations by using a ``SRC_URI`` statement like
585the following in your append file: 567the following in your append file::
586::
587 568
588 SRC_URI += "file://myconfig.cfg \ 569 SRC_URI += "file://myconfig.cfg \
589 file://eth.cfg \ 570 file://eth.cfg \
@@ -627,8 +608,7 @@ reference them in :term:`SRC_URI`
627statements. 608statements.
628 609
629For example, you can apply a three-patch series by adding the following 610For example, you can apply a three-patch series by adding the following
630lines to your linux-yocto ``.bbappend`` file in your layer: 611lines to your linux-yocto ``.bbappend`` file in your layer::
631::
632 612
633 SRC_URI += "file://0001-first-change.patch" 613 SRC_URI += "file://0001-first-change.patch"
634 SRC_URI += "file://0002-second-change.patch" 614 SRC_URI += "file://0002-second-change.patch"
@@ -658,8 +638,7 @@ If you have a complete, working Linux kernel ``.config`` file you want
658to use for the configuration, as before, copy that file to the 638to use for the configuration, as before, copy that file to the
659appropriate ``${PN}`` directory in your layer's ``recipes-kernel/linux`` 639appropriate ``${PN}`` directory in your layer's ``recipes-kernel/linux``
660directory, and rename the copied file to "defconfig". Then, add the 640directory, and rename the copied file to "defconfig". Then, add the
661following lines to the linux-yocto ``.bbappend`` file in your layer: 641following lines to the linux-yocto ``.bbappend`` file in your layer::
662::
663 642
664 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 643 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
665 SRC_URI += "file://defconfig" 644 SRC_URI += "file://defconfig"
@@ -685,8 +664,7 @@ Generally speaking, the preferred approach is to determine the
685incremental change you want to make and add that as a configuration 664incremental change you want to make and add that as a configuration
686fragment. For example, if you want to add support for a basic serial 665fragment. For example, if you want to add support for a basic serial
687console, create a file named ``8250.cfg`` in the ``${PN}`` directory 666console, create a file named ``8250.cfg`` in the ``${PN}`` directory
688with the following content (without indentation): 667with the following content (without indentation)::
689::
690 668
691 CONFIG_SERIAL_8250=y 669 CONFIG_SERIAL_8250=y
692 CONFIG_SERIAL_8250_CONSOLE=y 670 CONFIG_SERIAL_8250_CONSOLE=y
@@ -698,8 +676,7 @@ with the following content (without indentation):
698 676
699Next, include this 677Next, include this
700configuration fragment and extend the ``FILESPATH`` variable in your 678configuration fragment and extend the ``FILESPATH`` variable in your
701``.bbappend`` file: 679``.bbappend`` file::
702::
703 680
704 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 681 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
705 SRC_URI += "file://8250.cfg" 682 SRC_URI += "file://8250.cfg"
@@ -718,8 +695,7 @@ It might be desirable to have kernel configuration fragment support
718through a ``defconfig`` file that is pulled from the kernel source tree 695through a ``defconfig`` file that is pulled from the kernel source tree
719for the configured machine. By default, the OpenEmbedded build system 696for the configured machine. By default, the OpenEmbedded build system
720looks for ``defconfig`` files in the layer used for Metadata, which is 697looks for ``defconfig`` files in the layer used for Metadata, which is
721"out-of-tree", and then configures them using the following: 698"out-of-tree", and then configures them using the following::
722::
723 699
724 SRC_URI += "file://defconfig" 700 SRC_URI += "file://defconfig"
725 701
@@ -732,16 +708,14 @@ append files, you can direct the OpenEmbedded build system to use a
732``defconfig`` file that is "in-tree". 708``defconfig`` file that is "in-tree".
733 709
734To specify an "in-tree" ``defconfig`` file, use the following statement 710To specify an "in-tree" ``defconfig`` file, use the following statement
735form: 711form::
736::
737 712
738 KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file" 713 KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
739 714
740Here is an example 715Here is an example
741that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2" 716that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2"
742and provides the path to the "in-tree" ``defconfig`` file to be used for 717and provides the path to the "in-tree" ``defconfig`` file to be used for
743a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset: 718a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
744::
745 719
746 KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" 720 KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig"
747 721
@@ -792,8 +766,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
792 ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" 766 ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
793 section for more information. 767 section for more information.
794 768
795 Use the following ``devtool`` command to check out the code: 769 Use the following ``devtool`` command to check out the code::
796 ::
797 770
798 $ devtool modify linux-yocto 771 $ devtool modify linux-yocto
799 772
@@ -819,14 +792,12 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
819 noted where you can find the source files (e.g. 792 noted where you can find the source files (e.g.
820 ``poky_sdk/workspace/sources/linux-yocto``). Change to where the 793 ``poky_sdk/workspace/sources/linux-yocto``). Change to where the
821 kernel source code is before making your edits to the 794 kernel source code is before making your edits to the
822 ``calibrate.c`` file: 795 ``calibrate.c`` file::
823 ::
824 796
825 $ cd poky_sdk/workspace/sources/linux-yocto 797 $ cd poky_sdk/workspace/sources/linux-yocto
826 798
827 2. *Edit the source file*: Edit the ``init/calibrate.c`` file to have 799 2. *Edit the source file*: Edit the ``init/calibrate.c`` file to have
828 the following changes: 800 the following changes::
829 ::
830 801
831 void calibrate_delay(void) 802 void calibrate_delay(void)
832 { 803 {
@@ -846,8 +817,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
846 . 817 .
847 818
8483. *Build the Updated Kernel Source:* To build the updated kernel 8193. *Build the Updated Kernel Source:* To build the updated kernel
849 source, use ``devtool``: 820 source, use ``devtool``::
850 ::
851 821
852 $ devtool build linux-yocto 822 $ devtool build linux-yocto
853 823
@@ -872,8 +842,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
872 using QEMU to verify your changes: 842 using QEMU to verify your changes:
873 843
874 1. *Boot the image*: Boot the modified image in the QEMU emulator 844 1. *Boot the image*: Boot the modified image in the QEMU emulator
875 using this command: 845 using this command::
876 ::
877 846
878 $ runqemu qemux86 847 $ runqemu qemux86
879 848
@@ -891,8 +860,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
891 860
8926. *Stage and commit your changes*: Within your eSDK terminal, change 8616. *Stage and commit your changes*: Within your eSDK terminal, change
893 your working directory to where you modified the ``calibrate.c`` file 862 your working directory to where you modified the ``calibrate.c`` file
894 and use these Git commands to stage and commit your changes: 863 and use these Git commands to stage and commit your changes::
895 ::
896 864
897 $ cd poky_sdk/workspace/sources/linux-yocto 865 $ cd poky_sdk/workspace/sources/linux-yocto
898 $ git status 866 $ git status
@@ -921,8 +889,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
921 image that includes your kernel patches. Execute the following 889 image that includes your kernel patches. Execute the following
922 command from your 890 command from your
923 :term:`Build Directory` in the terminal 891 :term:`Build Directory` in the terminal
924 set up to run BitBake: 892 set up to run BitBake::
925 ::
926 893
927 $ cd poky/build 894 $ cd poky/build
928 $ bitbake core-image-minimal 895 $ bitbake core-image-minimal
@@ -966,14 +933,12 @@ Section.
966 1. *Change the working directory*: You need to locate the source 933 1. *Change the working directory*: You need to locate the source
967 files in the local copy of the kernel Git repository. Change to 934 files in the local copy of the kernel Git repository. Change to
968 where the kernel source code is before making your edits to the 935 where the kernel source code is before making your edits to the
969 ``calibrate.c`` file: 936 ``calibrate.c`` file::
970 ::
971 937
972 $ cd ~/linux-yocto-4.12/init 938 $ cd ~/linux-yocto-4.12/init
973 939
974 2. *Edit the source file*: Edit the ``calibrate.c`` file to have the 940 2. *Edit the source file*: Edit the ``calibrate.c`` file to have the
975 following changes: 941 following changes::
976 ::
977 942
978 void calibrate_delay(void) 943 void calibrate_delay(void)
979 { 944 {
@@ -993,8 +958,7 @@ Section.
993 . 958 .
994 959
9952. *Stage and Commit Your Changes:* Use standard Git commands to stage 9602. *Stage and Commit Your Changes:* Use standard Git commands to stage
996 and commit the changes you just made: 961 and commit the changes you just made::
997 ::
998 962
999 $ git add calibrate.c 963 $ git add calibrate.c
1000 $ git commit -m "calibrate.c - Added some printk statements" 964 $ git commit -m "calibrate.c - Added some printk statements"
@@ -1009,13 +973,11 @@ Section.
1009 updated kernel source files. Add 973 updated kernel source files. Add
1010 :term:`SRC_URI` and 974 :term:`SRC_URI` and
1011 :term:`SRCREV` statements similar 975 :term:`SRCREV` statements similar
1012 to the following to your ``local.conf``: 976 to the following to your ``local.conf``::
1013 ::
1014 977
1015 $ cd poky/build/conf 978 $ cd poky/build/conf
1016 979
1017 Add the following to the ``local.conf``: 980 Add the following to the ``local.conf``::
1018 ::
1019 981
1020 SRC_URI_pn-linux-yocto = "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \ 982 SRC_URI_pn-linux-yocto = "git:///path-to/linux-yocto-4.12;protocol=file;name=machine;branch=standard/base; \
1021 git:///path-to/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}" 983 git:///path-to/yocto-kernel-cache;protocol=file;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}"
@@ -1031,16 +993,14 @@ Section.
1031 993
10324. *Build the Image:* With the source modified, your changes staged and 9944. *Build the Image:* With the source modified, your changes staged and
1033 committed, and the ``local.conf`` file pointing to the kernel files, 995 committed, and the ``local.conf`` file pointing to the kernel files,
1034 you can now use BitBake to build the image: 996 you can now use BitBake to build the image::
1035 ::
1036 997
1037 $ cd poky/build 998 $ cd poky/build
1038 $ bitbake core-image-minimal 999 $ bitbake core-image-minimal
1039 1000
10405. *Boot the image*: Boot the modified image in the QEMU emulator using 10015. *Boot the image*: Boot the modified image in the QEMU emulator using
1041 this command. When prompted to login to the QEMU console, use "root" 1002 this command. When prompted to login to the QEMU console, use "root"
1042 with no password: 1003 with no password::
1043 ::
1044 1004
1045 $ cd poky/build 1005 $ cd poky/build
1046 $ runqemu qemux86 1006 $ runqemu qemux86
@@ -1059,8 +1019,7 @@ Section.
1059 1019
10607. *Generate the Patch File:* Once you are sure that your patch works 10207. *Generate the Patch File:* Once you are sure that your patch works
1061 correctly, you can generate a ``*.patch`` file in the kernel source 1021 correctly, you can generate a ``*.patch`` file in the kernel source
1062 repository: 1022 repository::
1063 ::
1064 1023
1065 $ cd ~/linux-yocto-4.12/init 1024 $ cd ~/linux-yocto-4.12/init
1066 $ git format-patch -1 1025 $ git format-patch -1
@@ -1073,8 +1032,7 @@ Section.
1073 ``meta-mylayer``. When the layer was created using the 1032 ``meta-mylayer``. When the layer was created using the
1074 ``yocto-create`` script, no additional hierarchy was created to 1033 ``yocto-create`` script, no additional hierarchy was created to
1075 support patches. Before moving the patch file, you need to add 1034 support patches. Before moving the patch file, you need to add
1076 additional structure to your layer using the following commands: 1035 additional structure to your layer using the following commands::
1077 ::
1078 1036
1079 $ cd ~/meta-mylayer 1037 $ cd ~/meta-mylayer
1080 $ mkdir recipes-kernel 1038 $ mkdir recipes-kernel
@@ -1083,8 +1041,7 @@ Section.
1083 1041
1084 Once you have created this 1042 Once you have created this
1085 hierarchy in your layer, you can move the patch file using the 1043 hierarchy in your layer, you can move the patch file using the
1086 following command: 1044 following command::
1087 ::
1088 1045
1089 $ mv ~/linux-yocto-4.12/init/0001-calibrate.c-Added-some-printk-statements.patch ~/meta-mylayer/recipes-kernel/linux/linux-yocto 1046 $ mv ~/linux-yocto-4.12/init/0001-calibrate.c-Added-some-printk-statements.patch ~/meta-mylayer/recipes-kernel/linux/linux-yocto
1090 1047
@@ -1093,8 +1050,7 @@ Section.
1093 the OpenEmbedded build system to find the patch. The append file 1050 the OpenEmbedded build system to find the patch. The append file
1094 needs to be in your layer's ``recipes-kernel/linux`` directory and it 1051 needs to be in your layer's ``recipes-kernel/linux`` directory and it
1095 must be named ``linux-yocto_4.12.bbappend`` and have the following 1052 must be named ``linux-yocto_4.12.bbappend`` and have the following
1096 contents: 1053 contents::
1097 ::
1098 1054
1099 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 1055 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
1100 SRC_URI_append = "file://0001-calibrate.c-Added-some-printk-statements.patch" 1056 SRC_URI_append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
@@ -1113,8 +1069,7 @@ Section.
1113 To build ``core-image-minimal`` again and see the effects of your patch, 1069 To build ``core-image-minimal`` again and see the effects of your patch,
1114 you can essentially eliminate the temporary source files saved in 1070 you can essentially eliminate the temporary source files saved in
1115 ``poky/build/tmp/work/...`` and residual effects of the build by entering 1071 ``poky/build/tmp/work/...`` and residual effects of the build by entering
1116 the following sequence of commands: 1072 the following sequence of commands::
1117 ::
1118 1073
1119 $ cd poky/build 1074 $ cd poky/build
1120 $ bitbake -c cleanall yocto-linux 1075 $ bitbake -c cleanall yocto-linux
@@ -1160,8 +1115,7 @@ environment, you must do the following:
1160- You must be sure of the state of your build's configuration in the 1115- You must be sure of the state of your build's configuration in the
1161 :term:`Source Directory`. 1116 :term:`Source Directory`.
1162 1117
1163- Your build host must have the following two packages installed: 1118- Your build host must have the following two packages installed::
1164 ::
1165 1119
1166 libncurses5-dev 1120 libncurses5-dev
1167 libtinfo-dev 1121 libtinfo-dev
@@ -1169,8 +1123,7 @@ environment, you must do the following:
1169The following commands initialize the BitBake environment, run the 1123The following commands initialize the BitBake environment, run the
1170:ref:`ref-tasks-kernel_configme` 1124:ref:`ref-tasks-kernel_configme`
1171task, and launch ``menuconfig``. These commands assume the Source 1125task, and launch ``menuconfig``. These commands assume the Source
1172Directory's top-level folder is ``poky``: 1126Directory's top-level folder is ``poky``::
1173::
1174 1127
1175 $ cd poky 1128 $ cd poky
1176 $ source oe-init-build-env 1129 $ source oe-init-build-env
@@ -1232,8 +1185,7 @@ the ``.config`` file would be:
1232 1185
1233Within the ``.config`` file, you can see the kernel settings. For 1186Within the ``.config`` file, you can see the kernel settings. For
1234example, the following entry shows that symmetric multi-processor 1187example, the following entry shows that symmetric multi-processor
1235support is not set: 1188support is not set::
1236::
1237 1189
1238 # CONFIG_SMP is not set 1190 # CONFIG_SMP is not set
1239 1191
@@ -1274,8 +1226,7 @@ your layer's ``recipes-kernel/linux`` directory, and rename the copied
1274file to "defconfig" (e.g. 1226file to "defconfig" (e.g.
1275``~/meta-mylayer/recipes-kernel/linux/linux-yocto/defconfig``). Then, 1227``~/meta-mylayer/recipes-kernel/linux/linux-yocto/defconfig``). Then,
1276add the following lines to the linux-yocto ``.bbappend`` file in your 1228add the following lines to the linux-yocto ``.bbappend`` file in your
1277layer: 1229layer::
1278::
1279 1230
1280 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 1231 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
1281 SRC_URI += "file://defconfig" 1232 SRC_URI += "file://defconfig"
@@ -1323,8 +1274,7 @@ appear in the ``.config`` file, which is in the :term:`Build Directory`.
1323It is simple to create a configuration fragment. One method is to use 1274It is simple to create a configuration fragment. One method is to use
1324shell commands. For example, issuing the following from the shell 1275shell commands. For example, issuing the following from the shell
1325creates a configuration fragment file named ``my_smp.cfg`` that enables 1276creates a configuration fragment file named ``my_smp.cfg`` that enables
1326multi-processor support within the kernel: 1277multi-processor support within the kernel::
1327::
1328 1278
1329 $ echo "CONFIG_SMP=y" >> my_smp.cfg 1279 $ echo "CONFIG_SMP=y" >> my_smp.cfg
1330 1280
@@ -1342,8 +1292,7 @@ To create a configuration fragment using this method, follow these
1342steps: 1292steps:
1343 1293
13441. *Complete a Build Through Kernel Configuration:* Complete a build at 12941. *Complete a Build Through Kernel Configuration:* Complete a build at
1345 least through the kernel configuration task as follows: 1295 least through the kernel configuration task as follows::
1346 ::
1347 1296
1348 $ bitbake linux-yocto -c kernel_configme -f 1297 $ bitbake linux-yocto -c kernel_configme -f
1349 1298
@@ -1352,8 +1301,7 @@ steps:
1352 your build state might become unknown, it is best to run this task 1301 your build state might become unknown, it is best to run this task
1353 prior to starting ``menuconfig``. 1302 prior to starting ``menuconfig``.
1354 1303
13552. *Launch menuconfig:* Run the ``menuconfig`` command: 13042. *Launch menuconfig:* Run the ``menuconfig`` command::
1356 ::
1357 1305
1358 $ bitbake linux-yocto -c menuconfig 1306 $ bitbake linux-yocto -c menuconfig
1359 1307
@@ -1361,8 +1309,7 @@ steps:
1361 to prepare a configuration fragment. The resulting file 1309 to prepare a configuration fragment. The resulting file
1362 ``fragment.cfg`` is placed in the 1310 ``fragment.cfg`` is placed in the
1363 ``${``\ :term:`WORKDIR`\ ``}`` 1311 ``${``\ :term:`WORKDIR`\ ``}``
1364 directory: 1312 directory::
1365 ::
1366 1313
1367 $ bitbake linux-yocto -c diffconfig 1314 $ bitbake linux-yocto -c diffconfig
1368 1315
@@ -1387,8 +1334,7 @@ options in a file called ``myconfig.cfg``. If you put that file inside a
1387directory named ``linux-yocto`` that resides in the same directory as 1334directory named ``linux-yocto`` that resides in the same directory as
1388the kernel's append file within your layer and then add the following 1335the kernel's append file within your layer and then add the following
1389statements to the kernel's append file, those configuration options will 1336statements to the kernel's append file, those configuration options will
1390be picked up and applied when the kernel is built: 1337be picked up and applied when the kernel is built::
1391::
1392 1338
1393 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" 1339 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
1394 SRC_URI += "file://myconfig.cfg" 1340 SRC_URI += "file://myconfig.cfg"
@@ -1397,8 +1343,7 @@ As mentioned earlier, you can group related configurations into multiple
1397files and name them all in the ``SRC_URI`` statement as well. For 1343files and name them all in the ``SRC_URI`` statement as well. For
1398example, you could group separate configurations specifically for 1344example, you could group separate configurations specifically for
1399Ethernet and graphics into their own files and add those by using a 1345Ethernet and graphics into their own files and add those by using a
1400``SRC_URI`` statement like the following in your append file: 1346``SRC_URI`` statement like the following in your append file::
1401::
1402 1347
1403 SRC_URI += "file://myconfig.cfg \ 1348 SRC_URI += "file://myconfig.cfg \
1404 file://eth.cfg \ 1349 file://eth.cfg \
@@ -1409,8 +1354,7 @@ Validating Configuration
1409 1354
1410You can use the 1355You can use the
1411:ref:`ref-tasks-kernel_configcheck` 1356:ref:`ref-tasks-kernel_configcheck`
1412task to provide configuration validation: 1357task to provide configuration validation::
1413::
1414 1358
1415 $ bitbake linux-yocto -c kernel_configcheck -f 1359 $ bitbake linux-yocto -c kernel_configcheck -f
1416 1360
@@ -1537,8 +1481,7 @@ To streamline the configuration, do the following:
1537 successfully. Use this configuration file as your baseline. 1481 successfully. Use this configuration file as your baseline.
1538 1482
15392. *Run Configure and Check Tasks:* Separately run the 14832. *Run Configure and Check Tasks:* Separately run the
1540 ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks: 1484 ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks::
1541 ::
1542 1485
1543 $ bitbake linux-yocto -c kernel_configme -f 1486 $ bitbake linux-yocto -c kernel_configme -f
1544 $ bitbake linux-yocto -c kernel_configcheck -f 1487 $ bitbake linux-yocto -c kernel_configcheck -f
@@ -1572,8 +1515,7 @@ Expanding Variables
1572Sometimes it is helpful to determine what a variable expands to during a 1515Sometimes it is helpful to determine what a variable expands to during a
1573build. You can examine the values of variables by examining the 1516build. You can examine the values of variables by examining the
1574output of the ``bitbake -e`` command. The output is long and is more 1517output of the ``bitbake -e`` command. The output is long and is more
1575easily managed in a text file, which allows for easy searches: 1518easily managed in a text file, which allows for easy searches::
1576::
1577 1519
1578 $ bitbake -e virtual/kernel > some_text_file 1520 $ bitbake -e virtual/kernel > some_text_file
1579 1521
@@ -1590,15 +1532,13 @@ source directory. Follow these steps to clean up the version string:
1590 1532
15911. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned 15331. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned
1592 Git repository (source directory) and use the following Git command 1534 Git repository (source directory) and use the following Git command
1593 to list the files that have been changed, added, or removed: 1535 to list the files that have been changed, added, or removed::
1594 ::
1595 1536
1596 $ git status 1537 $ git status
1597 1538
15982. *Commit the Changes:* You should commit those changes to the kernel 15392. *Commit the Changes:* You should commit those changes to the kernel
1599 source tree regardless of whether or not you will save, export, or 1540 source tree regardless of whether or not you will save, export, or
1600 use the changes: 1541 use the changes::
1601 ::
1602 1542
1603 $ git add 1543 $ git add
1604 $ git commit -s -a -m "getting rid of -dirty" 1544 $ git commit -s -a -m "getting rid of -dirty"
@@ -1633,8 +1573,7 @@ linux-yocto custom recipe (``linux-yocto-custom.bb``) that uses
1633``kernel.org`` sources and the Yocto Project Linux kernel tools for 1573``kernel.org`` sources and the Yocto Project Linux kernel tools for
1634managing kernel Metadata. You can find this recipe in the ``poky`` Git 1574managing kernel Metadata. You can find this recipe in the ``poky`` Git
1635repository of the Yocto Project :yocto_git:`Source Repository <>` 1575repository of the Yocto Project :yocto_git:`Source Repository <>`
1636at: 1576at::
1637::
1638 1577
1639 poky/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb 1578 poky/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
1640 1579
@@ -1655,8 +1594,7 @@ Here are some basic steps you can use to work with your own sources:
1655 ``defconfig`` file or configuration fragment files in your layer. 1594 ``defconfig`` file or configuration fragment files in your layer.
1656 When you use the ``linux-yocto-custom.bb`` recipe, you must specify a 1595 When you use the ``linux-yocto-custom.bb`` recipe, you must specify a
1657 configuration. If you do not have a ``defconfig`` file, you can run 1596 configuration. If you do not have a ``defconfig`` file, you can run
1658 the following: 1597 the following::
1659 ::
1660 1598
1661 $ make defconfig 1599 $ make defconfig
1662 1600
@@ -1708,8 +1646,7 @@ Here are some basic steps you can use to work with your own sources:
1708 ``LINUX_VERSION`` with the Source Control Manager (SCM) revision 1646 ``LINUX_VERSION`` with the Source Control Manager (SCM) revision
1709 as derived from the :term:`SRCPV` 1647 as derived from the :term:`SRCPV`
1710 variable. The combined results are a string with the following 1648 variable. The combined results are a string with the following
1711 form: 1649 form::
1712 ::
1713 1650
1714 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2 1651 3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
1715 1652
@@ -1723,8 +1660,7 @@ Here are some basic steps you can use to work with your own sources:
1723 triggers an explicit build failure. You must change it to match a 1660 triggers an explicit build failure. You must change it to match a
1724 list of the machines that your new recipe supports. For example, 1661 list of the machines that your new recipe supports. For example,
1725 to support the ``qemux86`` and ``qemux86-64`` machines, use the 1662 to support the ``qemux86`` and ``qemux86-64`` machines, use the
1726 following form: 1663 following form::
1727 ::
1728 1664
1729 COMPATIBLE_MACHINE = "qemux86|qemux86-64" 1665 COMPATIBLE_MACHINE = "qemux86|qemux86-64"
1730 1666
@@ -1807,8 +1743,7 @@ Typically, you will need to set the following variables:
1807 1743
1808Depending on the build system used by the module sources, you might need 1744Depending on the build system used by the module sources, you might need
1809to make some adjustments. For example, a typical module ``Makefile`` 1745to make some adjustments. For example, a typical module ``Makefile``
1810looks much like the one provided with the ``hello-mod`` template: 1746looks much like the one provided with the ``hello-mod`` template::
1811::
1812 1747
1813 obj-m := hello.o 1748 obj-m := hello.o
1814 1749
@@ -1845,8 +1780,7 @@ them appropriately for your machine configuration file:
1845- :term:`MACHINE_EXTRA_RRECOMMENDS` 1780- :term:`MACHINE_EXTRA_RRECOMMENDS`
1846 1781
1847Modules are often not required for boot and can be excluded from certain 1782Modules are often not required for boot and can be excluded from certain
1848build configurations. The following allows for the most flexibility: 1783build configurations. The following allows for the most flexibility::
1849::
1850 1784
1851 MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule" 1785 MACHINE_EXTRA_RRECOMMENDS += "kernel-module-mymodule"
1852 1786
@@ -1895,26 +1829,22 @@ branch.
1895 1829
1896 $ git whatchanged origin/standard/base..origin/standard/emenlow 1830 $ git whatchanged origin/standard/base..origin/standard/emenlow
1897 1831
1898To see short, one line summaries of changes use the ``git log`` command: 1832To see short, one line summaries of changes use the ``git log`` command::
1899::
1900 1833
1901 $ git log --oneline origin/standard/base..origin/standard/emenlow 1834 $ git log --oneline origin/standard/base..origin/standard/emenlow
1902 1835
1903Use this command to see code differences for the changes: 1836Use this command to see code differences for the changes::
1904::
1905 1837
1906 $ git diff origin/standard/base..origin/standard/emenlow 1838 $ git diff origin/standard/base..origin/standard/emenlow
1907 1839
1908Use this command to see the commit log messages and the text 1840Use this command to see the commit log messages and the text
1909differences: 1841differences::
1910::
1911 1842
1912 $ git show origin/standard/base..origin/standard/emenlow 1843 $ git show origin/standard/base..origin/standard/emenlow
1913 1844
1914Use this command to create individual patches for each change. Here is 1845Use this command to create individual patches for each change. Here is
1915an example that creates patch files for each commit and places them 1846an example that creates patch files for each commit and places them
1916in your ``Documents`` directory: 1847in your ``Documents`` directory::
1917::
1918 1848
1919 $ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow 1849 $ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
1920 1850
@@ -1923,15 +1853,13 @@ Showing a Particular Feature or Branch Change
1923 1853
1924Tags in the Yocto Project kernel tree divide changes for significant 1854Tags in the Yocto Project kernel tree divide changes for significant
1925features or branches. The ``git show`` tag command shows changes based 1855features or branches. The ``git show`` tag command shows changes based
1926on a tag. Here is an example that shows ``systemtap`` changes: 1856on a tag. Here is an example that shows ``systemtap`` changes::
1927::
1928 1857
1929 $ git show systemtap 1858 $ git show systemtap
1930 1859
1931You can use the ``git branch --contains`` tag command to 1860You can use the ``git branch --contains`` tag command to
1932show the branches that contain a particular feature. This command shows 1861show the branches that contain a particular feature. This command shows
1933the branches that contain the ``systemtap`` feature: 1862the branches that contain the ``systemtap`` feature::
1934::
1935 1863
1936 $ git branch --contains systemtap 1864 $ git branch --contains systemtap
1937 1865
@@ -1986,8 +1914,7 @@ build.
1986 searched during the build as potential feature directories. 1914 searched during the build as potential feature directories.
1987 1915
1988 Continuing with the example, suppose the "test.scc" feature you are 1916 Continuing with the example, suppose the "test.scc" feature you are
1989 adding has a ``test.scc`` file in the following directory: 1917 adding has a ``test.scc`` file in the following directory::
1990 ::
1991 1918
1992 my_recipe 1919 my_recipe
1993 | 1920 |
@@ -2001,8 +1928,7 @@ build.
2001 a similarly named configuration fragment file ``test.cfg``. 1928 a similarly named configuration fragment file ``test.cfg``.
2002 1929
20032. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the 19302. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the
2004 recipe's ``SRC_URI`` statement: 1931 recipe's ``SRC_URI`` statement::
2005 ::
2006 1932
2007 SRC_URI_append = " file://test.scc" 1933 SRC_URI_append = " file://test.scc"
2008 1934
@@ -2011,8 +1937,7 @@ build.
2011 1937
20123. *Specify the Feature as a Kernel Feature:* Use the 19383. *Specify the Feature as a Kernel Feature:* Use the
2013 ``KERNEL_FEATURES`` statement to specify the feature as a kernel 1939 ``KERNEL_FEATURES`` statement to specify the feature as a kernel
2014 feature: 1940 feature::
2015 ::
2016 1941
2017 KERNEL_FEATURES_append = " test.scc" 1942 KERNEL_FEATURES_append = " test.scc"
2018 1943
diff --git a/documentation/kernel-dev/concepts-appx.rst b/documentation/kernel-dev/concepts-appx.rst
index 4b6dbe5ef9..63e67315fa 100644
--- a/documentation/kernel-dev/concepts-appx.rst
+++ b/documentation/kernel-dev/concepts-appx.rst
@@ -359,8 +359,7 @@ To determine whether or not a given option is "hardware" or
359"non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains 359"non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains
360files that classify individual or groups of options as either hardware 360files that classify individual or groups of options as either hardware
361or non-hardware. To better show this, consider a situation where the 361or non-hardware. To better show this, consider a situation where the
362``yocto-kernel-cache`` contains the following files: 362``yocto-kernel-cache`` contains the following files::
363::
364 363
365 yocto-kernel-cache/features/drm-psb/hardware.cfg 364 yocto-kernel-cache/features/drm-psb/hardware.cfg
366 yocto-kernel-cache/features/kgdb/hardware.cfg 365 yocto-kernel-cache/features/kgdb/hardware.cfg
@@ -400,8 +399,7 @@ provides explanations for the various files:
400 (i.e. ``hardware.kcf`` or ``non-hardware.kcf``). 399 (i.e. ``hardware.kcf`` or ``non-hardware.kcf``).
401 400
402Here is a specific example using the 401Here is a specific example using the
403``kernel-cache/bsp/mti-malta32/hardware.cfg``: 402``kernel-cache/bsp/mti-malta32/hardware.cfg``::
404::
405 403
406 CONFIG_SERIAL_8250 404 CONFIG_SERIAL_8250
407 CONFIG_SERIAL_8250_CONSOLE 405 CONFIG_SERIAL_8250_CONSOLE
diff --git a/documentation/kernel-dev/faq.rst b/documentation/kernel-dev/faq.rst
index c2106f81e1..8169511445 100644
--- a/documentation/kernel-dev/faq.rst
+++ b/documentation/kernel-dev/faq.rst
@@ -57,8 +57,7 @@ These other variables are useful for installing specific modules:
57 57
58For example, set the following in the ``qemux86.conf`` file to include 58For example, set the following in the ``qemux86.conf`` file to include
59the ``ab123`` kernel modules with images built for the ``qemux86`` 59the ``ab123`` kernel modules with images built for the ``qemux86``
60machine: 60machine::
61::
62 61
63 MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123" 62 MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
64 63
@@ -71,8 +70,7 @@ How do I change the Linux kernel command line?
71The Linux kernel command line is 70The Linux kernel command line is
72typically specified in the machine config using the ``APPEND`` variable. 71typically specified in the machine config using the ``APPEND`` variable.
73For example, you can add some helpful debug information doing the 72For example, you can add some helpful debug information doing the
74following: 73following::
75::
76 74
77 APPEND += "printk.time=y initcall_debug debug" 75 APPEND += "printk.time=y initcall_debug debug"
78 76
diff --git a/documentation/kernel-dev/maint-appx.rst b/documentation/kernel-dev/maint-appx.rst
index 44c43893e2..f84ab6e239 100644
--- a/documentation/kernel-dev/maint-appx.rst
+++ b/documentation/kernel-dev/maint-appx.rst
@@ -28,8 +28,7 @@ in the Yocto Project Linux kernel in any clone of the Yocto Project
28Linux kernel source repository and ``yocto-kernel-cache`` Git trees. For 28Linux kernel source repository and ``yocto-kernel-cache`` Git trees. For
29example, the following commands clone the Yocto Project baseline Linux 29example, the following commands clone the Yocto Project baseline Linux
30kernel that branches off ``linux.org`` version 4.12 and the 30kernel that branches off ``linux.org`` version 4.12 and the
31``yocto-kernel-cache``, which contains stores of kernel Metadata: 31``yocto-kernel-cache``, which contains stores of kernel Metadata::
32::
33 32
34 $ git clone git://git.yoctoproject.org/linux-yocto-4.12 33 $ git clone git://git.yoctoproject.org/linux-yocto-4.12
35 $ git clone git://git.yoctoproject.org/linux-kernel-cache 34 $ git clone git://git.yoctoproject.org/linux-kernel-cache
@@ -42,16 +41,14 @@ section.
42 41
43Once you have cloned the kernel Git repository and the cache of Metadata 42Once you have cloned the kernel Git repository and the cache of Metadata
44on your local machine, you can discover the branches that are available 43on your local machine, you can discover the branches that are available
45in the repository using the following Git command: 44in the repository using the following Git command::
46::
47 45
48 $ git branch -a 46 $ git branch -a
49 47
50Checking out a branch allows you to work with a particular Yocto Linux 48Checking out a branch allows you to work with a particular Yocto Linux
51kernel. For example, the following commands check out the 49kernel. For example, the following commands check out the
52"standard/beagleboard" branch of the Yocto Linux kernel repository and 50"standard/beagleboard" branch of the Yocto Linux kernel repository and
53the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository: 51the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository::
54::
55 52
56 $ cd ~/linux-yocto-4.12 53 $ cd ~/linux-yocto-4.12
57 $ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard 54 $ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard
@@ -111,8 +108,7 @@ patch, or BSP:
111 108
112 For a typical build, the target of the search is a feature 109 For a typical build, the target of the search is a feature
113 description in an ``.scc`` file whose name follows this format (e.g. 110 description in an ``.scc`` file whose name follows this format (e.g.
114 ``beaglebone-standard.scc`` and ``beaglebone-preempt-rt.scc``): 111 ``beaglebone-standard.scc`` and ``beaglebone-preempt-rt.scc``)::
115 ::
116 112
117 bsp_root_name-kernel_type.scc 113 bsp_root_name-kernel_type.scc
118 114
@@ -222,8 +218,7 @@ build process generates a build tree that is separate from your kernel's
222local Git source repository tree. This build tree has a name that uses 218local Git source repository tree. This build tree has a name that uses
223the following form, where ``${MACHINE}`` is the metadata name of the 219the following form, where ``${MACHINE}`` is the metadata name of the
224machine (BSP) and "kernel_type" is one of the Yocto Project supported 220machine (BSP) and "kernel_type" is one of the Yocto Project supported
225kernel types (e.g. "standard"): 221kernel types (e.g. "standard")::
226::
227 222
228 linux-${MACHINE}-kernel_type-build 223 linux-${MACHINE}-kernel_type-build
229 224