1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
<chapter id='kernel-dev-intro'>
<title>Introduction</title>
<section id='kernel-dev-overview'>
<title>Overview</title>
<para>
Regardless of how you intend to make use of the Yocto Project,
chances are you will work with the Linux kernel.
This manual describes how to set up your build host to support
kernel development, introduces the kernel development process,
provides background information on the Yocto Linux kernel
<ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
describes common tasks you can perform using the kernel tools,
and shows you how to use the kernel Metadata needed to work with
the kernel inside the Yocto Project.
</para>
<para>
Each Yocto Project release has a set of Yocto Linux kernel recipes,
whose Git repositories you can view in the Yocto
<ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> under
the "Yocto Linux Kernel" heading.
New recipes for the release track the latest Linux kernel
upstream developments from
<ulink url='http://www.kernel.org'></ulink> and introduce
newly-supported platforms.
Previous recipes in the release are refreshed and supported for at
least one additional Yocto Project release.
As they align, these previous releases are updated to include the
latest from the
<ulink url='&YOCTO_HOME_URL;/organization/long-term-support-initiative-ltsi'>Long Term Support Initiative</ulink>
(LTSI) project.
Also included is a Yocto Linux kernel development recipe
(<filename>linux-yocto-dev.bb</filename>) should you want to work
with the very latest in upstream Yocto Linux kernel development and
kernel Metadata development.
<note>
For more on Yocto Linux kernels, see the
"<link linkend='kernel-big-picture'>Yocto Project Kernel Development and Maintenance</link>
section.
</note>
</para>
<para>
The Yocto Project also provides a powerful set of kernel
tools for managing Yocto Linux kernel sources and configuration data.
You can use these tools to make a single configuration change,
apply multiple patches, or work with your own kernel sources.
</para>
<para>
In particular, the kernel tools allow you to generate configuration
fragments that specify only what you must, and nothing more.
Configuration fragments only need to contain the highest level
visible <filename>CONFIG</filename> options as presented by the
Yocto Linux kernel <filename>menuconfig</filename> system.
Contrast this against a complete Yocto Linux kernel
<filename>.config</filename> file, which includes all the automatically
selected <filename>CONFIG</filename> options.
This efficiency reduces your maintenance effort and allows you
to further separate your configuration in ways that make sense for
your project.
A common split separates policy and hardware.
For example, all your kernels might support the
<filename>proc</filename> and <filename>sys</filename> filesystems,
but only specific boards require sound, USB, or specific drivers.
Specifying these configurations individually allows you to aggregate
them together as needed, but maintains them in only one place.
Similar logic applies to separating source changes.
</para>
<para>
If you do not maintain your own kernel sources and need to make
only minimal changes to the sources, the released recipes provide a
vetted base upon which to layer your changes.
Doing so allows you to benefit from the continual kernel
integration and testing performed during development of the
Yocto Project.
</para>
<para>
If, instead, you have a very specific Linux kernel source tree
and are unable to align with one of the official Yocto Linux kernel
recipes, an alternative exists by which you can use the Yocto
Project Linux kernel tools with your own kernel sources.
</para>
</section>
<section id='preparing-the-build-host-to-work-on-the-kernel'>
<title>Preparing the Build Host to Work on the Kernel</title>
<para>
Before you can do any kernel development, you need to be
sure your build host is set up to use the Yocto Project.
For information on how to get set up, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Setting Up to Use the Yocto Project</ulink>"
section in the Yocto Project Development Manual.
Part of preparing the system is creating a local Git
repository of the
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
(<filename>poky</filename>) on your system.
Follow the steps in the
"<ulink url='&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository'>Cloning the <filename>poky</filename> Repository</ulink>"
section in the Yocto Project Development Manual to set up your
Source Directory.
</para>
<para>
Kernel development is best accomplished using
<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'><filename>devtool</filename></ulink>
and not through traditional kernel workflow methods.
The remainder of this section provides information for both scenarios.
</para>
<section id='getting-ready-to-develop-using-devtool'>
<title>Getting Ready to Develop using <filename>devtool</filename></title>
<para role='writernotes'>
Sections as follows:
<orderedlist>
<listitem><para role='writernotes'>
Source the oe-init-build-env script.
At this point, we assume the build host is set up and
<filename>poky</filename> repository has been cloned.
</para></listitem>
<listitem><para role='writernotes'>
Be sure your <filename>local.conf</filename> file has
the correct
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
variable set for the target hardware on which your
kernel image runs.
Also have the
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><filename>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</filename></ulink>
variable set equal to "kernel-modules".
</para></listitem>
<listitem><para role='writernotes'>
Create a layer for later that will contain your patches
(if any) to the kernel.
</para></listitem>
<listitem><para role='writernotes'>
Build the extensible SDK.
</para></listitem>
<listitem><para role='writernotes'>
Install the extensible SDK.
</para></listitem>
<listitem><para role='writernotes'>
Set up the terminal so that you can work with the
extensible SDK.
This terminal is known as the "eSDK Terminal" unlike the
terminal that is set up to run BitBake, which is known
as the "BitBake Terminal".
</para></listitem>
<listitem><para role='writernotes'>
Build the initial image using the extensible SDK.
</para></listitem>
</orderedlist>
</para>
<para role='writernotes'>
At this point, the user has enough stuff set up to work on the
kernel.
I will put a section in the "Common Tasks" area of this manual
that finished out how to make a modification to the kernel.
</para>
</section>
<section id='getting-ready-for-traditional-kernel-development'>
<title>Getting Ready for Traditional Kernel Development</title>
<para>
For traditional kernel development using the Yocto
Project, you need to establish local copies of the
kernel source.
You can find Git repositories of supported Yocto Project
kernels organized under "Yocto Linux Kernel" in the Yocto
Project Source Repositories at
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
</para>
<para>
This setup can involve creating a bare clone of the
Yocto Project kernel and then copying that cloned
repository.
You can create the bare clone and the copy of the bare
clone anywhere you like.
For simplicity, it is recommended that you create these
structures outside of the
<ulink url='&YOCTO_DOCS_REF_URL;source-directory'>Source Directory</ulink>,
which is usually named <filename>poky</filename>.
</para>
<para>
The following steps show how to create a bare clone of the
<filename>linux-yocto-4.4</filename> kernel and then
create a copy of that clone:
<note>
When you have a local Yocto Project kernel Git
repository, you can reference that repository rather than
the upstream Git repository as part of the
<filename>clone</filename> command.
Doing so can speed up the process.
</note>
<orderedlist>
<listitem><para>
<emphasis>Create the Bare Clone:</emphasis>
In the following example, the bare clone is named
<filename>linux-yocto-4.4.git</filename>:
<literallayout class='monospaced'>
$ git clone ‐‐bare git://git.yoctoproject.org/linux-yocto-4.4 linux-yocto-4.4.git
Cloning into bare repository 'linux-yocto-4.4.git'...
remote: Counting objects: 4543903, done.
remote: Compressing objects: 100% (695618/695618), done.
remote: Total 4543903 (delta 3818435), reused 4541724 (delta 3816256)
Receiving objects: 100% (4543903/4543903), 801.08 MiB | 6.55 MiB/s, done.
Resolving deltas: 100% (3818435/3818435), done.
Checking connectivity... done.
</literallayout>
</para></listitem>
<listitem><para>
<emphasis>Create the Copy of the Bare Clone:</emphasis>
In the following command, the copy of the bare clone
is named <filename>my-linux-yocto-4.4-work</filename>:
<literallayout class='monospaced'>
$ git clone linux-yocto-4.4.git my-linux-yocto-4.4-work
Cloning into 'my-linux-yocto-4.4-work'...
done.
Checking out files: 100% (52221/52221), done.
</literallayout>
</para></listitem>
<listitem><para>
<emphasis>Cloning the <filename>meta-yocto-kernel-extras</filename> Repository:</emphasis>
The <filename>meta-yocto-kernel-extras</filename> Git
repository contains Metadata needed only if you are
modifying and building the kernel image.
In particular, it contains the kernel BitBake append
(<filename>.bbappend</filename>) files that you edit to
point to your locally modified kernel source files and
to build the kernel image.
Pointing to these local files is much more efficient
than requiring a download of the kernel's source files
from upstream each time you make changes to the kernel.
</para>
<para>You can find the
<filename>meta-yocto-kernel-extras</filename> Git
Repository in the "Yocto Metadata Layers" area of the
Yocto Project Source Repositories at
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
It is good practice to create this Git repository
inside the Source Directory.</para>
<para>Following is an example that creates the
<filename>meta-yocto-kernel-extras</filename> Git
repository inside the Source Directory, which is named
<filename>poky</filename>, in this case:
<literallayout class='monospaced'>
$ cd ~/poky
$ git clone git://git.yoctoproject.org/meta-yocto-kernel-extras meta-yocto-kernel-extras
Cloning into 'meta-yocto-kernel-extras'...
remote: Counting objects: 727, done.
remote: Compressing objects: 100% (452/452), done.
remote: Total 727 (delta 260), reused 719 (delta 252)
Receiving objects: 100% (727/727), 536.36 KiB | 0 bytes/s, done.
Resolving deltas: 100% (260/260), done.
Checking connectivity... done.
</literallayout>
</para></listitem>
</orderedlist>
</para>
</section>
</section>
<section id='kernel-modification-workflow'>
<title>Kernel Modification Workflow</title>
<para>
Kernel modification involves changing the Yocto Project kernel,
which could involve changing configuration options as well as adding
new kernel recipes.
Configuration changes can be added in the form of configuration
fragments, while recipe modification comes through the kernel's
<filename>recipes-kernel</filename> area in a kernel layer you create.
</para>
<para>
This section presents a high-level overview of the Yocto Project
kernel modification workflow.
You can find additional information here:
<itemizedlist>
<listitem><para>
The
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
section.
</para></listitem>
<listitem><para>
The
"<ulink url='&YOCTO_DOCS_DEV_URL;#configuring-the-kernel'>Configuring the Kernel</ulink>"
section in the Yocto Project Development Manual.
</para></listitem>
</itemizedlist>
This illustration and the following list summarizes the kernel
modification general workflow.
<imagedata fileref="figures/kernel-dev-flow.png"
width="9in" depth="5in" align="center" scalefit="1" />
</para>
<para>
<orderedlist>
<listitem><para>
<emphasis>Set up Your Host Development System to Support
Development Using the Yocto Project</emphasis>:
See the
"<link linkend='preparing-the-build-host-to-work-on-the-kernel'>Preparing the Build Host to Work on the Kernel</link>"
section and be sure you have everything set up to use the
Yocto Project, including a local Git repository of the
<ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
(<filename>poky</filename>).
</para></listitem>
<listitem><para>
<emphasis>Establish the Temporary Kernel Source Files</emphasis>:
Temporary kernel source files are kept in the
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
created by the OpenEmbedded build system when you run BitBake.
If you have never built the kernel in which you are
interested, you need to run an initial build to
establish local kernel source files.</para>
<para>If you are building an image for the first time, you
need to get the build environment ready by sourcing an
environment setup script
(i.e. <filename>oe-init-build-env</filename> or
<filename>oe-init-build-env-memres</filename>).
You also need to be sure two key configuration files
(<filename>local.conf</filename> and
<filename>bblayers.conf</filename>) are configured
appropriately.</para>
<para>The entire process for building an image is overviewed
in the
"<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
section of the Yocto Project Quick Start.
You might want to reference this information.
You can find more information on BitBake in the
<ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
</para>
<para>The build process supports several types of images to
satisfy different needs.
See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
chapter in the Yocto Project Reference Manual for information
on supported images.
</para></listitem>
<listitem><para>
<emphasis>Make Changes to the Kernel Source Code if
applicable</emphasis>:
Modifying the kernel does not always mean directly
changing source files.
However, if you have to do this, you make the changes to the
files in the Build Directory.
</para></listitem>
<listitem><para>
<emphasis>Make Kernel Configuration Changes if
Applicable</emphasis>:
If your situation calls for changing the kernel's
configuration, you can use
<link linkend='generating-configuration-files'><filename>menuconfig</filename></link>,
which allows you to interactively develop and test the
configuration changes you are making to the kernel.
Saving changes you make with <filename>menuconfig</filename>
updates the kernel's <filename>.config</filename> file.
<note><title>Warning</title>
Try to resist the temptation to directly edit an
existing <filename>.config</filename> file, which is
found in the Build Directory among the source code
used for the build (e.g. see the workflow illustration
in the
"<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
section).
Doing so, can produce unexpected results when the
OpenEmbedded build system regenerates the configuration
file.
</note>
Once you are satisfied with the configuration
changes made using <filename>menuconfig</filename>
and you have saved them, you can directly compare the
resulting <filename>.config</filename> file against an
existing original and gather those changes into a
<ulink url='&YOCTO_DOCS_DEV_URL;#creating-config-fragments'>configuration fragment file</ulink>
to be referenced from within the kernel's
<filename>.bbappend</filename> file.</para>
<para>Additionally, if you are working in a BSP layer
and need to modify the BSP's kernel's configuration,
you can use the
<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'><filename>yocto-kernel</filename></ulink>
script as well as <filename>menuconfig</filename>.
The <filename>yocto-kernel</filename> script lets
you interactively set up kernel configurations.
</para></listitem>
<listitem><para>
<emphasis>Rebuild the Kernel Image With Your Changes</emphasis>:
Rebuilding the kernel image applies your changes.
</para></listitem>
</orderedlist>
</para>
</section>
<section id='kernel-dev-other-resources'>
<title>Other Resources</title>
<para>
The remainder of this manual provides instructions for completing
specific Linux kernel development tasks.
These instructions assume you are comfortable working with
<ulink url='http://openembedded.org/wiki/Bitbake'>BitBake</ulink>
recipes and basic open-source development tools.
Understanding these concepts will facilitate the process of working
with the kernel recipes.
If you find you need some additional background, please be sure to
review and understand the following documentation:
<itemizedlist>
<listitem><para>
<ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>
</para></listitem>
<listitem><para>
<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'><filename>devtool</filename> workflow</ulink>
as described in the Yocto Project Software Development Kit
(SDK) Developer's Guide.
</para></listitem>
<listitem><para>
The
"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" section
in the Yocto Project Development Manual
</para></listitem>
<listitem><para>
The
"<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
section.
</para></listitem>
</itemizedlist>
</para>
<para>
Finally, while this document focuses on the manual creation of
recipes, patches, and configuration files, the Yocto Project
Board Support Package (BSP) tools are available to automate
this process with existing content and work well to create the
initial framework and boilerplate code.
For details on these tools, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>Using the Yocto Project's BSP Tools</ulink>"
section in the Yocto Project Board Support Package (BSP) Developer's
Guide.
</para>
</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
-->
|