diff options
Diffstat (limited to 'documentation/kernel-dev/advanced.rst')
-rw-r--r-- | documentation/kernel-dev/advanced.rst | 259 |
1 files changed, 111 insertions, 148 deletions
diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst index dd0b76bc31..4c463503f6 100644 --- a/documentation/kernel-dev/advanced.rst +++ b/documentation/kernel-dev/advanced.rst | |||
@@ -21,7 +21,7 @@ is the ``yocto-kernel-cache`` Git repository. You can find this repository | |||
21 | grouped under the "Yocto Linux Kernel" heading in the | 21 | grouped under the "Yocto Linux Kernel" heading in the |
22 | :yocto_git:`Yocto Project Source Repositories <>`. | 22 | :yocto_git:`Yocto Project Source Repositories <>`. |
23 | 23 | ||
24 | Kernel development tools ("kern-tools") exist also in the Yocto Project | 24 | Kernel development tools ("kern-tools") are also available in the Yocto Project |
25 | Source Repositories under the "Yocto Linux Kernel" heading in the | 25 | Source Repositories under the "Yocto Linux Kernel" heading in the |
26 | ``yocto-kernel-tools`` Git repository. The recipe that builds these | 26 | ``yocto-kernel-tools`` Git repository. The recipe that builds these |
27 | tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in | 27 | tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in |
@@ -46,18 +46,18 @@ linux-yocto recipe. | |||
46 | 46 | ||
47 | Every linux-yocto style recipe must define the | 47 | Every linux-yocto style recipe must define the |
48 | :term:`KMACHINE` variable. This | 48 | :term:`KMACHINE` variable. This |
49 | variable is typically set to the same value as the ``MACHINE`` variable, | 49 | variable is typically set to the same value as the :term:`MACHINE` variable, |
50 | which is used by :term:`BitBake`. | 50 | which is used by :term:`BitBake`. |
51 | However, in some cases, the variable might instead refer to the | 51 | However, in some cases, the variable might instead refer to the |
52 | underlying platform of the ``MACHINE``. | 52 | underlying platform of the :term:`MACHINE`. |
53 | 53 | ||
54 | Multiple BSPs can reuse the same ``KMACHINE`` name if they are built | 54 | Multiple BSPs can reuse the same :term:`KMACHINE` name if they are built |
55 | using the same BSP description. Multiple Corei7-based BSPs could share | 55 | using the same BSP description. Multiple Corei7-based BSPs could share |
56 | the same "intel-corei7-64" value for ``KMACHINE``. It is important to | 56 | the same "intel-corei7-64" value for :term:`KMACHINE`. It is important to |
57 | realize that ``KMACHINE`` is just for kernel mapping, while ``MACHINE`` | 57 | realize that :term:`KMACHINE` is just for kernel mapping, while :term:`MACHINE` |
58 | is the machine type within a BSP Layer. Even with this distinction, | 58 | is the machine type within a BSP Layer. Even with this distinction, |
59 | however, these two variables can hold the same value. See the `BSP | 59 | however, these two variables can hold the same value. See the |
60 | Descriptions <#bsp-descriptions>`__ section for more information. | 60 | ":ref:`kernel-dev/advanced:bsp descriptions`" section for more information. |
61 | 61 | ||
62 | Every linux-yocto style recipe must also indicate the Linux kernel | 62 | Every linux-yocto style recipe must also indicate the Linux kernel |
63 | source repository branch used to build the Linux kernel. The | 63 | source repository branch used to build the Linux kernel. The |
@@ -66,12 +66,10 @@ to indicate the branch. | |||
66 | 66 | ||
67 | .. note:: | 67 | .. note:: |
68 | 68 | ||
69 | You can use the ``KBRANCH`` value to define an alternate branch typically | 69 | You can use the :term:`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 | |||
73 | KBRANCH_edgerouter = "standard/edgerouter" | ||
74 | 71 | ||
72 | KBRANCH:beaglebone-yocto = "standard/beaglebone" | ||
75 | 73 | ||
76 | The linux-yocto style recipes can optionally define the following | 74 | The linux-yocto style recipes can optionally define the following |
77 | variables: | 75 | variables: |
@@ -82,49 +80,47 @@ variables: | |||
82 | 80 | ||
83 | :term:`LINUX_KERNEL_TYPE` | 81 | :term:`LINUX_KERNEL_TYPE` |
84 | defines the kernel type to be used in assembling the configuration. If | 82 | defines the kernel type to be used in assembling the configuration. If |
85 | you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to "standard". | 83 | you do not specify a :term:`LINUX_KERNEL_TYPE`, it defaults to "standard". |
86 | Together with ``KMACHINE``, ``LINUX_KERNEL_TYPE`` defines the search | 84 | Together with :term:`KMACHINE`, :term:`LINUX_KERNEL_TYPE` defines the search |
87 | arguments used by the kernel tools to find the appropriate description | 85 | arguments used by the kernel tools to find the appropriate description |
88 | within the kernel Metadata with which to build out the sources and | 86 | within the kernel Metadata with which to build out the sources and |
89 | configuration. The linux-yocto recipes define "standard", "tiny", and | 87 | configuration. The linux-yocto recipes define "standard", "tiny", and |
90 | "preempt-rt" kernel types. See the "`Kernel Types <#kernel-types>`__" | 88 | "preempt-rt" kernel types. See the ":ref:`kernel-dev/advanced:kernel types`" |
91 | section for more information on kernel types. | 89 | section for more information on kernel types. |
92 | 90 | ||
93 | During the build, the kern-tools search for the BSP description file | 91 | During the build, the kern-tools search for the BSP description file |
94 | that most closely matches the ``KMACHINE`` and ``LINUX_KERNEL_TYPE`` | 92 | that most closely matches the :term:`KMACHINE` and :term:`LINUX_KERNEL_TYPE` |
95 | variables passed in from the recipe. The tools use the first BSP | 93 | variables passed in from the recipe. The tools use the first BSP |
96 | description they find that matches both variables. If the tools cannot find | 94 | description they find that matches both variables. If the tools cannot find |
97 | a match, they issue a warning. | 95 | a match, they issue a warning. |
98 | 96 | ||
99 | The tools first search for the ``KMACHINE`` and then for the | 97 | The tools first search for the :term:`KMACHINE` and then for the |
100 | ``LINUX_KERNEL_TYPE``. If the tools cannot find a partial match, they | 98 | :term:`LINUX_KERNEL_TYPE`. If the tools cannot find a partial match, they |
101 | will use the sources from the ``KBRANCH`` and any configuration | 99 | will use the sources from the :term:`KBRANCH` and any configuration |
102 | specified in the :term:`SRC_URI`. | 100 | specified in the :term:`SRC_URI`. |
103 | 101 | ||
104 | You can use the | 102 | You can use the |
105 | :term:`KERNEL_FEATURES` | 103 | :term:`KERNEL_FEATURES` |
106 | variable to include features (configuration fragments, patches, or both) | 104 | variable to include features (configuration fragments, patches, or both) |
107 | that are not already included by the ``KMACHINE`` and | 105 | that are not already included by the :term:`KMACHINE` and |
108 | ``LINUX_KERNEL_TYPE`` variable combination. For example, to include a | 106 | :term:`LINUX_KERNEL_TYPE` variable combination. For example, to include a |
109 | feature specified as "features/netfilter/netfilter.scc", specify: | 107 | feature specified as "features/netfilter/netfilter.scc", specify:: |
110 | :: | ||
111 | 108 | ||
112 | KERNEL_FEATURES += "features/netfilter/netfilter.scc" | 109 | KERNEL_FEATURES += "features/netfilter/netfilter.scc" |
113 | 110 | ||
114 | To include a | 111 | To include a |
115 | feature called "cfg/sound.scc" just for the ``qemux86`` machine, | 112 | feature called "cfg/sound.scc" just for the ``qemux86`` machine, |
116 | specify: | 113 | specify:: |
117 | :: | ||
118 | 114 | ||
119 | KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc" | 115 | KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc" |
120 | 116 | ||
121 | The value of | 117 | The value of |
122 | the entries in ``KERNEL_FEATURES`` are dependent on their location | 118 | the entries in :term:`KERNEL_FEATURES` are dependent on their location |
123 | within the kernel Metadata itself. The examples here are taken from the | 119 | within the kernel Metadata itself. The examples here are taken from the |
124 | ``yocto-kernel-cache`` repository. Each branch of this repository | 120 | ``yocto-kernel-cache`` repository. Each branch of this repository |
125 | contains "features" and "cfg" subdirectories at the top-level. For more | 121 | contains "features" and "cfg" subdirectories at the top-level. For more |
126 | information, see the "`Kernel Metadata | 122 | information, see the ":ref:`kernel-dev/advanced:kernel metadata syntax`" |
127 | Syntax <#kernel-metadata-syntax>`__" section. | 123 | section. |
128 | 124 | ||
129 | Kernel Metadata Syntax | 125 | Kernel Metadata Syntax |
130 | ====================== | 126 | ====================== |
@@ -148,7 +144,7 @@ Features aggregate sources in the form of patches and configuration | |||
148 | fragments into a modular reusable unit. You can use features to | 144 | fragments into a modular reusable unit. You can use features to |
149 | implement conceptually separate kernel Metadata descriptions such as | 145 | implement conceptually separate kernel Metadata descriptions such as |
150 | pure configuration fragments, simple patches, complex features, and | 146 | pure configuration fragments, simple patches, complex features, and |
151 | kernel types. `Kernel types <#kernel-types>`__ define general kernel | 147 | kernel types. :ref:`kernel-dev/advanced:kernel types` define general kernel |
152 | features and policy to be reused in the BSPs. | 148 | features and policy to be reused in the BSPs. |
153 | 149 | ||
154 | BSPs define hardware-specific features and aggregate them with kernel | 150 | BSPs define hardware-specific features and aggregate them with kernel |
@@ -157,8 +153,7 @@ types to form the final description of what will be assembled and built. | |||
157 | While the kernel Metadata syntax does not enforce any logical separation | 153 | While the kernel Metadata syntax does not enforce any logical separation |
158 | of configuration fragments, patches, features or kernel types, best | 154 | of configuration fragments, patches, features or kernel types, best |
159 | practices dictate a logical separation of these types of Metadata. The | 155 | practices dictate a logical separation of these types of Metadata. The |
160 | following Metadata file hierarchy is recommended: | 156 | following Metadata file hierarchy is recommended:: |
161 | :: | ||
162 | 157 | ||
163 | base/ | 158 | base/ |
164 | bsp/ | 159 | bsp/ |
@@ -167,10 +162,9 @@ following Metadata file hierarchy is recommended: | |||
167 | ktypes/ | 162 | ktypes/ |
168 | patches/ | 163 | patches/ |
169 | 164 | ||
170 | The ``bsp`` directory contains the `BSP | 165 | The ``bsp`` directory contains the :ref:`kernel-dev/advanced:bsp descriptions`. |
171 | descriptions <#bsp-descriptions>`__. The remaining directories all | 166 | The remaining directories all contain "features". Separating ``bsp`` from the |
172 | contain "features". Separating ``bsp`` from the rest of the structure | 167 | rest of the structure aids conceptualizing intended usage. |
173 | aids conceptualizing intended usage. | ||
174 | 168 | ||
175 | Use these guidelines to help place your ``scc`` description files within | 169 | Use these guidelines to help place your ``scc`` description files within |
176 | the structure: | 170 | the structure: |
@@ -188,7 +182,7 @@ the structure: | |||
188 | order to define a base kernel policy or major kernel type to be | 182 | order to define a base kernel policy or major kernel type to be |
189 | reused across multiple BSPs, place the file in ``ktypes`` directory. | 183 | reused across multiple BSPs, place the file in ``ktypes`` directory. |
190 | 184 | ||
191 | These distinctions can easily become blurred - especially as out-of-tree | 185 | These distinctions can easily become blurred --- especially as out-of-tree |
192 | features slowly merge upstream over time. Also, remember that how the | 186 | features slowly merge upstream over time. Also, remember that how the |
193 | description files are placed is a purely logical organization and has no | 187 | description files are placed is a purely logical organization and has no |
194 | impact on the functionality of the kernel Metadata. There is no impact | 188 | impact on the functionality of the kernel Metadata. There is no impact |
@@ -198,11 +192,12 @@ contain "features" as far as the kernel tools are concerned. | |||
198 | Paths used in kernel Metadata files are relative to base, which is | 192 | Paths used in kernel Metadata files are relative to base, which is |
199 | either | 193 | either |
200 | :term:`FILESEXTRAPATHS` if | 194 | :term:`FILESEXTRAPATHS` if |
201 | you are creating Metadata in `recipe-space <#recipe-space-metadata>`__, | 195 | you are creating Metadata in |
196 | :ref:`recipe-space <kernel-dev/advanced:recipe-space metadata>`, | ||
202 | or the top level of | 197 | or the top level of |
203 | :yocto_git:`yocto-kernel-cache </yocto-kernel-cache/tree/>` | 198 | :yocto_git:`yocto-kernel-cache </yocto-kernel-cache/tree/>` |
204 | if you are creating `Metadata outside of the | 199 | if you are creating |
205 | recipe-space <#metadata-outside-the-recipe-space>`__. | 200 | :ref:`kernel-dev/advanced:metadata outside the recipe-space`. |
206 | 201 | ||
207 | .. [1] | 202 | .. [1] |
208 | ``scc`` stands for Series Configuration Control, but the naming has | 203 | ``scc`` stands for Series Configuration Control, but the naming has |
@@ -222,8 +217,7 @@ used with the ``linux-yocto-4.12`` kernel as defined outside of the | |||
222 | recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of | 217 | recipe space (i.e. ``yocto-kernel-cache``). This Metadata consists of |
223 | two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the | 218 | two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the |
224 | ``cfg`` directory of the ``yocto-4.12`` branch in the | 219 | ``cfg`` directory of the ``yocto-4.12`` branch in the |
225 | ``yocto-kernel-cache`` Git repository: | 220 | ``yocto-kernel-cache`` Git repository:: |
226 | :: | ||
227 | 221 | ||
228 | cfg/smp.scc: | 222 | cfg/smp.scc: |
229 | define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds" | 223 | define KFEATURE_DESCRIPTION "Enable SMP for 32 bit builds" |
@@ -265,8 +259,7 @@ non-hardware fragment. | |||
265 | 259 | ||
266 | As described in the | 260 | As described in the |
267 | ":ref:`kernel-dev/common:validating configuration`" section, you can | 261 | ":ref:`kernel-dev/common:validating configuration`" section, you can |
268 | use the following BitBake command to audit your configuration: | 262 | use the following BitBake command to audit your configuration:: |
269 | :: | ||
270 | 263 | ||
271 | $ bitbake linux-yocto -c kernel_configcheck -f | 264 | $ bitbake linux-yocto -c kernel_configcheck -f |
272 | 265 | ||
@@ -287,8 +280,7 @@ in the ``patches/build`` directory of the ``yocto-4.12`` branch in the | |||
287 | ``yocto-kernel-cache`` Git repository. | 280 | ``yocto-kernel-cache`` Git repository. |
288 | 281 | ||
289 | The following listings show the ``build.scc`` file and part of the | 282 | The following listings show the ``build.scc`` file and part of the |
290 | ``modpost-mask-trivial-warnings.patch`` file: | 283 | ``modpost-mask-trivial-warnings.patch`` file:: |
291 | :: | ||
292 | 284 | ||
293 | patches/build/build.scc: | 285 | patches/build/build.scc: |
294 | patch arm-serialize-build-targets.patch | 286 | patch arm-serialize-build-targets.patch |
@@ -311,8 +303,8 @@ The following listings show the ``build.scc`` file and part of the | |||
311 | . | 303 | . |
312 | . | 304 | . |
313 | . | 305 | . |
314 | char *dump_write = NULL, *files_source = NULL; | 306 | char *dump_write = NULL, *files_source = NULL; |
315 | int opt; | 307 | int opt; |
316 | -- | 308 | -- |
317 | 2.10.1 | 309 | 2.10.1 |
318 | 310 | ||
@@ -320,7 +312,7 @@ The following listings show the ``build.scc`` file and part of the | |||
320 | 312 | ||
321 | The description file can | 313 | The description file can |
322 | include multiple patch statements where each statement handles a single | 314 | include multiple patch statements where each statement handles a single |
323 | patch. In the example ``build.scc`` file, five patch statements exist | 315 | patch. In the example ``build.scc`` file, there are five patch statements |
324 | for the five patches in the directory. | 316 | for the five patches in the directory. |
325 | 317 | ||
326 | You can create a typical ``.patch`` file using ``diff -Nurp`` or | 318 | You can create a typical ``.patch`` file using ``diff -Nurp`` or |
@@ -334,8 +326,7 @@ Features | |||
334 | 326 | ||
335 | Features are complex kernel Metadata types that consist of configuration | 327 | Features are complex kernel Metadata types that consist of configuration |
336 | fragments, patches, and possibly other feature description files. As an | 328 | fragments, patches, and possibly other feature description files. As an |
337 | example, consider the following generic listing: | 329 | example, consider the following generic listing:: |
338 | :: | ||
339 | 330 | ||
340 | features/myfeature.scc | 331 | features/myfeature.scc |
341 | define KFEATURE_DESCRIPTION "Enable myfeature" | 332 | define KFEATURE_DESCRIPTION "Enable myfeature" |
@@ -352,34 +343,30 @@ as how an additional feature description file is included with the | |||
352 | 343 | ||
353 | Typically, features are less granular than configuration fragments and | 344 | Typically, features are less granular than configuration fragments and |
354 | are more likely than configuration fragments and patches to be the types | 345 | are more likely than configuration fragments and patches to be the types |
355 | of things you want to specify in the ``KERNEL_FEATURES`` variable of the | 346 | of things you want to specify in the :term:`KERNEL_FEATURES` variable of the |
356 | Linux kernel recipe. See the "`Using Kernel Metadata in a | 347 | Linux kernel recipe. See the |
357 | Recipe <#using-kernel-metadata-in-a-recipe>`__" section earlier in the | 348 | ":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier |
358 | manual. | 349 | in the manual. |
359 | 350 | ||
360 | Kernel Types | 351 | Kernel Types |
361 | ------------ | 352 | ------------ |
362 | 353 | ||
363 | A kernel type defines a high-level kernel policy by aggregating | 354 | A kernel type defines a high-level kernel policy by aggregating non-hardware |
364 | non-hardware configuration fragments with patches you want to use when | 355 | configuration fragments with patches you want to use when building a Linux |
365 | building a Linux kernel of a specific type (e.g. a real-time kernel). | 356 | kernel of a specific type (e.g. a real-time kernel). Syntactically, kernel |
366 | Syntactically, kernel types are no different than features as described | 357 | types are no different than features as described in the |
367 | in the "`Features <#features>`__" section. The | 358 | ":ref:`kernel-dev/advanced:features`" section. The :term:`LINUX_KERNEL_TYPE` |
368 | :term:`LINUX_KERNEL_TYPE` | 359 | variable in the kernel recipe selects the kernel type. For example, in the |
369 | variable in the kernel recipe selects the kernel type. For example, in | 360 | ``linux-yocto_4.12.bb`` kernel recipe found in ``poky/meta/recipes-kernel/linux``, a |
370 | the ``linux-yocto_4.12.bb`` kernel recipe found in | 361 | :ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` |
371 | ``poky/meta/recipes-kernel/linux``, a | 362 | directive includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file, |
372 | :ref:`require <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` directive | 363 | which has the following statement that defines the default kernel type:: |
373 | includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file, | ||
374 | which has the following statement that defines the default kernel type: | ||
375 | :: | ||
376 | 364 | ||
377 | LINUX_KERNEL_TYPE ??= "standard" | 365 | LINUX_KERNEL_TYPE ??= "standard" |
378 | 366 | ||
379 | Another example would be the real-time kernel (i.e. | 367 | Another example would be the real-time kernel (i.e. |
380 | ``linux-yocto-rt_4.12.bb``). This kernel recipe directly sets the kernel | 368 | ``linux-yocto-rt_4.12.bb``). This kernel recipe directly sets the kernel |
381 | type as follows: | 369 | type as follows:: |
382 | :: | ||
383 | 370 | ||
384 | LINUX_KERNEL_TYPE = "preempt-rt" | 371 | LINUX_KERNEL_TYPE = "preempt-rt" |
385 | 372 | ||
@@ -412,8 +399,7 @@ for Linux Yocto kernels: | |||
412 | For any given kernel type, the Metadata is defined by the ``.scc`` (e.g. | 399 | For 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`` | 400 | ``standard.scc``). Here is a partial listing for the ``standard.scc`` |
414 | file, which is found in the ``ktypes/standard`` directory of the | 401 | file, which is found in the ``ktypes/standard`` directory of the |
415 | ``yocto-kernel-cache`` Git repository: | 402 | ``yocto-kernel-cache`` Git repository:: |
416 | :: | ||
417 | 403 | ||
418 | # Include this kernel type fragment to get the standard features and | 404 | # Include this kernel type fragment to get the standard features and |
419 | # configuration values. | 405 | # configuration values. |
@@ -482,15 +468,13 @@ Description Overview | |||
482 | For simplicity, consider the following root BSP layer description files | 468 | For simplicity, consider the following root BSP layer description files |
483 | for the BeagleBone board. These files employ both a structure and naming | 469 | for the BeagleBone board. These files employ both a structure and naming |
484 | convention for consistency. The naming convention for the file is as | 470 | convention for consistency. The naming convention for the file is as |
485 | follows: | 471 | follows:: |
486 | :: | ||
487 | 472 | ||
488 | bsp_root_name-kernel_type.scc | 473 | bsp_root_name-kernel_type.scc |
489 | 474 | ||
490 | Here are some example root layer | 475 | Here are some example root layer |
491 | BSP filenames for the BeagleBone Board BSP, which is supported by the | 476 | BSP filenames for the BeagleBone Board BSP, which is supported by the |
492 | Yocto Project: | 477 | Yocto Project:: |
493 | :: | ||
494 | 478 | ||
495 | beaglebone-standard.scc | 479 | beaglebone-standard.scc |
496 | beaglebone-preempt-rt.scc | 480 | beaglebone-preempt-rt.scc |
@@ -498,8 +482,7 @@ Yocto Project: | |||
498 | Each file uses the root name (i.e "beaglebone") BSP name followed by the | 482 | Each file uses the root name (i.e "beaglebone") BSP name followed by the |
499 | kernel type. | 483 | kernel type. |
500 | 484 | ||
501 | Examine the ``beaglebone-standard.scc`` file: | 485 | Examine the ``beaglebone-standard.scc`` file:: |
502 | :: | ||
503 | 486 | ||
504 | define KMACHINE beaglebone | 487 | define KMACHINE beaglebone |
505 | define KTYPE standard | 488 | define KTYPE standard |
@@ -523,34 +506,31 @@ description as meeting the criteria set by the recipe being built. This | |||
523 | example supports the "beaglebone" machine for the "standard" kernel and | 506 | example supports the "beaglebone" machine for the "standard" kernel and |
524 | the "arm" architecture. | 507 | the "arm" architecture. |
525 | 508 | ||
526 | Be aware that a hard link between the ``KTYPE`` variable and a kernel | 509 | Be aware that there is no hard link between the :term:`KTYPE` variable and a kernel |
527 | type description file does not exist. Thus, if you do not have the | 510 | type description file. Thus, if you do not have the |
528 | kernel type defined in your kernel Metadata as it is here, you only need | 511 | kernel type defined in your kernel Metadata as it is here, you only need |
529 | to ensure that the | 512 | to ensure that the |
530 | :term:`LINUX_KERNEL_TYPE` | 513 | :term:`LINUX_KERNEL_TYPE` |
531 | variable in the kernel recipe and the ``KTYPE`` variable in the BSP | 514 | variable in the kernel recipe and the :term:`KTYPE` variable in the BSP |
532 | description file match. | 515 | description file match. |
533 | 516 | ||
534 | To separate your kernel policy from your hardware configuration, you | 517 | To separate your kernel policy from your hardware configuration, you |
535 | include a kernel type (``ktype``), such as "standard". In the previous | 518 | include a kernel type (``ktype``), such as "standard". In the previous |
536 | example, this is done using the following: | 519 | example, this is done using the following:: |
537 | :: | ||
538 | 520 | ||
539 | include ktypes/standard/standard.scc | 521 | include ktypes/standard/standard.scc |
540 | 522 | ||
541 | This file aggregates all the configuration | 523 | This file aggregates all the configuration |
542 | fragments, patches, and features that make up your standard kernel | 524 | fragments, patches, and features that make up your standard kernel |
543 | policy. See the "`Kernel Types <#kernel-types>`__" section for more | 525 | policy. See the ":ref:`kernel-dev/advanced:kernel types`" section for more |
544 | information. | 526 | information. |
545 | 527 | ||
546 | To aggregate common configurations and features specific to the kernel | 528 | To aggregate common configurations and features specific to the kernel |
547 | for `mybsp`, use the following: | 529 | for `mybsp`, use the following:: |
548 | :: | ||
549 | 530 | ||
550 | include mybsp.scc | 531 | include mybsp.scc |
551 | 532 | ||
552 | You can see that in the BeagleBone example with the following: | 533 | You can see that in the BeagleBone example with the following:: |
553 | :: | ||
554 | 534 | ||
555 | include beaglebone.scc | 535 | include beaglebone.scc |
556 | 536 | ||
@@ -558,15 +538,13 @@ For information on how to break a complete ``.config`` file into the various | |||
558 | configuration fragments, see the ":ref:`kernel-dev/common:creating configuration fragments`" section. | 538 | configuration fragments, see the ":ref:`kernel-dev/common:creating configuration fragments`" section. |
559 | 539 | ||
560 | Finally, if you have any configurations specific to the hardware that | 540 | Finally, if you have any configurations specific to the hardware that |
561 | are not in a ``*.scc`` file, you can include them as follows: | 541 | are not in a ``*.scc`` file, you can include them as follows:: |
562 | :: | ||
563 | 542 | ||
564 | kconf hardware mybsp-extra.cfg | 543 | kconf hardware mybsp-extra.cfg |
565 | 544 | ||
566 | The BeagleBone example does not include these | 545 | The BeagleBone example does not include these |
567 | types of configurations. However, the Malta 32-bit board does | 546 | types of configurations. However, the Malta 32-bit board does |
568 | ("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file: | 547 | ("mti-malta32"). Here is the ``mti-malta32-le-standard.scc`` file:: |
569 | :: | ||
570 | 548 | ||
571 | define KMACHINE mti-malta32-le | 549 | define KMACHINE mti-malta32-le |
572 | define KMACHINE qemumipsel | 550 | define KMACHINE qemumipsel |
@@ -585,15 +563,7 @@ Example | |||
585 | Many real-world examples are more complex. Like any other ``.scc`` file, | 563 | Many real-world examples are more complex. Like any other ``.scc`` file, |
586 | BSP descriptions can aggregate features. Consider the Minnow BSP | 564 | BSP descriptions can aggregate features. Consider the Minnow BSP |
587 | definition given the ``linux-yocto-4.4`` branch of the | 565 | definition given the ``linux-yocto-4.4`` branch of the |
588 | ``yocto-kernel-cache`` (i.e. | 566 | ``yocto-kernel-cache`` (i.e. ``yocto-kernel-cache/bsp/minnow/minnow.scc``):: |
589 | ``yocto-kernel-cache/bsp/minnow/minnow.scc``): | ||
590 | |||
591 | .. note:: | ||
592 | |||
593 | Although the Minnow Board BSP is unused, the Metadata remains and is | ||
594 | being used here just as an example. | ||
595 | |||
596 | :: | ||
597 | 567 | ||
598 | include cfg/x86.scc | 568 | include cfg/x86.scc |
599 | include features/eg20t/eg20t.scc | 569 | include features/eg20t/eg20t.scc |
@@ -616,6 +586,11 @@ definition given the ``linux-yocto-4.4`` branch of the | |||
616 | kconf hardware minnow.cfg | 586 | kconf hardware minnow.cfg |
617 | kconf hardware minnow-dev.cfg | 587 | kconf hardware minnow-dev.cfg |
618 | 588 | ||
589 | .. note:: | ||
590 | |||
591 | Although the Minnow Board BSP is unused, the Metadata remains and is | ||
592 | being used here just as an example. | ||
593 | |||
619 | The ``minnow.scc`` description file includes a hardware configuration | 594 | The ``minnow.scc`` description file includes a hardware configuration |
620 | fragment (``minnow.cfg``) specific to the Minnow BSP as well as several | 595 | fragment (``minnow.cfg``) specific to the Minnow BSP as well as several |
621 | more general configuration fragments and features enabling hardware | 596 | more general configuration fragments and features enabling hardware |
@@ -623,8 +598,7 @@ found on the machine. This ``minnow.scc`` description file is then | |||
623 | included in each of the three "minnow" description files for the | 598 | included in each of the three "minnow" description files for the |
624 | supported kernel types (i.e. "standard", "preempt-rt", and "tiny"). | 599 | supported kernel types (i.e. "standard", "preempt-rt", and "tiny"). |
625 | Consider the "minnow" description for the "standard" kernel type (i.e. | 600 | Consider the "minnow" description for the "standard" kernel type (i.e. |
626 | ``minnow-standard.scc``): | 601 | ``minnow-standard.scc``):: |
627 | :: | ||
628 | 602 | ||
629 | define KMACHINE minnow | 603 | define KMACHINE minnow |
630 | define KTYPE standard | 604 | define KTYPE standard |
@@ -656,8 +630,7 @@ that defines all enabled hardware for the BSP that is common to all | |||
656 | kernel types. Using this command significantly reduces duplication. | 630 | kernel types. Using this command significantly reduces duplication. |
657 | 631 | ||
658 | Now consider the "minnow" description for the "tiny" kernel type (i.e. | 632 | Now consider the "minnow" description for the "tiny" kernel type (i.e. |
659 | ``minnow-tiny.scc``): | 633 | ``minnow-tiny.scc``):: |
660 | :: | ||
661 | 634 | ||
662 | define KMACHINE minnow | 635 | define KMACHINE minnow |
663 | define KTYPE tiny | 636 | define KTYPE tiny |
@@ -678,7 +651,7 @@ Notice again the three critical variables: | |||
678 | :term:`KMACHINE`, | 651 | :term:`KMACHINE`, |
679 | :term:`KTYPE`, and | 652 | :term:`KTYPE`, and |
680 | :term:`KARCH`. Of these variables, only | 653 | :term:`KARCH`. Of these variables, only |
681 | ``KTYPE`` has changed to specify the "tiny" kernel type. | 654 | :term:`KTYPE` has changed to specify the "tiny" kernel type. |
682 | 655 | ||
683 | Kernel Metadata Location | 656 | Kernel Metadata Location |
684 | ======================== | 657 | ======================== |
@@ -709,19 +682,17 @@ Recipe-Space Metadata | |||
709 | --------------------- | 682 | --------------------- |
710 | 683 | ||
711 | When stored in recipe-space, the kernel Metadata files reside in a | 684 | When stored in recipe-space, the kernel Metadata files reside in a |
712 | directory hierarchy below | 685 | directory hierarchy below :term:`FILESEXTRAPATHS`. For |
713 | :term:`FILESEXTRAPATHS`. For | 686 | a linux-yocto recipe or for a Linux kernel recipe derived by copying |
714 | a linux-yocto recipe or for a Linux kernel recipe derived by copying and | 687 | :oe_git:`meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb |
715 | modifying | 688 | </openembedded-core/tree/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb>` |
716 | ``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to | 689 | into your layer and modifying it, :term:`FILESEXTRAPATHS` is typically set to |
717 | a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to | ||
718 | ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``. | 690 | ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``. |
719 | See the ":ref:`kernel-dev/common:modifying an existing recipe`" | 691 | See the ":ref:`kernel-dev/common:modifying an existing recipe`" |
720 | section for more information. | 692 | section for more information. |
721 | 693 | ||
722 | Here is an example that shows a trivial tree of kernel Metadata stored | 694 | Here is an example that shows a trivial tree of kernel Metadata stored |
723 | in recipe-space within a BSP layer: | 695 | in recipe-space within a BSP layer:: |
724 | :: | ||
725 | 696 | ||
726 | meta-my_bsp_layer/ | 697 | meta-my_bsp_layer/ |
727 | `-- recipes-kernel | 698 | `-- recipes-kernel |
@@ -740,14 +711,13 @@ and fetches any files referenced in the ``.scc`` files by the | |||
740 | ``include``, ``patch``, or ``kconf`` commands. Because of this, it is | 711 | ``include``, ``patch``, or ``kconf`` commands. Because of this, it is |
741 | necessary to bump the recipe :term:`PR` | 712 | necessary to bump the recipe :term:`PR` |
742 | value when changing the content of files not explicitly listed in the | 713 | value when changing the content of files not explicitly listed in the |
743 | ``SRC_URI``. | 714 | :term:`SRC_URI`. |
744 | 715 | ||
745 | If the BSP description is in recipe space, you cannot simply list the | 716 | If 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 | 717 | ``*.scc`` in the :term:`SRC_URI` statement. You need to use the following |
747 | form from your kernel append file: | 718 | form from your kernel append file:: |
748 | :: | ||
749 | 719 | ||
750 | SRC_URI_append_myplatform = " \ | 720 | SRC_URI:append:myplatform = " \ |
751 | file://myplatform;type=kmeta;destsuffix=myplatform \ | 721 | file://myplatform;type=kmeta;destsuffix=myplatform \ |
752 | " | 722 | " |
753 | 723 | ||
@@ -758,37 +728,35 @@ When stored outside of the recipe-space, the kernel Metadata files | |||
758 | reside in a separate repository. The OpenEmbedded build system adds the | 728 | reside in a separate repository. The OpenEmbedded build system adds the |
759 | Metadata to the build as a "type=kmeta" repository through the | 729 | Metadata to the build as a "type=kmeta" repository through the |
760 | :term:`SRC_URI` variable. As an | 730 | :term:`SRC_URI` variable. As an |
761 | example, consider the following ``SRC_URI`` statement from the | 731 | example, consider the following :term:`SRC_URI` statement from the |
762 | ``linux-yocto_4.12.bb`` kernel recipe: | 732 | ``linux-yocto_5.15.bb`` kernel recipe:: |
763 | :: | ||
764 | |||
765 | 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}" | ||
767 | 733 | ||
734 | SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH};protocol=https \ | ||
735 | git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA};protocol=https" | ||
768 | 736 | ||
769 | ``${KMETA}``, in this context, is simply used to name the directory into | 737 | ``${KMETA}``, in this context, is simply used to name the directory into |
770 | which the Git fetcher places the Metadata. This behavior is no different | 738 | which the Git fetcher places the Metadata. This behavior is no different |
771 | than any multi-repository ``SRC_URI`` statement used in a recipe (e.g. | 739 | than any multi-repository :term:`SRC_URI` statement used in a recipe (e.g. |
772 | see the previous section). | 740 | see the previous section). |
773 | 741 | ||
774 | You can keep kernel Metadata in a "kernel-cache", which is a directory | 742 | You can keep kernel Metadata in a "kernel-cache", which is a directory |
775 | containing configuration fragments. As with any Metadata kept outside | 743 | containing configuration fragments. As with any Metadata kept outside |
776 | the recipe-space, you simply need to use the ``SRC_URI`` statement with | 744 | the recipe-space, you simply need to use the :term:`SRC_URI` statement with |
777 | the "type=kmeta" attribute. Doing so makes the kernel Metadata available | 745 | the "type=kmeta" attribute. Doing so makes the kernel Metadata available |
778 | during the configuration phase. | 746 | during the configuration phase. |
779 | 747 | ||
780 | If you modify the Metadata, you must not forget to update the ``SRCREV`` | 748 | If you modify the Metadata, you must not forget to update the :term:`SRCREV` |
781 | statements in the kernel's recipe. In particular, you need to update the | 749 | statements in the kernel's recipe. In particular, you need to update the |
782 | ``SRCREV_meta`` variable to match the commit in the ``KMETA`` branch you | 750 | ``SRCREV_meta`` variable to match the commit in the ``KMETA`` branch you |
783 | wish to use. Changing the data in these branches and not updating the | 751 | wish to use. Changing the data in these branches and not updating the |
784 | ``SRCREV`` statements to match will cause the build to fetch an older | 752 | :term:`SRCREV` statements to match will cause the build to fetch an older |
785 | commit. | 753 | commit. |
786 | 754 | ||
787 | Organizing Your Source | 755 | Organizing Your Source |
788 | ====================== | 756 | ====================== |
789 | 757 | ||
790 | Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux | 758 | Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux |
791 | kernel sources that have only a single branch - "master". This type of | 759 | kernel sources that have only a single branch. This type of |
792 | repository structure is fine for linear development supporting a single | 760 | repository structure is fine for linear development supporting a single |
793 | machine and architecture. However, if you work with multiple boards and | 761 | machine and architecture. However, if you work with multiple boards and |
794 | architectures, a kernel source repository with multiple branches is more | 762 | architectures, a kernel source repository with multiple branches is more |
@@ -797,11 +765,11 @@ board to boot. Sometimes, these patches are works-in-progress or | |||
797 | fundamentally wrong, yet they are still necessary for specific boards. | 765 | fundamentally wrong, yet they are still necessary for specific boards. |
798 | In these situations, you most likely do not want to include these | 766 | In these situations, you most likely do not want to include these |
799 | patches in every kernel you build (i.e. have the patches as part of the | 767 | patches in every kernel you build (i.e. have the patches as part of the |
800 | lone "master" branch). It is situations like these that give rise to | 768 | default branch). It is situations like these that give rise to |
801 | multiple branches used within a Linux kernel sources Git repository. | 769 | multiple branches used within a Linux kernel sources Git repository. |
802 | 770 | ||
803 | Repository organization strategies exist that maximize source reuse, | 771 | Here are repository organization strategies maximizing source reuse, |
804 | remove redundancy, and logically order your changes. This section | 772 | removing redundancy, and logically ordering your changes. This section |
805 | presents strategies for the following cases: | 773 | presents strategies for the following cases: |
806 | 774 | ||
807 | - Encapsulating patches in a feature description and only including the | 775 | - Encapsulating patches in a feature description and only including the |
@@ -825,11 +793,11 @@ Given this scenario, you do not need to create any branches in the | |||
825 | source repository. Rather, you just take the static patches you need and | 793 | source repository. Rather, you just take the static patches you need and |
826 | encapsulate them within a feature description. Once you have the feature | 794 | encapsulate them within a feature description. Once you have the feature |
827 | description, you simply include that into the BSP description as | 795 | description, you simply include that into the BSP description as |
828 | described in the "`BSP Descriptions <#bsp-descriptions>`__" section. | 796 | described in the ":ref:`kernel-dev/advanced:bsp descriptions`" section. |
829 | 797 | ||
830 | You can find information on how to create patches and BSP descriptions | 798 | You can find information on how to create patches and BSP descriptions |
831 | in the "`Patches <#patches>`__" and "`BSP | 799 | in the ":ref:`kernel-dev/advanced:patches`" and |
832 | Descriptions <#bsp-descriptions>`__" sections. | 800 | ":ref:`kernel-dev/advanced:bsp descriptions`" sections. |
833 | 801 | ||
834 | Machine Branches | 802 | Machine Branches |
835 | ---------------- | 803 | ---------------- |
@@ -837,21 +805,19 @@ Machine Branches | |||
837 | When you have multiple machines and architectures to support, or you are | 805 | When you have multiple machines and architectures to support, or you are |
838 | actively working on board support, it is more efficient to create | 806 | actively working on board support, it is more efficient to create |
839 | branches in the repository based on individual machines. Having machine | 807 | branches in the repository based on individual machines. Having machine |
840 | branches allows common source to remain in the "master" branch with any | 808 | branches allows common source to remain in the development branch with any |
841 | features specific to a machine stored in the appropriate machine branch. | 809 | features specific to a machine stored in the appropriate machine branch. |
842 | This organization method frees you from continually reintegrating your | 810 | This organization method frees you from continually reintegrating your |
843 | patches into a feature. | 811 | patches into a feature. |
844 | 812 | ||
845 | Once you have a new branch, you can set up your kernel Metadata to use | 813 | Once you have a new branch, you can set up your kernel Metadata to use |
846 | the branch a couple different ways. In the recipe, you can specify the | 814 | the branch a couple different ways. In the recipe, you can specify the |
847 | new branch as the ``KBRANCH`` to use for the board as follows: | 815 | new branch as the :term:`KBRANCH` to use for the board as follows:: |
848 | :: | ||
849 | 816 | ||
850 | KBRANCH = "mynewbranch" | 817 | KBRANCH = "mynewbranch" |
851 | 818 | ||
852 | Another method is to use the ``branch`` command in the BSP | 819 | Another method is to use the ``branch`` command in the BSP |
853 | description: | 820 | description:: |
854 | :: | ||
855 | 821 | ||
856 | mybsp.scc: | 822 | mybsp.scc: |
857 | define KMACHINE mybsp | 823 | define KMACHINE mybsp |
@@ -865,15 +831,13 @@ description: | |||
865 | 831 | ||
866 | If you find yourself with numerous branches, you might consider using a | 832 | If you find yourself with numerous branches, you might consider using a |
867 | hierarchical branching system similar to what the Yocto Linux Kernel Git | 833 | hierarchical branching system similar to what the Yocto Linux Kernel Git |
868 | repositories use: | 834 | repositories use:: |
869 | :: | ||
870 | 835 | ||
871 | common/kernel_type/machine | 836 | common/kernel_type/machine |
872 | 837 | ||
873 | If you had two kernel types, "standard" and "small" for instance, three | 838 | If you had two kernel types, "standard" and "small" for instance, three |
874 | machines, and common as ``mydir``, the branches in your Git repository | 839 | machines, and common as ``mydir``, the branches in your Git repository |
875 | might look like this: | 840 | might look like this:: |
876 | :: | ||
877 | 841 | ||
878 | mydir/base | 842 | mydir/base |
879 | mydir/standard/base | 843 | mydir/standard/base |
@@ -905,8 +869,7 @@ that have to be regularly updated. The Yocto Project Linux kernel tools | |||
905 | provide for this with the ``git merge`` command. | 869 | provide for this with the ``git merge`` command. |
906 | 870 | ||
907 | To merge a feature branch into a BSP, insert the ``git merge`` command | 871 | To merge a feature branch into a BSP, insert the ``git merge`` command |
908 | after any ``branch`` commands: | 872 | after any ``branch`` commands:: |
909 | :: | ||
910 | 873 | ||
911 | mybsp.scc: | 874 | mybsp.scc: |
912 | define KMACHINE mybsp | 875 | define KMACHINE mybsp |