summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--documentation/bsp-guide/bsp.xml89
1 files changed, 63 insertions, 26 deletions
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 75640cc58..ff8a4818f 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp-guide/bsp.xml
@@ -324,21 +324,22 @@ meta-<bsp_name>/recipes-kernel/linux/linux-wrs_git.bbappend
<para>
For your BSP you typically want to use an existing Poky kernel found in the
Poky repository at <filename class='directory'>meta/recipes-kernel/kernel</filename>.
- You can append your specific changes to the kernel by using a
- <filename>.bbappend</filename> file, which is located in the
- <filename class='directory'>meta-&lt;bsp_name&gt;/recipes-kernel/linux</filename>
+ You can append your specific changes to the kernel recipe by using an append file,
+ which is located in the
+ <filename class='directory'>meta-&lt;bsp_name&gt;/recipes-kernel/linux</filename>
directory.
</para>
<para>
- Consider a BSP that uses the <filename>linux-yocto-stable_git.bb</filename> kernel.
- You would use the <filename>linux-yocto-stable_git.bbappend</filename> file to add
+ Consider a BSP that uses the <filename>linux-yocto-stable_git.bb</filename> kernel,
+ which is the preferred kernel to use for developing a new BSP using the Yocto Project.
+ You would use the <filename>linux-yocto-stable_git.bbappend</filename> file to append
specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
</para>
<para>
Consider an example for the existing "crownbay" BSP.
- The <filename>.bbaappend</filename> file used for the "crownbay" BSP is:
+ The append file used for the "crownbay" BSP is:
<programlisting>
-meta-crownbay/recipes-kernel/linux/linux-wrs_git.bbappend
+meta-crownbay/recipes-kernel/linux/linux-yocto-stable_git.bbappend
</programlisting>
The file contains the following:
<programlisting>
@@ -346,31 +347,67 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
COMPATIBLE_MACHINE_crownbay = "cronwbay"
KMACHINE_crownbay = "crownbay"
</programlisting>
- This <filename>.bbappend</filename> file adds "crownbay" as a compatible machine,
+ This append file adds "crownbay" as a compatible machine,
and additionally sets a Yocto Kernel-specific variable that identifies the name of the
BSP branch to use in the GIT repository to find configuration information.
</para>
- <note><para>
- For an established BSP the configuration information is incorporated directly into the
- git tree.
- For a new BSP, however, the <filename>.bbappend</filename> file needs to
- include its own set of configuration options in a file called
- <filename>defconfig</filename> located in a directory that matches the recipe name.
+ <para>
+ One thing missing in this particular BSP, which you will typically need when
+ developing a BSP, is the kernel configuration (.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 SRC_URI statement in the append
+ file.
+ </para>
+ <para>
+ For example, suppose you had a set of configuration options in a file called
+ <filename>defonfig</filename>.
+ If you put that file inside a directory named
+ <filename class='directory'>/linux-yocto-stable_git</filename> 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.
<programlisting>
SRC_URI += "file://defconfig"
</programlisting>
- Once a BSP is committed, the Yocto kernel maintainer moves this configuration information
- into the git tree so that the <filename>.bbappend</filename> file does not need to locate
- its own configuration options.
- Again, the initial configuration options using the SRC_URI are put into a
- directory named
- <filename class='directory'>meta-&lt;bsp_name&gt;/recipes/linux/linux-yocto-stable</filename>.
- </para>
- <para>
- You can find more information about creating a BSP that is based on an existing similar
- BSP by reading the "Creating a BSP Based on an Existing Similar BSP" section in the
- "<ulink url="http://www.yoctoproject.org/community/documentation">Yocto Project
- Kernel Architecture and Use Manual</ulink>".
+ </para>
+ <para>
+ As mentioned earlier, you can group related configurations into multiple files and
+ name them all in the SRC_URI statement as well.
+ For example, you could group separate configurations specifically for ethernet and graphics
+ into their own files and add those by using a SRC_URI statement like the
+ following in your append file:
+ <programlisting>
+SRC_URI += "file://defconfig \
+ file://eth.cfg \
+ file://gfx.cfg"
+ </programlisting>
+ </para>
+ <para>
+ The FILESEXTRAPATHS variable is boilerplated here in order to make it easy to do that.
+ It basically allows those configuration files to be found by the build process.
+ </para>
+ <note><para>
+ Other methods exist to accomplish grouping and defining configuration options.
+ For example, you could directly add configuration options to the Yocto kernel
+ <filename class='directory'>wrs_meta</filename> 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 information on how to add these configurations directly, see the
+ "Yocto Project Kernel Architecture and Use Manual" on the
+ <ulink url="http://yoctoproject.org/community/documentation">Yocto Project website
+ Documentation Page</ulink>
+ </para>
+ <para>
+ In general, however, the Yocto Project maintainers take care of moving the SRC_URI-specified
+ configuration options to the <filename class='directory'>wrs_meta</filename> branch.
+ Not only is it easier for BSP developers to not have to worry about putting those
+ configurations in the branch, but having the manintainers 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.
</para></note>
</section>