summaryrefslogtreecommitdiffstats
path: root/documentation/kernel-dev
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/kernel-dev')
-rw-r--r--documentation/kernel-dev/kernel-dev-common.xml139
1 files changed, 10 insertions, 129 deletions
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
index 33b834729e..1b19c08524 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -197,8 +197,8 @@
197 </section> 197 </section>
198 </section> 198 </section>
199 199
200 <section id='iterative-development'> 200 <section id='using-an-iterative-development-process'>
201 <title>Iterative Development</title> 201 <title>Using an Iterative Development Process</title>
202 202
203 <para> 203 <para>
204 If you do not have existing patches or configuration files, 204 If you do not have existing patches or configuration files,
@@ -212,21 +212,9 @@
212 </para> 212 </para>
213 213
214 <para> 214 <para>
215 As you read this section, be sure to substitute "linux-yocto" with 215 As you read this section, be sure to substitute the name
216 the name of the Linux kernel recipe with which you are working. 216 of your Linux kernel recipe for the term
217 </para> 217 "linux-yocto".
218
219 <para>
220 Original Text:
221 <literallayout class='monospaced'>
222If you do not have existing patches or configuration files, you can easily
223generate them from within the bitbake build environment, as will be described
224below. As you do, running previously completed bitbake tasks will cause bitbake
225to invalidate the tasks that follow them in the build sequence, causing them to
226rebuild at the next invocation of the build. Throughout this section, be sure to
227substitute "linux-yocto" with the name of the Linux kernel recipe you are
228working with.
229 </literallayout>
230 </para> 218 </para>
231 219
232 <section id='generating-configuration-files'> 220 <section id='generating-configuration-files'>
@@ -272,7 +260,7 @@ working with.
272 <literallayout class='monospaced'> 260 <literallayout class='monospaced'>
273 $ bitbake linux-yocto -c kernel_configme -f 261 $ bitbake linux-yocto -c kernel_configme -f
274 </literallayout></para></listitem> 262 </literallayout></para></listitem>
275 <listitem><para>Create a renamed copy of the resulting 263 <listitem><para>Copy and rename the resulting
276 <filename>.config</filename> file (e.g. 264 <filename>.config</filename> file (e.g.
277 <filename>config.orig</filename>). 265 <filename>config.orig</filename>).
278 </para></listitem> 266 </para></listitem>
@@ -352,68 +340,10 @@ working with.
352 </para> 340 </para>
353 341
354 <para> 342 <para>
355 Original Text: 343 For more information on how to use the
356 <literallayout class='monospaced'> 344 <filename>menuconfig</filename> tool, see the
357You can manipulate the config used to build a linux-yocto recipe with the 345 "<ulink url='&YOCTO_DOCS_DEV_URL;#using-menuconfig'>Using <filename>menuconfig</filename></ulink>"
358"menuconfig" command. 346 section in the Yocto Project Development Manual.
359
360 $ bitbake linux-yocto -c menuconfig
361
362This will start the Linux kernel configuration tool, allowing you to prepare a
363new .config for the build. When you exit, be sure to save the changes when
364prompted. The resulting .config file will be located in the ${WORKDIR} under
365the linux-${MACHINE}-${KTYPE}-build directory. You can use this in its entirety
366as the defconfig file described in 2.2.2.
367
368Better still, would be to use the "menuconfig" command and take the difference
369of the new .config file with the previous one to generate a configuration
370fragment. To do this, be sure to complete a build at least through the kernel
371configuration task:
372
373 $ bitbake linux-yocto -c kernel_configme -f
374
375Then make a copy of the .config file, calling it "config.orig", for example. Run
376the "menuconfig" command as described above. Finally, prepare a configuration
377fragment from the difference between the files. Ultimately you want a list of
378Linux kernel CONFIG_ assignments, and not something in diff format. Something
379like the following will do that automatically (but plan on reviewing the output
380as you can usually remove some of the defaults):
381
382 $ diff -Nurp config.orig .config | sed -n "s/^\+//p" > frag.cfg
383
384You can use the output as a configuration fragment described in 2.2.2. This
385method can also be used to define a BSP configuration fragment (See 3.3.5).
386
387The Yocto Project kernel tools provide some configuration validation tools which
388will warn when a configuration you requested does not appear in the final
389config, or when you override a policy configuration in a hardware configuration
390fragment. You can run these tools with the following command:
391
392 $ bitbake linux-yocto -c kernel_configcheck -f
393
394 ...
395
396 NOTE: validating kernel configuration
397 This BSP sets 3 invalid/obsolete kernel options.
398 These config options are not offered anywhere within this kernel.
399 The full list can be found in your kernel src dir at:
400 meta/cfg/standard/mybsp/invalid.cfg
401
402 This BSP sets 21 kernel options that are possibly non-hardware related.
403 The full list can be found in your kernel src dir at:
404 meta/cfg/standard/mybsp/specified_non_hdw.cfg
405
406 WARNING: There were 2 hardware options requested that do not
407 have a corresponding value present in the final ".config" file.
408 This probably means you aren't getting the config you wanted.
409 The full list can be found in your kernel src dir at:
410 meta/cfg/standard/mybsp/mismatch.cfg
411
412The various problems that you can encounter are described in the output along
413with where to find the offending configuration items. You can use these logs to
414adjust your configuration files and repeat the "kernel_configme" and
415"kernel_configcheck" commands until no warnings are produced.
416 </literallayout>
417 </para> 347 </para>
418 </section> 348 </section>
419 349
@@ -495,55 +425,6 @@ adjust your configuration files and repeat the "kernel_configme" and
495 "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-the-patch'>Creating the Patch</ulink>" 425 "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-the-patch'>Creating the Patch</ulink>"
496 section in the Yocto Project Development Manual. 426 section in the Yocto Project Development Manual.
497 </para> 427 </para>
498
499 <para>
500 Original Text:
501 <literallayout class='monospaced'>
502You can experiment with source code changes and create a simple patch without
503leaving the bitbake environment. To get started, be sure to complete a build at
504least through the kernel configuration task:
505
506 $ bitbake linux-yocto -c kernel_configme -f
507
508This step will ensure you have the sources prepared and the configuration
509completed. You will find the sources in the ${WORKDIR}/linux directory.
510
511You can edit the sources as you would any other Linux source tree, but keep in
512mind that your changes will be lost if you trigger the fetch task for the
513recipe. Avoid this by not issuing the "cleanall" or "cleansstate", or forcing
514the "fetch" command. Also be sure not to modify the recipe itself while working
515with temporary changes or bitbake may run the fetch command (depending on the
516changes to the recipe).
517
518To test your temporary changes, instruct bitbake to run the compile again. The
519-f option forces the command to run again even though bitbake may think it has
520already done so:
521
522 $ bitbake linux-yocto -c compile -f
523
524If the compile fails, you can update the sources and repeat the compile
525command. Once it compiles successfully, you can inspect and test the resulting
526build (kernel, modules, etc.) from the build directory at
527${WORKDIR}/linux-${MACHINE}-${KTYPE}-build. Alternatively, you can run the
528deploy command to place the kernel image in the tmp/deploy/images directory:
529
530 $ bitbake linux-yocto -c deploy
531
532And of course, you can run through all the remaining installation and packaging
533steps by issuing:
534
535 $ bitbake linux-yocto
536
537For rapid iterative development, the edit-compile-repeat loop is preferable to
538rebuilding the entire recipe as the installation and packaging tasks are very
539time consuming.
540
541Once you are happy with your modifications, you can make these permanent by
542generating patches and applying them to the SRC_URI as described in section
5432.2.1 Applying Patches. If you are not familiar with generating patches, refer
544to the Yocto Project Development Manual, section 5.7.3 Creating the Patch.
545 </literallayout>
546 </para>
547 </section> 428 </section>
548 </section> 429 </section>
549 430