From cb9150394dd430f5829a89bceb3bf5cc7a90dc13 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 3 Oct 2017 12:36:57 -0700 Subject: kernel-dev: Edits to "Build Strategy" section. This section was written before the yocto-kernel-cache strategy existed and was thus incorrect. I updated it with how I understand things to work. (From yocto-docs rev: 629f24c9312a168ddcd28b0d9dde92ff06068483) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/kernel-dev/kernel-dev-maint-appx.xml | 101 +++++++++++++-------- 1 file changed, 63 insertions(+), 38 deletions(-) (limited to 'documentation') diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.xml b/documentation/kernel-dev/kernel-dev-maint-appx.xml index 4575c90df9..79e6e26e00 100644 --- a/documentation/kernel-dev/kernel-dev-maint-appx.xml +++ b/documentation/kernel-dev/kernel-dev-maint-appx.xml @@ -56,7 +56,7 @@ Once you have cloned the kernel Git repository and the cache of Metadata on your local machine, you can discover the - branches that are avilable in the repository using the following + branches that are available in the repository using the following Git command: $ git branch -a @@ -188,7 +188,7 @@ Clone Base Repository: The base repository is cloned, and the actions listed in the yocto-kernel-cache - irectories are applied to the tree. + directories are applied to the tree. Perform Cleanup: @@ -228,74 +228,99 @@ Build Strategy - Once a local Git repository of the Yocto Project kernel exists on a development system, - you can consider the compilation phase of kernel development - building a kernel image. - Some prerequisites exist that are validated by the build process before compilation - starts: + Once you have cloned a Yocto Linux kernel repository and the + cache repository (yocto-kernel-cache) onto + your development system, you can consider the compilation phase + of kernel development, which is building a kernel image. + Some prerequisites exist that are validated by the build process + before compilation starts: - The - SRC_URI points - to the kernel Git repository. - A BSP build branch exists. - This branch has the following form: + + The + SRC_URI + points to the kernel Git repository. + + + A BSP build branch with Metadata exists in the + yocto-kernel-cache repository. + The branch is based on the Yocto Linux kernel version and + has configurations and features grouped under the + yocto-kernel-cache/bsp directory. + For example, features and configurations for the + BeagleBone Board assuming a + linux-yocto_4.12 kernel reside in the + following area of the yocto-kernel-cache + repository: - kernel_type/bsp_name - + yocto-kernel-cache/bsp/beaglebone + + + In the previous example, the "yocto-4.12" branch is + checked out in the yocto-kernel-cache + repository. + + - The OpenEmbedded build system makes sure these conditions exist before attempting compilation. + The OpenEmbedded build system makes sure these conditions exist + before attempting compilation. Other means, however, do exist, such as as bootstrapping a BSP. Before building a kernel, the build process verifies the tree and configures the kernel by processing all of the - configuration "fragments" specified by feature descriptions in the .scc - files. - As the features are compiled, associated kernel configuration fragments are noted - and recorded in the meta-* series of directories in their compilation order. - The fragments are migrated, pre-processed and passed to the Linux Kernel - Configuration subsystem (lkc) as raw input in the form - of a .config file. - The lkc uses its own internal dependency constraints to do the final - processing of that information and generates the final .config file - that is used during compilation. + configuration "fragments" specified by feature descriptions + in the .scc files. + As the features are compiled, associated kernel configuration + fragments are noted and recorded in the series of directories + in their compilation order. + The fragments are migrated, pre-processed and passed to the + Linux Kernel Configuration subsystem (lkc) as + raw input in the form of a .config file. + The lkc uses its own internal dependency + constraints to do the final processing of that information and + generates the final .config file that is used + during compilation. - Using the board's architecture and other relevant values from the board's template, - kernel compilation is started and a kernel image is produced. + Using the board's architecture and other relevant values from + the board's template, kernel compilation is started and a kernel + image is produced. The other thing that you notice once you configure a kernel is that - the build process generates a build tree that is separate from your kernel's local Git - source repository tree. + the build process generates a build tree that is separate from + your kernel's local Git source repository tree. This build tree has a name that uses the following form, where - ${MACHINE} is the metadata name of the machine (BSP) and "kernel_type" is one - of the Yocto Project supported kernel types (e.g. "standard"): + ${MACHINE} is the metadata name of the + machine (BSP) and "kernel_type" is one of the Yocto Project + supported kernel types (e.g. "standard"): linux-${MACHINE}-kernel_type-build - The existing support in the kernel.org tree achieves this - default functionality. + The existing support in the kernel.org tree + achieves this default functionality. - This behavior means that all the generated files for a particular machine or BSP are now in - the build tree directory. - The files include the final .config file, all the .o - files, the .a files, and so forth. + This behavior means that all the generated files for a particular + machine or BSP are now in the build tree directory. + The files include the final .config file, + all the .o files, the .a + files, and so forth. Since each machine or BSP has its own separate Build Directory - in its own separate branch - of the Git repository, you can easily switch between different builds. + in its own separate branch of the Git repository, you can easily + switch between different builds. -- cgit v1.2.3-54-g00ecf