sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

documentation/dev-manual/dev-manual-bsp-appendix.xml: Yocto term scrub 

Scrubbed the manual for the term "Yocto Project", which has been
over-used.  I updated occurrances to better represent actual bits
rather than generically referring to everything as Yocto Project.

(From yocto-docs rev: f70cffeffa0d8863a88783607621bf6f7125d02d)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2012-07-02 09:57:20 -07:00 committed by Richard Purdie
parent b634676b29
commit 7606c30c19
1 changed files with 21 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
documentation/dev-manual/dev-manual-bsp-appendix.xml
View File

@ -23,19 +23,20 @@
</para>
<section id='getting-local-yocto-project-files-and-bsp-files'>
<title>Getting Local Yocto Project Files and BSP Files</title>
<title>Getting Local Source Files and BSP Files</title>
<para>
You need to have the Yocto Project files available on your host system.
You can get files through tarball extraction or by cloning the <filename>poky</filename>
Git repository.
You need to have the <link linkend='source-directory'>source directory</link>
available on your host system.
You can set up this directory through tarball extraction or by cloning the
<filename>poky</filename> Git repository.
The following paragraphs describe both methods.
For additional information, see the bulleted item
"<link linkend='local-yp-release'>Yocto Project Release</link>".
</para>
<para>
As mentioned, one way to get the Yocto Project files is to use Git to clone the
As mentioned, one way to set up the source directory is to use Git to clone the
<filename>poky</filename> repository.
These commands create a local copy of the Git repository.
By default, the top-level directory of the repository is named <filename>poky</filename>:
@ -44,8 +45,8 @@
$ cd poky
</literallayout>
Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
These commands unpack the tarball into a Yocto Project File directory structure.
By default, the top-level directory of the file structure is named
These commands unpack the tarball into a source directory structure.
By default, the top-level directory of the source directory is named
<filename>&YOCTO_POKY;</filename>:
<literallayout class='monospaced'>
$ tar xfj &YOCTO_POKY_TARBALL;
@ -60,8 +61,7 @@
<para>Once you expand the released tarball, you have a snapshot of the Git repository
that represents a specific release.
Fundamentally, this is different than having a local copy of the Yocto Project
Git repository.
Fundamentally, this is different than having a local copy of the Poky Git repository.
Given the tarball method, changes you make are building on top of a release.
With the Git repository method you have the ability to track development
and keep changes in revision control.
@ -133,12 +133,12 @@
<para>
You need to have the base BSP layer on your development system.
Similar to the local <link linkend='yocto-project-files'>Yocto Project Files</link>,
Similar to the local <link linkend='source-directory'>source directory</link>,
you can get the BSP
layer in a couple of different ways:
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.
has the BSP layers.
You should use the same method that you used to set up the source directory earlier.
See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get
the BSP files.
</para>
@ -196,8 +196,8 @@
<title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
<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.
Now that you have set up the source directory and included 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>
@ -207,7 +207,7 @@
The name should follow the BSP layer naming convention, which is
<filename>meta-&lt;name&gt;</filename>.
The following assumes your working directory is <filename>meta-intel</filename>
inside the local Yocto Project files.
inside your source directory.
To start your new layer, just copy the new layer alongside the existing
BSP layers in the <filename>meta-intel</filename> directory:
<literallayout class='monospaced'>
@ -239,7 +239,7 @@
First, since in this example the new BSP will not support EMGD, we will get rid of the
<filename>crownbay.conf</filename> file and then rename the
<filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.
Much of what we do in the configuration directory is designed to help the Yocto Project
Much of what we do in the configuration directory is designed to help the OpenEmbedded
build system work with the new layer and to be able to find and use the right software.
The following two commands result in a single machine configuration file named
<filename>mymachine.conf</filename>.
@ -312,7 +312,7 @@
When you create a BSP, you use these areas for appropriate recipes and append files.
Recipes take the form of <filename>.bb</filename> files, while append files take
the form of <filename>.bbappend</filename> files.
If you want to leverage the existing recipes the Yocto Project build system uses
If you want to leverage the existing recipes the OpenEmbedded build system uses
but change those recipes, you can use <filename>.bbappend</filename> files.
All new recipes and append files for your layer must go in the layer’s
<filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>,
@ -365,7 +365,7 @@
Now let's look at changes in <filename>recipes-core</filename>.
The file <filename>task-core-tools.bbappend</filename> in
<filename>recipes-core/tasks</filename> appends the similarly named recipe
located in the local <link linkend='yocto-project-files'>Yocto Project Files</link> at
located in the <link linkend='source-directory'>source directory</link> at
<filename>meta/recipes-core/tasks</filename>.
The append file in our layer right now is Crown Bay-specific and supports
EMGD and non-EMGD.
@ -395,7 +395,7 @@
Recall that the BSP uses the <filename>linux-yocto</filename> kernel as determined
earlier in the <filename>mymachine.conf</filename>.
The recipe for that kernel is not located in the
BSP layer but rather in the local Yocto Project files at
BSP layer but rather in the source directory at
<filename>meta/recipes-kernel/linux</filename> and is
named <filename>linux-yocto_3.2.bb</filename>.
The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
@ -576,15 +576,14 @@
<orderedlist>
<listitem><para>Get the environment ready for the build by sourcing the environment
script.
The environment script is in the top-level of the local Yocto Project files
directory structure.
The environment script is in the top-level of the source directory.
The script has the string
<filename>init-build-env</filename> in the file’s name.
For this example, the following command gets the build environment ready:
<literallayout class='monospaced'>
$ source oe-init-build-env yocto-build
</literallayout>
When you source the script a build directory is created in the current
When you source the script, a build directory is created in the current
working directory.
In our example we were in the <filename>poky</filename> directory.
Thus, entering the previous command created the <filename>yocto-build</filename> directory.