summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2011-08-11 07:09:33 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-08-15 15:27:02 +0100
commit3c631db138337f380d1a7f20932f9c38126d6ec1 (patch)
tree3a7639c31071b4784892be50e77685a55dfaacd4 /documentation
parentfe76c380ccafcdf95bc5f859cc26bd5b5788445f (diff)
downloadpoky-3c631db138337f380d1a7f20932f9c38126d6ec1.tar.gz
documentation/dev-manual/dev-manual-kernel-appendix.xml: edit pass.
(From yocto-docs rev: 77dec8c28ce519b6b9c2afd2a5410653fdfd22e8) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/dev-manual/dev-manual-kernel-appendix.xml205
1 files changed, 116 insertions, 89 deletions
diff --git a/documentation/dev-manual/dev-manual-kernel-appendix.xml b/documentation/dev-manual/dev-manual-kernel-appendix.xml
index d4c8bd566a..2304f0a898 100644
--- a/documentation/dev-manual/dev-manual-kernel-appendix.xml
+++ b/documentation/dev-manual/dev-manual-kernel-appendix.xml
@@ -7,9 +7,9 @@
7 7
8 <para> 8 <para>
9 Kernel modification involves changing or adding configurations to an existing kernel, 9 Kernel modification involves changing or adding configurations to an existing kernel,
10 adding recipes to the kernel that are needed to support specific hardware features, or even 10 changing or adding recipes to the kernel that are needed to support specific hardware features,
11 changing the source code itself. 11 or even altering the source code itself.
12 This section presents some simple examples that modify the kernel source code, 12 This appendix presents simple examples that modify the kernel source code,
13 change the kernel configuration, and add a kernel source recipe. 13 change the kernel configuration, and add a kernel source recipe.
14<!-- [WRITER'S NOTE: I might want to work in information about applying a local 14<!-- [WRITER'S NOTE: I might want to work in information about applying a local
15 change to a kernel layer and also pushing a change upstream into the tree] 15 change to a kernel layer and also pushing a change upstream into the tree]
@@ -35,24 +35,19 @@
35 console. 35 console.
36 </para> 36 </para>
37 37
38 <para>
39 For a general flow of the example, see
40 <xref linkend='kernel-modification-workflow'>Kernel Modification Workflow</xref>
41 earlier in this manual.
42 </para>
43
44 <section id='understanding-the-files-you-need'> 38 <section id='understanding-the-files-you-need'>
45 <title>Understanding the Files You Need</title> 39 <title>Understanding the Files You Need</title>
46 40
47 <para> 41 <para>
48 Before you modify the kernel you need to know what Git repositories and file 42 Before you modify the kernel, you need to know what Git repositories and file
49 structures you need. 43 structures you need.
50 Briefly, you need the following: 44 Briefly, you need the following:
51 <itemizedlist> 45 <itemizedlist>
52 <listitem><para>A local Yocto Project files Git repository</para></listitem> 46 <listitem><para>A local Yocto Project files Git repository</para></listitem>
53 <listitem><para>The <filename>poky-extras</filename> Git repository placed 47 <listitem><para>The <filename>poky-extras</filename> Git repository placed
54 within the local Yocto Project files Git repository</para></listitem> 48 within the local Yocto Project files Git repository</para></listitem>
55 <listitem><para>A bare clone of the Linux Yocto kernel that you want to modify 49 <listitem><para>A bare clone of the Linux Yocto kernel upstream Git
50 repository that you want to modify
56 </para></listitem> 51 </para></listitem>
57 <listitem><para>A copy of that bare clone in which you make your source 52 <listitem><para>A copy of that bare clone in which you make your source
58 modifcations</para></listitem> 53 modifcations</para></listitem>
@@ -60,7 +55,12 @@
60 </para> 55 </para>
61 56
62 <para> 57 <para>
63 The following illustration summarizes what you need: 58 The following figure summarizes these four areas.
59 Within each rectangular that represents a data structure an URL appears at the
60 lower left-hand corner of the box.
61 These URLs are the locations used in this example.
62 The figure also provides key statements and commands used during the kernel
63 modification process:
64 </para> 64 </para>
65 65
66 <para> 66 <para>
@@ -71,33 +71,52 @@
71 <para> 71 <para>
72 Here is a brief description of the four areas: 72 Here is a brief description of the four areas:
73 <itemizedlist> 73 <itemizedlist>
74 <listitem><para><emphasis>Local Yocto Project Files:</emphasis> This Git 74 <listitem><para><emphasis>Local Yocto Project Files Git Repository:</emphasis>
75 repository contains all the metadata that supports building images in the 75 This area contains all the metadata that supports building images in the
76 Yocto Project build environment. 76 Yocto Project build environment - the local Yocto Project files.
77 Note that the Git repository in our example also contains the
78 <filename>poky-extras</filename> Git repository, which contains the
79 kernel metadata specific to building a kernel image.
80 The Local Yocto Project files Git repository also contains the build directory 77 The Local Yocto Project files Git repository also contains the build directory
81 and configuration files that let you control the build.</para></listitem> 78 and a configuration directory that let you control the build.
82 <listitem><para><emphasis><filename>poky-extras</filename>:</emphasis> This 79 Note also that in this example the repository also contains the
83 Git repository contains the <filename>meta-kernel-dev</filename> layer, 80 <filename>poky-extras</filename> Git repository.</para>
84 which is where you make changes that append to the kernel build recipes. 81 <para>See the bulleted item
85 You edit <filename>.bbappend</filename> files to point the build to your 82 <link linkend='local-yp-release'>Yocto Project Release</link> in
86 local kernel source files and to define the kernel being built. 83 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
84 for information on how to get these files.</para></listitem>
85 <listitem><para><emphasis><filename>poky-extras</filename> Git Repository:</emphasis>
86 This area contains the <filename>meta-kernel-dev</filename> layer,
87 which is where you make changes that append the kernel build recipes.
88 You edit <filename>.bbappend</filename> files to locate your
89 local kernel source files and to identify the kernel being built.
87 This Git repository is a gathering place for extensions to the Linux Yocto 90 This Git repository is a gathering place for extensions to the Linux Yocto
88 (or really any) kernel recipes that faciliate the creation and development 91 (or really any) kernel recipes that faciliate the creation and development
89 of kernel features, BSPs or configuration</para></listitem> 92 of kernel features, BSPs or configurations.</para>
90 <listitem><para><emphasis>Bare Clone of the Linux Yocto Git Repository:</emphasis> 93 <para>See the bulleted item
91 This bare Git repository tracks the upstream Git repository of the Linux Yocto kernel 94 <link linkend='poky-extras-repo'>The
92 you are changing. 95 <filename>poky-extras</filename> Git Repository</link> in
93 As mentioned, when you build the Linux Yocto kernel image you point to this repository 96 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
94 so that the build process can locate the locally changed source files. 97 for information on how to get these files.</para></listitem>
95 When you modify the kernel image you must work with a bare clone. 98 <listitem><para><emphasis>Bare Clone of the Linux Yocto kernel:</emphasis>
99 This bare Git repository tracks the upstream Git repository of the Linux
100 Yocto kernel source code you are changing.
101 When you modify the kernel you must work through a bare clone.
102 All source code changes you make to the kernel must be committed and
103 pushed to the bare clone using Git commands.
104 As mentioned, the <filename>.bbappend</filename> file in the
105 <filename>poky-extras</filename> repository points to the bare clone
106 so that the build process can locate the locally changed source files.</para>
107 <para>See the bulleted item
108 <link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
109 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
110 for information on how to set up the bare clone.
96 </para></listitem> 111 </para></listitem>
97 <listitem><para><emphasis>Copy of the Linux Yocto Kernel Bare Clone:</emphasis> 112 <listitem><para><emphasis>Copy of the Linux Yocto Kernel Bare Clone:</emphasis>
98 This Git repository contains the actual source files that you modify. 113 This Git repository contains the actual source files that you modify.
99 Any changes you make to files in this location need to ultimately be pushed 114 Any changes you make to files in this location need to ultimately be pushed
100 to the bare clone using the <filename>git push</filename> command. 115 to the bare clone using the <filename>git push</filename> command.</para>
116 <para>See the bulleted item
117 <link linkend='local-kernel-files'>Linux Yocto Kernel</link> in
118 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
119 for information on how to set up the bare clone.
101 </para></listitem> 120 </para></listitem>
102 </itemizedlist> 121 </itemizedlist>
103 </para> 122 </para>
@@ -107,8 +126,10 @@
107 <title>Setting Up the Local Yocto Project Files Git Repository</title> 126 <title>Setting Up the Local Yocto Project Files Git Repository</title>
108 127
109 <para> 128 <para>
110 You can get files through tarball extraction or by cloning the <filename>poky</filename> 129 You can get the local Yocto Project files through tarball extraction or by
111 Git repository. 130 cloning the <filename>poky</filename> Git repository.
131 This example uses <filename>poky</filename> as the root directory of the
132 local Yocto Project files Git repository.
112 See the bulleted item 133 See the bulleted item
113 <link linkend='local-yp-release'>Yocto Project Release</link> in 134 <link linkend='local-yp-release'>Yocto Project Release</link> in
114 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual 135 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
@@ -116,7 +137,6 @@
116 </para> 137 </para>
117 138
118 <para> 139 <para>
119 This example assumes the name of the Git repository is <filename>poky</filename>.
120 Once you have the repository set up, 140 Once you have the repository set up,
121 you have many development branches from which you can work. 141 you have many development branches from which you can work.
122 From inside the repository you can see the branch names and the tag names used 142 From inside the repository you can see the branch names and the tag names used
@@ -126,10 +146,10 @@
126 $ git branch -a 146 $ git branch -a
127 $ git tag -l 147 $ git tag -l
128 </literallayout> 148 </literallayout>
129 For this example, we are going to use the Yocto Project 1.1_M3 Release, 149 This example uses the Yocto Project 1.1_M3 Release,
130 which maps to the <filename>1.1_M3</filename> branch in the repository. 150 which maps to the <filename>1.1_M3</filename> branch in the repository.
131 These commands create a local branch named <filename>1.1_M3</filename> 151 The following commands create and checkout the local <filename>1.1_M3</filename>
132 that tracks the remote branch of the same name. 152 branch:
133 <literallayout class='monospaced'> 153 <literallayout class='monospaced'>
134 $ git checkout -b 1.1_M3 origin/1.1_M3 154 $ git checkout -b 1.1_M3 origin/1.1_M3
135 Branch 1.1_M3 set up to track remote branch 1.1_M3 from origin. 155 Branch 1.1_M3 set up to track remote branch 1.1_M3 from origin.
@@ -148,7 +168,7 @@
148 <link linkend='poky-extras-repo'>The 168 <link linkend='poky-extras-repo'>The
149 <filename>poky-extras</filename> Git Repository</link> in 169 <filename>poky-extras</filename> Git Repository</link> in
150 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual 170 <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
151 for information on how to get these files. 171 for information on how to get the <filename>poky-extras</filename> repository.
152 </para> 172 </para>
153 </section> 173 </section>
154 174
@@ -166,10 +186,12 @@
166 </para> 186 </para>
167 187
168 <para> 188 <para>
169 The bare clone exists simply as the receiving end of <filename>git push</filename> 189 The bare clone exists for the kernel build tools and simply as the receiving end
190 of <filename>git push</filename>
170 commands after you make edits and commits inside the copy of the clone. 191 commands after you make edits and commits inside the copy of the clone.
171 The copy (<filename>linux-yocto-2.6.37</filename> in this example) has to have 192 The copy (<filename>linux-yocto-2.6.37</filename> in this example) has to have
172 a local branch created and checked out for your work. 193 a local branch created and checked out for your work.
194 This example uses <filename>common-pc-base</filename> as the local branch.
173 The following commands create and checkout the branch: 195 The following commands create and checkout the branch:
174 <literallayout class='monospaced'> 196 <literallayout class='monospaced'>
175 $ cd ~/linux-yocto-2.6.37 197 $ cd ~/linux-yocto-2.6.37
@@ -184,8 +206,8 @@
184 <title>Building and Booting the Default QEMU Kernel Image</title> 206 <title>Building and Booting the Default QEMU Kernel Image</title>
185 207
186 <para> 208 <para>
187 In this example before we make changes to the kernel image we will build it first 209 Before we make changes to the kernel source files, this example first builds the
188 and see how it boots inside the QEMU emulator. 210 default image and then boots it inside the QEMU emulator.
189 <note> 211 <note>
190 Because a full build can take hours, you should check two variables in the 212 Because a full build can take hours, you should check two variables in the
191 <filename>build</filename> directory that is created after you source the 213 <filename>build</filename> directory that is created after you source the
@@ -195,14 +217,14 @@
195 in the <filename>build/conf</filename> directory in the 217 in the <filename>build/conf</filename> directory in the
196 <filename>local.conf</filename> configuration file. 218 <filename>local.conf</filename> configuration file.
197 By default, these variables are commented out. 219 By default, these variables are commented out.
198 If your host development system supports multi-core and multi-thread capabilities 220 If your host development system supports multi-core and multi-thread capabilities,
199 you can uncomment these statements and set the variables to significantly shorten 221 you can uncomment these statements and set the variables to significantly shorten
200 the full build time. 222 the full build time.
201 As a guideline, set <filename>BB_NUMBER_THREADS</filename> to twice the number 223 As a guideline, set <filename>BB_NUMBER_THREADS</filename> to twice the number
202 of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and 224 of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and
203 a half times the number of cores your machine supports. 225 a half times the number of cores your machine supports.
204 </note> 226 </note>
205 These commands build the default <filename>qemux86</filename> image: 227 The following commands build the default <filename>qemux86</filename> image:
206 <literallayout class='monospaced'> 228 <literallayout class='monospaced'>
207 $ cd ~/poky 229 $ cd ~/poky
208 $ source oe-init-build-env 230 $ source oe-init-build-env
@@ -226,8 +248,11 @@
226 </para> 248 </para>
227 249
228 <para> 250 <para>
229 The <filename>source</filename> command sets up the build environment, while the 251 The <filename>source</filename> command sets up the build environment and,
230 following <filename>bitbake</filename> command starts the build. 252 if necessary, creates the build directory.
253 The following <filename>bitbake</filename> command starts the build.
254 <note>Be sure to check the settings in the <filename>local.conf</filename>
255 before starting the build.</note>
231 </para> 256 </para>
232 257
233 <para> 258 <para>
@@ -239,12 +264,12 @@
239 </para> 264 </para>
240 265
241 <para> 266 <para>
242 As the image boots in the emulator, console messages and status appear across the 267 As the image boots in the emulator, console message and status output appears
243 terminal window. 268 across the terminal window.
244 Because the output scrolls by quickly it is difficult to read. 269 Because the output scrolls by quickly, it is difficult to read.
245 To examine the output you can log into the system using the 270 To examine the output, you log into the system using the
246 login <filename>root</filename> with no password. 271 login <filename>root</filename> with no password.
247 Once you are logged in, you can issue the following command to scroll through the 272 Once you are logged in, issue the following command to scroll through the
248 console output: 273 console output:
249 <literallayout class='monospaced'> 274 <literallayout class='monospaced'>
250 # dmesg | less 275 # dmesg | less
@@ -263,10 +288,12 @@
263 <para> 288 <para>
264 The file you change in this example is named <filename>calibrate.c</filename> 289 The file you change in this example is named <filename>calibrate.c</filename>
265 and is located in the <filename>linux-yocto-2.6.37</filename> Git repository 290 and is located in the <filename>linux-yocto-2.6.37</filename> Git repository
266 in <filename>init</filename>. 291 (the copy of the bare clone) in <filename>init</filename>.
267 For this example simply insert several <filename>printk</filename> statements 292 This example simply inserts several <filename>printk</filename> statements
268 at the beginning of the <filename>calibrate_delay</filename> function. 293 at the beginning of the <filename>calibrate_delay</filename> function.
269 Now let's look at the changes to the source code. 294 </para>
295
296 <para>
270 Here is the unaltered code at the start of this function: 297 Here is the unaltered code at the start of this function:
271 <literallayout class='monospaced'> 298 <literallayout class='monospaced'>
272 void __cpuinit calibrate_delay(void) 299 void __cpuinit calibrate_delay(void)
@@ -283,8 +310,8 @@
283 </para> 310 </para>
284 311
285 <para> 312 <para>
286 This example uses the following five <filename>printk</filename> statements 313 Here is the altered code showing five new <filename>printk</filename> statements
287 just after defining <filename>lps_precision</filename>: 314 just after initializing <filename>lps_precision</filename>:
288 <literallayout class='monospaced'> 315 <literallayout class='monospaced'>
289 void __cpuinit calibrate_delay(void) 316 void __cpuinit calibrate_delay(void)
290 { 317 {
@@ -306,7 +333,7 @@
306 333
307 <para> 334 <para>
308 After making and saving your changes, you need to stage them for the push. 335 After making and saving your changes, you need to stage them for the push.
309 The following Git commands stage and commit your changes: 336 The following Git commands are one method of staging and committing your changes:
310 <literallayout class='monospaced'> 337 <literallayout class='monospaced'>
311 $ git add calibrate.c 338 $ git add calibrate.c
312 $ git commit --signoff 339 $ git commit --signoff
@@ -314,32 +341,27 @@
314 </para> 341 </para>
315 342
316 <para> 343 <para>
317 Once the source code has been modified you need to use Git to push the changes to 344 Once the source code has been modified, you need to use Git to push the changes to
318 the bare clone. 345 the bare clone.
319 If you do not push the changes then the Yocto Project build system will not pick 346 If you do not push the changes, then the Yocto Project build system will not pick
320 the changed source files. 347 up the changed source files.
321 </para> 348 </para>
322 349
323 <para> 350 <para>
324 To push the changes do the following: 351 The following command pushes the changes to the bare clone:
325 <literallayout class='monospaced'> 352 <literallayout class='monospaced'>
326 $ git push origin common-pc-base:yocto/standard/common-pc/base 353 $ git push origin common-pc-base:yocto/standard/common-pc/base
327 </literallayout> 354 </literallayout>
328 </para> 355 </para>
329
330 <para>
331 For general information on how to push a change using Git, see [WRITER'S NOTE: need
332 the link to the submitting a change section].
333 </para>
334 </section> 356 </section>
335 357
336 <section id='changing-build-parameters-for-your-build'> 358 <section id='changing-build-parameters-for-your-build'>
337 <title>Changing Build Parameters for Your Build</title> 359 <title>Changing Build Parameters for Your Build</title>
338 360
339 <para> 361 <para>
340 At this point the source has been changed and pushed. 362 At this point, the source has been changed and pushed.
341 Now you need to define some variables used by the Yocto Project build system to locate your 363 The example now defines some variables used by the Yocto Project build system
342 source. 364 to locate your kernel source.
343 You essentially need to identify where to find the kernel recipe and the changed source code. 365 You essentially need to identify where to find the kernel recipe and the changed source code.
344 You also need to be sure some basic configurations are in place that identify the 366 You also need to be sure some basic configurations are in place that identify the
345 type of machine you are building and to help speed up the build should your host support 367 type of machine you are building and to help speed up the build should your host support
@@ -348,18 +370,17 @@
348 370
349 <para> 371 <para>
350 Do the following to make sure the build parameters are set up for the example. 372 Do the following to make sure the build parameters are set up for the example.
351 Once you set up these build parameters they should not have to change unless you 373 Once you set up these build parameters, they do not have to change unless you
352 change the target architecture of the machine you are building or you move 374 change the target architecture of the machine you are building or you move
353 the bare clone, copy of the clone, or the <filename>poky-extras</filename> repository: 375 the bare clone, copy of the clone, or the <filename>poky-extras</filename> repository:
354 <itemizedlist> 376 <itemizedlist>
355 <listitem><para><emphasis>Build for the Correct Target Architecture</emphasis> - The 377 <listitem><para><emphasis>Build for the Correct Target Architecture</emphasis> - The
356 <filename>local.conf</filename> in the build directory defines the build's 378 <filename>local.conf</filename> file in the build directory defines the build's
357 target architecture. 379 target architecture.
358 By default, 380 By default, <filename>MACHINE</filename> is set to
359 <filename>MACHINE</filename> is set to <filename>qemux86</filename>, which 381 <filename>qemux86</filename>, which specifies a 32-bit Intel Architecture
360 specifies a 32-bit Intel Architecture target machine suitable for the 382 target machine suitable for the QEMU emulator.
361 QEMU emulator. 383 In this example, <filename>MACHINE</filename> is correctly configured.
362 So for this example, <filename>MACHINE</filename> is correctly configured.
363 </para></listitem> 384 </para></listitem>
364 <listitem><para><emphasis>Optimize Build Time</emphasis> - Also in the 385 <listitem><para><emphasis>Optimize Build Time</emphasis> - Also in the
365 <filename>local.conf</filename> file are two variables that can speed your 386 <filename>local.conf</filename> file are two variables that can speed your
@@ -371,13 +392,14 @@
371 number of cores.</para></listitem> 392 number of cores.</para></listitem>
372 <listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename> 393 <listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename>
373 Layer</emphasis> - The <filename>BBLAYERS</filename> variable in the 394 Layer</emphasis> - The <filename>BBLAYERS</filename> variable in the
374 <filename>bblayers.conf</filename> found in the 395 <filename>bblayers.conf</filename> file found in the
375 <filename>poky/build/conf</filename> directory needs to have the path to your local 396 <filename>poky/build/conf</filename> directory needs to have the path to your local
376 <filename>meta-kernel-dev</filename> layer. 397 <filename>meta-kernel-dev</filename> layer.
377 By default, the <filename>BBLAYERS</filename> variable contains paths to 398 By default, the <filename>BBLAYERS</filename> variable contains paths to
378 <filename>meta</filename> and <filename>meta-yocto</filename> in the 399 <filename>meta</filename> and <filename>meta-yocto</filename> in the
379 <filename>poky</filename> Git repository. 400 <filename>poky</filename> Git repository.
380 Add the path to your <filename>meta-kernel-dev</filename> location. 401 Add the path to your <filename>meta-kernel-dev</filename> location.
402 Be sure to substitute your user information in the statement.
381 Here is an example: 403 Here is an example:
382 <literallayout class='monospaced'> 404 <literallayout class='monospaced'>
383 BBLAYERS = " \ 405 BBLAYERS = " \
@@ -389,17 +411,18 @@
389 <listitem><para><emphasis>Identify Your Source Files</emphasis> - In the 411 <listitem><para><emphasis>Identify Your Source Files</emphasis> - In the
390 <filename>linux-yocto_2.6.37.bbappend</filename> file located in the 412 <filename>linux-yocto_2.6.37.bbappend</filename> file located in the
391 <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename> 413 <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
392 directory you need to identify the location of the 414 directory, you need to identify the location of the
393 local source code, which in this example is the bare clone named 415 local source code, which in this example is the bare clone named
394 <filename>linux-yocto-2.6.37.git</filename>. 416 <filename>linux-yocto-2.6.37.git</filename>.
395 To do this, set the <filename>KSRC_linux_yocto</filename> to point to your 417 To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
396 local <filename>linux-yocto-2.6.37.git</filename> Git repository by adding the 418 local <filename>linux-yocto-2.6.37.git</filename> Git repository by adding the
397 following statement: 419 following statement.
420 Be sure to substitute your user information in the statement:
398 <literallayout class='monospaced'> 421 <literallayout class='monospaced'>
399 KSRC_linux_yocto ?= /home/scottrif/linux-yocto-2.6.37.git 422 KSRC_linux_yocto ?= /home/scottrif/linux-yocto-2.6.37.git
400 </literallayout></para></listitem> 423 </literallayout></para></listitem>
401 <listitem><para><emphasis>Specify the Kernel Machine</emphasis> - Also in the 424 <listitem><para><emphasis>Specify the Kernel Machine</emphasis> - Also in the
402 <filename>linux-yocto_2.6.37.bbappend</filename> you need to specify 425 <filename>linux-yocto_2.6.37.bbappend</filename> file, you need to specify
403 the kernel machine with the following statement: 426 the kernel machine with the following statement:
404 <literallayout class='monospaced'> 427 <literallayout class='monospaced'>
405 KMACHINE_qemux86 = "yocto/standard/common-pc/base" 428 KMACHINE_qemux86 = "yocto/standard/common-pc/base"
@@ -408,14 +431,14 @@
408 </para> 431 </para>
409 432
410 <note> 433 <note>
411 Before attempting to build the modified kernel there is one more set of changes you 434 Before attempting to build the modified kernel, there is one more set of changes you
412 need to make in the <filename>meta-kernel-dev</filename> layer. 435 need to make in the <filename>meta-kernel-dev</filename> layer.
413 Because all the kernel <filename>.bbappend</filename> files are parsed during the 436 Because all the kernel <filename>.bbappend</filename> files are parsed during the
414 build process regardless of whether you are using them or not, you should either 437 build process regardless of whether you are using them or not, you should either
415 comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all 438 comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all
416 <filename>.bbappend</filename> files, or you should simply remove all the files 439 <filename>.bbappend</filename> files, or you should simply remove all the files
417 except the one your are using for the build (i.e. <filename>linux-yocto_2.6.37.bbappend</filename> 440 except the one your are using for the build
418 in this example). 441 (i.e. <filename>linux-yocto_2.6.37.bbappend</filename> in this example).
419 </note> 442 </note>
420 </section> 443 </section>
421 444
@@ -428,13 +451,17 @@
428 <orderedlist> 451 <orderedlist>
429 <listitem><para>Your environment should be set up since you previously sourced 452 <listitem><para>Your environment should be set up since you previously sourced
430 the <filename>oe-init-build-env</filename> script. 453 the <filename>oe-init-build-env</filename> script.
431 If it isn't, source the script again from the <filename>poky</filename> 454 If it isn't, source the script again from <filename>poky</filename>
432 again.</para></listitem> 455 </para></listitem>
433 <listitem><para>Be sure any old images are cleaned out by running the 456 <listitem><para>Be sure old images are cleaned out by running the
434 <filename>cleanall</filename> BitBake task as follows: 457 <filename>cleanall</filename> BitBake task as follows:
435 <literallayout class='monospaced'> 458 <literallayout class='monospaced'>
436 $ bitbake -c cleanall linux-yocto 459 $ bitbake -c cleanall linux-yocto
437 </literallayout></para></listitem> 460 </literallayout></para>
461 <para><note>Never remove by hand any files from the <filename>tmp/deploy</filename>
462 directory insided the local Yocto Project files build directory.
463 Always use the BitBake <filename>cleanall</filename> task to clear
464 out previous builds.</note></para></listitem>
438 <listitem><para>Build the kernel image using this command: 465 <listitem><para>Build the kernel image using this command:
439 <literallayout class='monospaced'> 466 <literallayout class='monospaced'>
440 $ bitbake -k core-image-minimal 467 $ bitbake -k core-image-minimal
@@ -443,7 +470,7 @@
443 </para> 470 </para>
444 471
445 <para> 472 <para>
446 Next, boot the modified image in the QEMU emulator using this command: 473 Finally, boot the modified image in the QEMU emulator using this command:
447 <literallayout class='monospaced'> 474 <literallayout class='monospaced'>
448 $ runqemu qemux86 475 $ runqemu qemux86
449 </literallayout> 476 </literallayout>