documentation/dev-manual/dev-manual-bsp-appendix.xml: removed redundancies

Some of the more general BSP development information was more appropriate
in the dev-manual-cases chapter.  I removed this information and left
example-specific (mostly) text.

(From yocto-docs rev: d44c0fa8bdea9a2cad51ae3ca4b861a12d9fcdf9)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 10 insertions, 138 deletions

diff --git a/documentation/dev-manual/dev-manual-bsp-appendix.xml b/documentation/dev-manual/dev-manual-bsp-appendix.xml
index 9ccad10..3c0ab28 100644
--- a/documentation/dev-manual/dev-manual-bsp-appendix.xml
+++ b/documentation/dev-manual/dev-manual-bsp-appendix.xml
@@ -54,29 +54,15 @@
     <title>Choosing a Base BSP</title>
 
     <para>
-        The Yocto Project ships with several BSPs that support various hardware.  
-        It is best to base your new BSP on an existing BSP rather than create all the 
-        recipes and configuration files from scratch.  
-        While it is possible to create everything from scratch, basing your new BSP 
-        on something that is close is much easier.  
-        Or, at a minimum, it gives you some structure with which to start.
+        For this example, the base BSP is the Intel Atom Processor E660 with Intel Platform 
+        Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
+        The BSP layer is <filename>meta-crownbay</filename>.
     </para>
 
     <para>
-        At this point you need to understand your target hardware well enough to determine which 
-        existing BSP it most closely matches.  
-        Things to consider are your hardware’s on-board features such as CPU type and graphics support.  
-        You should look at the README files for supported BSPs to get an idea of which one 
-        you could use.  
-        A generic Atom-based BSP to consider is the Crown Bay that does not support
-        the Intel® Embedded Media Graphics Driver (EMGD).  
-        The remainder of this example uses that base BSP. 
-    </para>
-
-    <para>
-        To see the supported BSPs, go to the Yocto Project
-        <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click 
-        on “BSP Downloads.”
+        For information on how to choose a base BSP, see
+        <xref linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</xref>
+        earlier in this manual.
     </para>
 </section>
 
@@ -90,7 +76,7 @@
         download the BSP tarball and extract it, or set up a local Git repository that 
         has the Yocto Project BSP layers.  
         You should use the same method that you used to get the local Yocto Project files earlier.
-        See the <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+        See <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
         for information on how to get the BSP files.
     </para>
         
@@ -119,48 +105,11 @@
     <para>
         Now that you have the local Yocto Project files and the base BSP files you need to create a 
         new layer for your BSP.
+        To create your BSP layer you simply copy the <filename>meta-crownbay</filename>
+        layer to a new layer.
     </para>
 
-    <para>
-        Layers are ideal for isolating and storing work for a given piece of hardware.  
-        A layer is really just a location or area in which you place the recipes for your BSP.  
-        In fact, a BSP is, in itself, a special type of layer.   
-        Consider an application as another example that illustrates a layer.  
-        Suppose you are creating an application that has library or other dependencies in 
-        order for it to compile and run.  
-        The layer, in this case, would be where all the recipes that define those dependencies 
-        are kept.  The key point for a layer is that it is an isolated area that contains 
-        all the relevant information for the project that the Yocto Project build system knows about.
-    </para>
-
-    <note>
-        The Yocto Project supports four BSPs that are part of the 
-        Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
-        <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.  
-        The recipes and configurations for these four BSPs are located and dispersed 
-        within local Yocto Project files.
-        Consequently, they are not totally isolated in the spirit of layers unless you think 
-        of <filename>meta-yocto</filename> as a layer itself.  
-        On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest, 
-        N450, and Sugar Bay are isolated.
-    </note>
-
-    <para>
-        When you set up a layer for a new BSP you should follow a standard layout.  
-        This layout is described in the
-        <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout'>
-        Example Filesystem Layout</ulink> section of the Board Support Package (BSP) Development
-        Guide.  
-        In the standard layout you will notice a suggested structure for recipes and  
-        configuration information.  
-        You can see the standard layout for the Crown Bay BSP in this example by examining the 
-        directory structure of the <filename>meta-crownbay</filename> layer inside the 
-        local Yocto Project files.
-    </para>
-
-    <para>
-        To create your BSP layer you simply copy the <filename>meta-crownbay</filename>
-        layer to a new layer.  
+    <para>  
         For this example the new layer will be named <filename>meta-mymachine</filename>.  
         The name must follow the BSP layer naming convention, which is 
         <filename>meta-&lt;name&gt;</filename>.  
@@ -486,22 +435,6 @@
     <title>Preparing for the Build</title>
 
     <para>
-        Once you have made all the changes to your BSP layer there remains a few things 
-        you need to do for the Yocto Project build system in order for it to create your image.  
-        You need to get the build environment ready by sourcing an environment setup script 
-        and you need to be sure two key configuration files are configured appropriately.
-    </para>
-
-    <para>
-        The entire process for building an image is overviewed in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
-        Building an Image</ulink> section of the Yocto Project Quick Start.    
-        You might want to reference this information.  
-        The remainder of this section will apply to our example of the 
-        <filename>meta-mymachine</filename> layer.
-    </para>
-
-    <para>
         To get ready to build your image that uses the new layer you need to do the following:
         <orderedlist>
             <listitem><para>Get the environment ready for the build by sourcing the environment 
@@ -560,67 +493,6 @@
     <title>Building the Image</title>
 
     <para>
-        The Yocto Project uses the BitBake tool to build images based on the type of image 
-        you want to create.  
-        You can find more information on BitBake 
-        <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.  
-    </para>
-
-    <para>
-        The build process supports several types of images to satisfy different needs.  
-        When you issue the BitBake command you provide a “top-level” recipe that essentially 
-        starts the process off of building the type of image you want.  
-    </para>
-
-    <para>
-        [WRITER'S NOTE: Consider moving this to the Poky Reference Manual.]
-    </para>
-
-    <para>
-        You can find these recipes in the <filename>meta/recipes-core/images</filename> and 
-        <filename>meta/recipes-sato/images</filename> directories of your local Yocto Project 
-        file structure (Git repository or extracted release tarball).  
-        Although the recipe names are somewhat explanatory, here is a list that describes them:
-        <itemizedlist>
-            <listitem><para><emphasis>Base</emphasis> – A foundational basic image without support 
-                for X that can be reasonably used for customization.</para></listitem>
-            <listitem><para><emphasis>Core</emphasis> – A foundational basic image with support for 
-                X that can be reasonably used for customization.</para></listitem>
-            <listitem><para><emphasis>Direct Disk</emphasis> – An image that you can copy directory to 
-                the disk of the target device.</para></listitem>
-            <listitem><para><emphasis>Live</emphasis> – An image you can run from a USB device or from 
-                a CD without having to first install something.</para></listitem>
-                    <listitem><para><emphasis>Minimal</emphasis> – A small image without a GUI.  
-                This image is not much more than a kernel with a shell.</para></listitem>
-            <listitem><para><emphasis>Minimal Development</emphasis> – A Minimal image suitable for 
-                development work.</para></listitem>
-            <listitem><para><emphasis>Minimal Direct Disk</emphasis> – A Minimal Direct Disk image.</para></listitem>
-            <listitem><para><emphasis>Minimal RAM-based Initial Root Filesystem</emphasis> – A minimal image 
-                that has the <filename>initramfs</filename> as part of the kernel, which allows the 
-                system to find the first “init” program more efficiently.</para></listitem>
-            <listitem><para><emphasis>Minimal Live</emphasis> – A Minimal Live image.</para></listitem>
-            <listitem><para><emphasis>Minimal MTD Utilities</emphasis> – A minimal image that has support 
-                for the MTD utilities, which let the user interact with the MTD subsystem in 
-                the kernel to perform operations on flash devices.</para></listitem>
-            <listitem><para><emphasis>Sato</emphasis> – An image with Sato support, a mobile environment 
-                and visual style that works well with mobile devices.</para></listitem>
-            <listitem><para><emphasis>Sato Development</emphasis> – A Sato image suitable for 
-                development work.</para></listitem>
-            <listitem><para><emphasis>Sato Direct Disk</emphasis> – A Sato Direct Disk image.</para></listitem>
-            <listitem><para><emphasis>Sato Live</emphasis> – A Sato Live image.</para></listitem>
-            <listitem><para><emphasis>Sato SDK</emphasis> – A Sato image that includes the Yocto Project 
-                toolchain and development libraries.</para></listitem>
-            <listitem><para><emphasis>Sato SDK Direct Disk</emphasis> – A Sato SDK Direct 
-                Disk image.</para></listitem>
-            <listitem><para><emphasis>Sato SDK Live</emphasis> – A Sato SDK Live image.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        The remainder of this section applies to our example of the <filename>meta-mymachine</filename> layer.
-    </para>
-
-    <para>
         To build the image for our <filename>meta-mymachine</filename> BSP enter the following command 
         from the same shell from which you ran the setup script.  
         You should run the <filename>bitbake</filename> command without any intervening shell commands.