From 0082a64386372bf25b72ed2e18ef6c3e1e756c42 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 17 Jul 2012 09:13:57 -0700 Subject: documentation/bsp-guide/bsp.xml: Updates to Kernel configuration section final changes to the section that talks about configuring the kernel. Changes here based off Bruce Ashfield's review comments. (From yocto-docs rev: 7715643f2a24336585dd44d1d75e7be0aade7f6b) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/bsp-guide/bsp.xml | 102 +++++++++++++++++++++------------------- 1 file changed, 54 insertions(+), 48 deletions(-) (limited to 'documentation/bsp-guide') diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index 8223954f04..0159f48848 100644 --- a/documentation/bsp-guide/bsp.xml +++ b/documentation/bsp-guide/bsp.xml @@ -505,10 +505,10 @@ - These files append your specific changes to the kernel you are using. + These files append your specific changes to the main kernel recipe you are using. - For your BSP, you typically want to use an existing Yocto Project kernel found in the + For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the source directory at meta/recipes-kernel/linux. You can append your specific changes to the kernel recipe by using a @@ -516,22 +516,22 @@ the meta-<bsp_name>/recipes-kernel/linux directory). - Suppose you are using the linux-yocto_3.2.bb recipe to build + Suppose you are using the linux-yocto_3.4.bb recipe to build the kernel. In other words, you have selected the kernel in your <bsp_name>.conf file by adding the following statements: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" - PREFERRED_VERSION_linux-yocto = "3.2%" + PREFERRED_VERSION_linux-yocto = "3.4%" - You would use the linux-yocto_3.2.bbappend file to append + You would use the linux-yocto_3.4.bbappend file to append specific BSP settings to the kernel, thus configuring the kernel for your particular BSP. As an example, look at the existing Crown Bay BSP. The append file used is: - meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend + meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend The following listing shows the file. Be aware that the actual commit ID strings in this example listing might be different @@ -558,7 +558,7 @@ Intel EMGD and the VESA graphics. The build process, in this case, recognizes and uses only the statements that apply to the defined machine name - crownbay in this case. - So, the applicable statements in the linux-yocto_3.2.bbappend + So, the applicable statements in the linux-yocto_3.4.bbappend file are follows: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" @@ -570,41 +570,42 @@ SRCREV_machine_pn-linux-yocto_crownbay ?= "48101e609711fcfe8d5e737a37a5a69f4bd57d9a" SRCREV_meta_pn-linux-yocto_crownbay ?= "5b4c9dc78b5ae607173cc3ddab9bce1b5f78129b" - The append file defines crownbay as the compatible machine and - defines the KMACHINE. - The file also points to some configuration fragments to use by setting the - KERNEL_FEATURES variable. - The location for the configuration fragments is the kernel tree itself in the - build directory - under linux/meta. - Finally, the append file points to the specific commits in the + The append file defines crownbay as the + COMPATIBLE_MACHINE + and defines the KMACHINE. + The file also uses the optional + KBRANCH variable + to ensure the build process uses the standard/default/crownbay + kernel branch. + Finally, the append file points to the specific top commits in the source directory Git repository and the meta Git repository branches to identify the exact kernel needed to build the Crown Bay BSP. + One thing missing in this particular BSP, which you will typically need when developing a BSP, is the kernel configuration file (.config) for your BSP. When developing a BSP, you probably have a kernel configuration file or a set of kernel configuration files that, when taken together, define the kernel configuration for your BSP. You can accomplish this definition by putting the configurations in a file or a set of files - inside a directory located at the same level as your append file and having the same name - as the kernel. - With all these conditions met simply reference those files in a + inside a directory located at the same level as your kernel's append file and having the same + name as the kernel's main recipe file. + With all these conditions met, simply reference those files in a SRC_URI statement in the append file. + For example, suppose you had a set of configuration options in a file called - myconfig. - If you put that file inside a directory named - /linux-yocto and then added + myconfig.cfg. + If you put that file inside a directory named /linux-yocto and then added a SRC_URI statement such as the following to the append file, - those configuration - options will be picked up and applied when the kernel is built. + those configuration options will be picked up and applied when the kernel is built. - SRC_URI += "file://myconfig" + SRC_URI += "file://myconfig.cfg" + As mentioned earlier, you can group related configurations into multiple files and name them all in the SRC_URI statement as well. @@ -612,11 +613,12 @@ into their own files and add those by using a SRC_URI statement like the following in your append file: - SRC_URI += "file://myconfig \ + SRC_URI += "file://myconfig.cfg \ file://eth.cfg \ file://gfx.cfg" + The FILESEXTRAPATHS variable is in boilerplate form in the previous example in order to make it easy to do that. @@ -625,32 +627,36 @@ The FILESEXTRAPATHS variable enables the build process to find those configuration files. + - Other methods exist to accomplish grouping and defining configuration options. - For example, if you are working with a local clone of the kernel repository, - you could checkout the kernel's meta branch, make your changes, - and then push the changes to the local bare clone of the kernel. - The result is that you directly add configuration options to the - meta branch for your BSP. - The configuration options will likely end up in that location anyway if the BSP gets - added to the Yocto Project. - For an example showing how to change the BSP configuration, see the - "Changing the BSP Configuration" - section in the Yocto Project Development Manual. - For a better understanding of working with a local clone of the kernel repository - and a local bare clone of the kernel, see the - "Modifying the Kernel - Source Code" section also in the Yocto Project Development Manual. + Other methods exist to accomplish grouping and defining configuration options. + For example, if you are working with a local clone of the kernel repository, + you could checkout the kernel's meta branch, make your changes, + and then push the changes to the local bare clone of the kernel. + The result is that you directly add configuration options to the + meta branch for your BSP. + The configuration options will likely end up in that location anyway if the BSP gets + added to the Yocto Project. + For an example showing how to change the BSP configuration, see the + "Changing the BSP Configuration" + section in the Yocto Project Development Manual. + For a better understanding of working with a local clone of the kernel repository + and a local bare clone of the kernel, see the + "Modifying the Kernel + Source Code" section also in the Yocto Project Development Manual. + + - In general, however, the Yocto Project maintainers take care of moving the - SRC_URI-specified - configuration options to the kernel's meta branch. - Not only is it easier for BSP developers to not have to worry about putting those - configurations in the branch, but having the maintainers do it allows them to apply - 'global' knowledge about the kinds of common configuration options multiple BSPs in - the tree are typically using. - This allows for promotion of common configurations into common features. + In general, however, the Yocto Project maintainers take care of moving the + SRC_URI-specified + configuration options to the kernel's meta branch. + Not only is it easier for BSP developers to not have to worry about putting those + configurations in the branch, but having the maintainers do it allows them to apply + 'global' knowledge about the kinds of common configuration options multiple BSPs in + the tree are typically using. + This allows for promotion of common configurations into common features. + -- cgit v1.2.3-54-g00ecf