diff options
Diffstat (limited to 'documentation/kernel-dev')
-rw-r--r-- | documentation/kernel-dev/kernel-dev-common.xml | 139 |
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'> | ||
222 | If you do not have existing patches or configuration files, you can easily | ||
223 | generate them from within the bitbake build environment, as will be described | ||
224 | below. As you do, running previously completed bitbake tasks will cause bitbake | ||
225 | to invalidate the tasks that follow them in the build sequence, causing them to | ||
226 | rebuild at the next invocation of the build. Throughout this section, be sure to | ||
227 | substitute "linux-yocto" with the name of the Linux kernel recipe you are | ||
228 | working 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 |
357 | You 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 | |||
362 | This will start the Linux kernel configuration tool, allowing you to prepare a | ||
363 | new .config for the build. When you exit, be sure to save the changes when | ||
364 | prompted. The resulting .config file will be located in the ${WORKDIR} under | ||
365 | the linux-${MACHINE}-${KTYPE}-build directory. You can use this in its entirety | ||
366 | as the defconfig file described in 2.2.2. | ||
367 | |||
368 | Better still, would be to use the "menuconfig" command and take the difference | ||
369 | of the new .config file with the previous one to generate a configuration | ||
370 | fragment. To do this, be sure to complete a build at least through the kernel | ||
371 | configuration task: | ||
372 | |||
373 | $ bitbake linux-yocto -c kernel_configme -f | ||
374 | |||
375 | Then make a copy of the .config file, calling it "config.orig", for example. Run | ||
376 | the "menuconfig" command as described above. Finally, prepare a configuration | ||
377 | fragment from the difference between the files. Ultimately you want a list of | ||
378 | Linux kernel CONFIG_ assignments, and not something in diff format. Something | ||
379 | like the following will do that automatically (but plan on reviewing the output | ||
380 | as you can usually remove some of the defaults): | ||
381 | |||
382 | $ diff -Nurp config.orig .config | sed -n "s/^\+//p" > frag.cfg | ||
383 | |||
384 | You can use the output as a configuration fragment described in 2.2.2. This | ||
385 | method can also be used to define a BSP configuration fragment (See 3.3.5). | ||
386 | |||
387 | The Yocto Project kernel tools provide some configuration validation tools which | ||
388 | will warn when a configuration you requested does not appear in the final | ||
389 | config, or when you override a policy configuration in a hardware configuration | ||
390 | fragment. 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 | |||
412 | The various problems that you can encounter are described in the output along | ||
413 | with where to find the offending configuration items. You can use these logs to | ||
414 | adjust 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'> | ||
502 | You can experiment with source code changes and create a simple patch without | ||
503 | leaving the bitbake environment. To get started, be sure to complete a build at | ||
504 | least through the kernel configuration task: | ||
505 | |||
506 | $ bitbake linux-yocto -c kernel_configme -f | ||
507 | |||
508 | This step will ensure you have the sources prepared and the configuration | ||
509 | completed. You will find the sources in the ${WORKDIR}/linux directory. | ||
510 | |||
511 | You can edit the sources as you would any other Linux source tree, but keep in | ||
512 | mind that your changes will be lost if you trigger the fetch task for the | ||
513 | recipe. Avoid this by not issuing the "cleanall" or "cleansstate", or forcing | ||
514 | the "fetch" command. Also be sure not to modify the recipe itself while working | ||
515 | with temporary changes or bitbake may run the fetch command (depending on the | ||
516 | changes to the recipe). | ||
517 | |||
518 | To 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 | ||
520 | already done so: | ||
521 | |||
522 | $ bitbake linux-yocto -c compile -f | ||
523 | |||
524 | If the compile fails, you can update the sources and repeat the compile | ||
525 | command. Once it compiles successfully, you can inspect and test the resulting | ||
526 | build (kernel, modules, etc.) from the build directory at | ||
527 | ${WORKDIR}/linux-${MACHINE}-${KTYPE}-build. Alternatively, you can run the | ||
528 | deploy command to place the kernel image in the tmp/deploy/images directory: | ||
529 | |||
530 | $ bitbake linux-yocto -c deploy | ||
531 | |||
532 | And of course, you can run through all the remaining installation and packaging | ||
533 | steps by issuing: | ||
534 | |||
535 | $ bitbake linux-yocto | ||
536 | |||
537 | For rapid iterative development, the edit-compile-repeat loop is preferable to | ||
538 | rebuilding the entire recipe as the installation and packaging tasks are very | ||
539 | time consuming. | ||
540 | |||
541 | Once you are happy with your modifications, you can make these permanent by | ||
542 | generating patches and applying them to the SRC_URI as described in section | ||
543 | 2.2.1 Applying Patches. If you are not familiar with generating patches, refer | ||
544 | to 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 | ||