2011-07-27 14:03:00 +00:00
|
|
|
|
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
2012-03-09 19:40:39 +00:00
|
|
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
|
|
|
|
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
|
|
|
|
<appendix id='dev-manual-bsp-appendix'>
|
|
|
|
|
|
2011-07-27 20:29:36 +00:00
|
|
|
|
<title>BSP Development Example</title>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
2011-11-04 14:56:35 +00:00
|
|
|
|
This appendix provides a complete BSP development example.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
The example assumes the following:
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
<listitem><para>Use of the Crown Bay Board Support Package (BSP) as a "base" BSP from
|
|
|
|
|
which to work.
|
|
|
|
|
The example begins with the Crown Bay BSP as the starting point
|
|
|
|
|
but ends by building a new 'atom-pc' BSP, which was based on the Crown Bay BSP.
|
|
|
|
|
</para></listitem>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
|
|
|
|
|
<listitem><para>Example was developed on an Intel-based Core i7 platform running
|
|
|
|
|
Ubuntu 10.04 LTS released in April of 2010.</para></listitem>
|
|
|
|
|
</itemizedlist>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
2011-07-27 15:16:48 +00:00
|
|
|
|
<section id='getting-local-yocto-project-files-and-bsp-files'>
|
2012-07-02 16:57:20 +00:00
|
|
|
|
<title>Getting Local Source Files and BSP Files</title>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<para>
|
2012-07-02 16:57:20 +00:00
|
|
|
|
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.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
The following paragraphs describe both methods.
|
|
|
|
|
For additional information, see the bulleted item
|
|
|
|
|
"<link linkend='local-yp-release'>Yocto Project Release</link>".
|
2012-02-02 17:16:54 +00:00
|
|
|
|
</para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
2012-07-02 16:57:20 +00:00
|
|
|
|
As mentioned, one way to set up the source directory is to use Git to clone the
|
2012-02-03 18:33:05 +00:00
|
|
|
|
<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>:
|
2011-11-03 17:58:14 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
|
$ git clone git://git.yoctoproject.org/poky
|
|
|
|
|
$ cd poky
|
|
|
|
|
</literallayout>
|
2012-04-23 20:41:10 +00:00
|
|
|
|
Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
|
2012-07-02 16:57:20 +00:00
|
|
|
|
These commands unpack the tarball into a source directory structure.
|
|
|
|
|
By default, the top-level directory of the source directory is named
|
2012-04-26 20:37:48 +00:00
|
|
|
|
<filename>&YOCTO_POKY;</filename>:
|
2011-11-03 17:58:14 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2012-03-09 19:40:39 +00:00
|
|
|
|
$ tar xfj &YOCTO_POKY_TARBALL;
|
|
|
|
|
$ cd &YOCTO_POKY;
|
2011-11-03 17:58:14 +00:00
|
|
|
|
</literallayout>
|
2012-02-02 17:16:54 +00:00
|
|
|
|
<note><para>If you're using the tarball method, you can ignore all the following steps that
|
2011-11-03 17:58:14 +00:00
|
|
|
|
ask you to carry out Git operations.
|
|
|
|
|
You already have the results of those operations
|
2012-04-23 20:41:10 +00:00
|
|
|
|
in the form of the &DISTRO_NAME; release tarballs.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
Consequently, there is nothing left to do other than extract those tarballs into the
|
2012-02-02 17:16:54 +00:00
|
|
|
|
proper locations.</para>
|
|
|
|
|
|
|
|
|
|
<para>Once you expand the released tarball, you have a snapshot of the Git repository
|
|
|
|
|
that represents a specific release.
|
2012-07-02 16:57:20 +00:00
|
|
|
|
Fundamentally, this is different than having a local copy of the Poky Git repository.
|
2012-02-03 18:33:05 +00:00
|
|
|
|
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.
|
|
|
|
|
See the
|
|
|
|
|
"<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>" section
|
2012-04-26 20:40:57 +00:00
|
|
|
|
for more discussion around these differences.</para></note>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</para>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<para>
|
2012-02-02 17:16:54 +00:00
|
|
|
|
With the local <filename>poky</filename> Git repository set up,
|
2012-02-01 00:24:48 +00:00
|
|
|
|
you have all the development branches available to you from which you can work.
|
2012-02-02 17:16:54 +00:00
|
|
|
|
Next, you need to be sure that your local repository reflects the exact
|
|
|
|
|
release in which you are interested.
|
2012-02-01 00:24:48 +00:00
|
|
|
|
From inside the repository you can see the development branches that represent
|
2012-02-03 18:33:05 +00:00
|
|
|
|
areas of development that have diverged from the main (master) branch
|
|
|
|
|
at some point, such as a branch to track a maintenance release's development.
|
2012-02-01 00:24:48 +00:00
|
|
|
|
You can also see the tag names used to mark snapshots of stable releases or
|
|
|
|
|
points in the repository.
|
|
|
|
|
Use the following commands to list out the branches and the tags in the repository,
|
|
|
|
|
respectively.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
$ git branch -a
|
|
|
|
|
$ git tag -l
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</literallayout>
|
2012-03-09 19:40:39 +00:00
|
|
|
|
For this example, we are going to use the Yocto Project &DISTRO; Release, which is code
|
|
|
|
|
named "&DISTRO_NAME;".
|
2012-02-02 17:16:54 +00:00
|
|
|
|
To make sure we have a local area (branch in Git terms) on our machine that
|
2012-03-09 19:40:39 +00:00
|
|
|
|
reflects the &DISTRO; release, we can use the following commands:
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2012-02-01 00:24:48 +00:00
|
|
|
|
$ cd ~/poky
|
|
|
|
|
$ git fetch --tags
|
2012-03-09 19:40:39 +00:00
|
|
|
|
$ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME;
|
|
|
|
|
Switched to a new branch '&DISTRO_NAME;'
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</literallayout>
|
2012-02-01 00:24:48 +00:00
|
|
|
|
The <filename>git fetch --tags</filename> is somewhat redundant since you just set
|
|
|
|
|
up the repository and should have all the tags.
|
|
|
|
|
The <filename>fetch</filename> command makes sure all the tags are available in your
|
|
|
|
|
local repository.
|
|
|
|
|
The Git <filename>checkout</filename> command with the <filename>-b</filename> option
|
2012-03-09 19:40:39 +00:00
|
|
|
|
creates a local branch for you named <filename>&DISTRO_NAME;</filename>.
|
|
|
|
|
Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball
|
|
|
|
|
marked with the <filename>&DISTRO_NAME;-&POKYVERSION;</filename> tag in the source repositories.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</para>
|
2012-02-02 17:16:54 +00:00
|
|
|
|
</section>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
|
|
|
|
|
<section id='choosing-a-base-bsp-app'>
|
|
|
|
|
<title>Choosing a Base BSP</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
2011-10-03 18:41:12 +00:00
|
|
|
|
For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
|
|
|
|
|
<trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform
|
2011-07-27 18:50:26 +00:00
|
|
|
|
Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
|
2011-11-03 17:58:14 +00:00
|
|
|
|
The BSP layer is <filename>meta-crownbay</filename>.
|
|
|
|
|
The base BSP is simply the BSP
|
|
|
|
|
we will be using as a starting point, so don't worry if you don't actually have Crown Bay
|
|
|
|
|
hardware.
|
|
|
|
|
The remainder of the example transforms the base BSP into a BSP that should be
|
|
|
|
|
able to boot on generic atom-pc (netbook) hardware.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2011-07-27 18:50:26 +00:00
|
|
|
|
For information on how to choose a base BSP, see
|
2011-10-04 13:00:29 +00:00
|
|
|
|
"<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>".
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='getting-your-base-bsp-app'>
|
|
|
|
|
<title>Getting Your Base BSP</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
You need to have the base BSP layer on your development system.
|
2012-07-02 16:57:20 +00:00
|
|
|
|
Similar to the local <link linkend='source-directory'>source directory</link>,
|
2012-04-26 20:48:19 +00:00
|
|
|
|
you can get the BSP
|
2011-11-04 21:22:05 +00:00
|
|
|
|
layer in a couple of different ways:
|
2011-07-27 14:55:55 +00:00
|
|
|
|
download the BSP tarball and extract it, or set up a local Git repository that
|
2012-07-02 16:57:20 +00:00
|
|
|
|
has the BSP layers.
|
|
|
|
|
You should use the same method that you used to set up the source directory earlier.
|
2011-10-04 13:00:29 +00:00
|
|
|
|
See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get
|
2011-10-04 12:56:17 +00:00
|
|
|
|
the BSP files.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
This example assumes the BSP layer will be located within a directory named
|
|
|
|
|
<filename>meta-intel</filename> contained within the <filename>poky</filename>
|
|
|
|
|
parent directory.
|
|
|
|
|
The following steps will automatically create the
|
2011-11-03 19:56:36 +00:00
|
|
|
|
<filename>meta-intel</filename> directory and the contained
|
|
|
|
|
<filename>meta-crownbay</filename> starting point in both the Git and the tarball cases.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</para>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
If you're using the Git method, you could do the following to create
|
|
|
|
|
the starting layout after you have made sure you are in the <filename>poky</filename>
|
|
|
|
|
directory created in the previous steps:
|
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
|
$ git clone git://git.yoctoproject.org/meta-intel.git
|
|
|
|
|
$ cd meta-intel
|
|
|
|
|
</literallayout>
|
2011-11-04 14:56:35 +00:00
|
|
|
|
Alternatively, you can start with the downloaded Crown Bay tarball.
|
2012-04-23 20:41:10 +00:00
|
|
|
|
You can download the &DISTRO_NAME; version of the BSP tarball from the
|
2012-03-09 19:40:39 +00:00
|
|
|
|
<ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page of the
|
2011-11-03 19:56:36 +00:00
|
|
|
|
Yocto Project website.
|
|
|
|
|
Here is the specific link for the tarball needed for this example:
|
2012-04-26 20:55:52 +00:00
|
|
|
|
<ulink url='&YOCTO_MACHINES_DL_URL;/crownbay-noemgd/crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2'></ulink>.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
Again, be sure that you are already in the <filename>poky</filename> directory
|
2011-11-03 19:56:36 +00:00
|
|
|
|
as described previously before installing the tarball:
|
2011-11-03 17:58:14 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2012-04-26 20:55:52 +00:00
|
|
|
|
$ tar xfj crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2
|
2011-11-03 17:58:14 +00:00
|
|
|
|
$ cd meta-intel
|
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The <filename>meta-intel</filename> directory contains all the metadata
|
|
|
|
|
that supports BSP creation.
|
|
|
|
|
If you're using the Git method, the following
|
2012-04-23 20:41:10 +00:00
|
|
|
|
step will switch to the &DISTRO_NAME; metadata.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
If you're using the tarball method, you already have the correct metadata and can
|
|
|
|
|
skip to the next step.
|
2011-07-27 16:06:05 +00:00
|
|
|
|
Because <filename>meta-intel</filename> is its own Git repository, you will want
|
2011-07-27 14:55:55 +00:00
|
|
|
|
to be sure you are in the appropriate branch for your work.
|
2012-03-09 19:40:39 +00:00
|
|
|
|
For this example we are going to use the <filename>&DISTRO_NAME;</filename> branch.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2012-03-09 19:40:39 +00:00
|
|
|
|
$ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
|
2012-04-26 21:03:25 +00:00
|
|
|
|
Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
|
2012-03-09 19:40:39 +00:00
|
|
|
|
Switched to a new branch '&DISTRO_NAME;'
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='making-a-copy-of-the-base bsp-to-create-your-new-bsp-layer-app'>
|
|
|
|
|
<title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
2012-07-02 16:57:20 +00:00
|
|
|
|
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.
|
2011-10-03 18:41:12 +00:00
|
|
|
|
To create your BSP layer, you simply copy the <filename>meta-crownbay</filename>
|
2011-07-27 18:50:26 +00:00
|
|
|
|
layer to a new layer.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
2011-07-27 18:50:26 +00:00
|
|
|
|
<para>
|
2011-10-03 18:41:12 +00:00
|
|
|
|
For this example, the new layer will be named <filename>meta-mymachine</filename>.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
The name should follow the BSP layer naming convention, which is
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<filename>meta-<name></filename>.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
The following assumes your working directory is <filename>meta-intel</filename>
|
2012-07-02 16:57:20 +00:00
|
|
|
|
inside your source directory.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
To start your new layer, just copy the new layer alongside the existing
|
|
|
|
|
BSP layers in the <filename>meta-intel</filename> directory:
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
$ cp -a meta-crownbay/ meta-mymachine
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='making-changes-to-your-bsp-app'>
|
|
|
|
|
<title>Making Changes to Your BSP</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Right now you have two identical BSP layers with different names:
|
|
|
|
|
<filename>meta-crownbay</filename> and <filename>meta-mymachine</filename>.
|
|
|
|
|
You need to change your configurations so that they work for your new BSP and
|
2011-07-27 16:32:27 +00:00
|
|
|
|
your particular hardware.
|
|
|
|
|
The following sections look at each of these areas of the BSP.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<section id='changing-the-bsp-configuration'>
|
|
|
|
|
<title>Changing the BSP Configuration</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
We will look first at the configurations, which are all done in the layer’s
|
|
|
|
|
<filename>conf</filename> directory.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2011-10-03 18:41:12 +00:00
|
|
|
|
First, since in this example the new BSP will not support EMGD, we will get rid of the
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<filename>crownbay.conf</filename> file and then rename the
|
|
|
|
|
<filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.
|
2012-07-02 16:57:20 +00:00
|
|
|
|
Much of what we do in the configuration directory is designed to help the OpenEmbedded
|
2011-07-27 16:32:27 +00:00
|
|
|
|
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>.
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
$ rm meta-mymachine/conf/machine/crownbay.conf
|
|
|
|
|
$ mv meta-mymachine/conf/machine/crownbay-noemgd.conf \
|
|
|
|
|
meta-mymachine/conf/machine/mymachine.conf
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
Next, we need to make changes to the <filename>mymachine.conf</filename> itself.
|
|
|
|
|
The only changes we want to make for this example are to the comment lines.
|
|
|
|
|
Changing comments, of course, is never strictly necessary, but it's alway good form to make
|
|
|
|
|
them reflect reality as much as possible.
|
|
|
|
|
|
|
|
|
|
Here, simply substitute the Crown Bay name with an appropriate name for the BSP
|
|
|
|
|
(<filename>mymachine</filename> in this case) and change the description to
|
|
|
|
|
something that describes your hardware.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Note that inside the <filename>mymachine.conf</filename> is the
|
2012-04-26 23:19:16 +00:00
|
|
|
|
<filename>PREFERRED_VERSION_linux-yocto</filename> statement.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
This statement identifies the kernel that the BSP is going to use.
|
2011-10-03 18:41:12 +00:00
|
|
|
|
In this case, the BSP is using <filename>linux-yocto</filename>, which is the
|
2012-07-02 17:19:10 +00:00
|
|
|
|
current Yocto Project kernel based on the Linux 3.2 release.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
The next configuration file in the new BSP layer we need to edit is
|
|
|
|
|
<filename>meta-mymachine/conf/layer.conf</filename>.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
This file identifies build information needed for the new layer.
|
|
|
|
|
You can see the
|
2012-03-09 19:40:39 +00:00
|
|
|
|
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-layer'>Layer Configuration File</ulink>" section
|
2012-02-06 18:11:20 +00:00
|
|
|
|
in The Board Support Packages (BSP) Development Guide for more information on this configuration file.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
Basically, we are changing the existing statements to work with our BSP.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The file contains these statements that reference the Crown Bay BSP:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
BBFILE_COLLECTIONS += "crownbay"
|
|
|
|
|
BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
|
|
|
|
|
BBFILE_PRIORITY_crownbay = "6"
|
2012-04-26 21:17:57 +00:00
|
|
|
|
|
|
|
|
|
LAYERDEPENDS_crownbay = "intel"
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<para>
|
|
|
|
|
Simply substitute the machine string name <filename>crownbay</filename>
|
|
|
|
|
with the new machine name <filename>mymachine</filename> to get the following:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-08-31 16:00:55 +00:00
|
|
|
|
BBFILE_COLLECTIONS += "mymachine"
|
2011-07-27 14:03:00 +00:00
|
|
|
|
BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
|
|
|
|
|
BBFILE_PRIORITY_mymachine = "6"
|
2012-04-26 21:17:57 +00:00
|
|
|
|
|
|
|
|
|
LAYERDEPENDS_mymachine = "intel"
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='changing-the-recipes-in-your-bsp'>
|
|
|
|
|
<title>Changing the Recipes in Your BSP</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Now we will take a look at the recipes in your new layer.
|
|
|
|
|
The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.
|
2011-10-03 18:41:12 +00:00
|
|
|
|
When you create a BSP, you use these areas for appropriate recipes and append files.
|
2012-03-13 22:49:49 +00:00
|
|
|
|
Recipes take the form of <filename>.bb</filename> files, while append files take
|
|
|
|
|
the form of <filename>.bbappend</filename> files.
|
2012-07-02 16:57:20 +00:00
|
|
|
|
If you want to leverage the existing recipes the OpenEmbedded build system uses
|
2011-10-03 18:41:12 +00:00
|
|
|
|
but change those recipes, you can use <filename>.bbappend</filename> files.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
All new recipes and append files for your layer must go in the layer’s
|
|
|
|
|
<filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>,
|
|
|
|
|
<filename>recipes-core</filename>, and
|
|
|
|
|
<filename>recipes-graphics</filename> directories.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<section id='changing-recipes-bsp'>
|
2011-11-04 21:22:05 +00:00
|
|
|
|
<title>Changing <filename>recipes-bsp</filename></title>
|
2011-07-27 16:32:27 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
First, let's look at <filename>recipes-bsp</filename>.
|
|
|
|
|
For this example we are not adding any new BSP recipes.
|
|
|
|
|
And, we only need to remove the formfactor we do not want and change the name of
|
|
|
|
|
the remaining one that doesn't support EMGD.
|
|
|
|
|
These commands take care of the <filename>recipes-bsp</filename> recipes:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
$ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
|
2011-07-27 14:03:00 +00:00
|
|
|
|
$ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \
|
|
|
|
|
meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='changing-recipes-graphics'>
|
2011-11-04 21:22:05 +00:00
|
|
|
|
<title>Changing <filename>recipes-graphics</filename></title>
|
2011-07-27 16:32:27 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Now let's look at <filename>recipes-graphics</filename>.
|
|
|
|
|
For this example we want to remove anything that supports EMGD and
|
|
|
|
|
be sure to rename remaining directories appropriately.
|
|
|
|
|
The following commands clean up the <filename>recipes-graphics</filename> directory:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-28 20:24:18 +00:00
|
|
|
|
$ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
|
2011-07-27 14:03:00 +00:00
|
|
|
|
$ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
|
|
|
|
|
meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
At this point the <filename>recipes-graphics</filename> directory just has files that
|
|
|
|
|
support Video Electronics Standards Association (VESA) graphics modes and not EMGD.
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='changing-recipes-core'>
|
2011-11-04 21:22:05 +00:00
|
|
|
|
<title>Changing <filename>recipes-core</filename></title>
|
2011-07-27 16:32:27 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
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
|
2012-07-02 16:57:20 +00:00
|
|
|
|
located in the <link linkend='source-directory'>source directory</link> at
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<filename>meta/recipes-core/tasks</filename>.
|
2012-03-13 22:51:53 +00:00
|
|
|
|
The append file in our layer right now is Crown Bay-specific and supports
|
2011-07-27 16:32:27 +00:00
|
|
|
|
EMGD and non-EMGD.
|
|
|
|
|
Here are the contents of the file:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
RRECOMMENDS_task-core-tools-profile_append_crownbay = " systemtap"
|
|
|
|
|
RRECOMMENDS_task-core-tools-profile_append_crownbay-noemgd = " systemtap"
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The <filename>RRECOMMENDS</filename> statements list packages that
|
|
|
|
|
extend usability.
|
|
|
|
|
The first <filename>RRECOMMENDS</filename> statement can be removed, while the
|
|
|
|
|
second one can be changed to reflect <filename>meta-mymachine</filename>:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
RRECOMMENDS_task-core-tools-profile_append_mymachine = " systemtap"
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='changing-recipes-kernel'>
|
2011-11-04 21:22:05 +00:00
|
|
|
|
<title>Changing <filename>recipes-kernel</filename></title>
|
2011-07-27 16:32:27 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Finally, let's look at <filename>recipes-kernel</filename> changes.
|
|
|
|
|
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
|
2012-07-02 16:57:20 +00:00
|
|
|
|
BSP layer but rather in the source directory at
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<filename>meta/recipes-kernel/linux</filename> and is
|
2012-04-26 21:30:35 +00:00
|
|
|
|
named <filename>linux-yocto_3.2.bb</filename>.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
|
|
|
|
|
statements point to the exact commits used by the Yocto Project development team
|
|
|
|
|
in their source repositories that identify the right kernel for our hardware.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
In other words, the <filename>SRCREV</filename> values are simply Git commit
|
|
|
|
|
IDs that identify which commit on each
|
|
|
|
|
of the kernel branches (machine and meta) will be checked out and used to build
|
|
|
|
|
the kernel.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</para>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<para>
|
|
|
|
|
However, in the <filename>meta-mymachine</filename> layer in
|
|
|
|
|
<filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
|
2012-04-26 21:30:35 +00:00
|
|
|
|
file named <filename>linux-yocto_3.2.bbappend</filename> that
|
2012-03-13 22:57:17 +00:00
|
|
|
|
appends information to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
|
|
|
|
|
Thus, the <filename>SRCREV</filename> statements in the append file override
|
2011-07-27 16:32:27 +00:00
|
|
|
|
the more general statements found in <filename>meta</filename>.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2012-03-13 22:57:17 +00:00
|
|
|
|
The <filename>SRCREV</filename> statements in the append file currently identify
|
2011-07-27 16:32:27 +00:00
|
|
|
|
the kernel that supports the Crown Bay BSP with and without EMGD support.
|
2012-05-24 13:03:29 +00:00
|
|
|
|
Here are the statements:
|
|
|
|
|
<note>The commit ID strings used in this manual might not match the actual commit
|
|
|
|
|
ID strings found in the <filename>linux-yocto_3.2.bbappend</filename> file.
|
|
|
|
|
For the example, this difference does not matter.</note>
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
SRCREV_machine_pn-linux-yocto_crownbay ?= \
|
2012-04-26 22:04:12 +00:00
|
|
|
|
"211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
|
2011-07-27 14:03:00 +00:00
|
|
|
|
SRCREV_meta_pn-linux-yocto_crownbay ?= \
|
2012-04-26 22:04:12 +00:00
|
|
|
|
"514847185c78c07f52e02750fbe0a03ca3a31d8f"
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
|
|
|
|
SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
|
2012-04-26 22:04:12 +00:00
|
|
|
|
"211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
|
2011-07-27 14:03:00 +00:00
|
|
|
|
SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
|
2012-04-26 22:04:12 +00:00
|
|
|
|
"514847185c78c07f52e02750fbe0a03ca3a31d8f"
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
You will notice that there are two pairs of <filename>SRCREV</filename> statements.
|
|
|
|
|
The top pair identifies the kernel that supports
|
|
|
|
|
EMGD, which we don’t care about in this example.
|
|
|
|
|
The bottom pair identifies the kernel that we will use:
|
|
|
|
|
<filename>linux-yocto</filename>.
|
|
|
|
|
At this point though, the unique commit strings all are still associated with
|
|
|
|
|
Crown Bay and not <filename>meta-mymachine</filename>.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2012-04-26 21:30:35 +00:00
|
|
|
|
To fix this situation in <filename>linux-yocto_3.2.bbappend</filename>,
|
2011-07-27 16:32:27 +00:00
|
|
|
|
we delete the two <filename>SRCREV</filename> statements that support
|
2011-10-03 18:41:12 +00:00
|
|
|
|
EMGD (the top pair).
|
2011-07-27 16:32:27 +00:00
|
|
|
|
We also change the remaining pair to specify <filename>mymachine</filename>
|
|
|
|
|
and insert the commit identifiers to identify the kernel in which we
|
|
|
|
|
are interested, which will be based on the <filename>atom-pc-standard</filename>
|
|
|
|
|
kernel.
|
2012-04-23 20:41:10 +00:00
|
|
|
|
In this case, because we're working with the &DISTRO_NAME; branch of everything, we
|
2011-11-03 17:58:14 +00:00
|
|
|
|
need to use the <filename>SRCREV</filename> values for the atom-pc branch
|
2012-04-23 20:41:10 +00:00
|
|
|
|
that are associated with the &DISTRO_NAME; release.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
To find those values, we need to find the <filename>SRCREV</filename>
|
2012-04-23 20:41:10 +00:00
|
|
|
|
values that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
|
2012-04-26 21:30:35 +00:00
|
|
|
|
<filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend</filename>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
file.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The machine <filename>SRCREV</filename> we want is in the
|
|
|
|
|
<filename>SRCREV_machine_atom-pc</filename> variable.
|
|
|
|
|
The meta <filename>SRCREV</filename> isn't specified in this file, so it must be
|
|
|
|
|
specified in the base kernel recipe in the
|
2012-04-26 21:30:35 +00:00
|
|
|
|
<filename>poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb</filename>
|
2012-04-26 22:04:12 +00:00
|
|
|
|
file, in the <filename>SRCREV_meta</filename> variable found there.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
Here are the final <filename>SRCREV</filename> statements:
|
|
|
|
|
<literallayout class='monospaced'>
|
2012-04-26 22:04:12 +00:00
|
|
|
|
SRCREV_machine_pn-linux-yocto_mymachine ?= \
|
|
|
|
|
"f29531a41df15d74be5ad47d958e4117ca9e489e"
|
|
|
|
|
SRCREV_meta_pn-linux-yocto_mymachine ?= \
|
|
|
|
|
"b14a08f5c7b469a5077c10942f4e1aec171faa9d"
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
In this example, we're using the <filename>SRCREV</filename> values we
|
2012-04-23 20:41:10 +00:00
|
|
|
|
found already captured in the &DISTRO_NAME; release because we're creating a BSP based on
|
|
|
|
|
&DISTRO_NAME;.
|
2011-11-03 17:58:14 +00:00
|
|
|
|
If, instead, we had based our BSP on the master branches, we would want to use
|
|
|
|
|
the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
|
|
|
|
|
We will not be doing that for this example.
|
|
|
|
|
However, if you do base a future BSP on master and
|
|
|
|
|
if you are familiar with Git repositories, you probably won’t have trouble locating the
|
2011-07-27 16:32:27 +00:00
|
|
|
|
exact commit strings in the Yocto Project source repositories you need to change
|
|
|
|
|
the <filename>SRCREV</filename> statements.
|
|
|
|
|
You can find all the <filename>machine</filename> and <filename>meta</filename>
|
2012-04-26 21:30:35 +00:00
|
|
|
|
branch points (commits) for the <filename>linux-yocto-3.2</filename> kernel at
|
|
|
|
|
<ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/linux-yocto-3.2'></ulink>.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
If you need a little more assistance after going to the link then do the following:
|
|
|
|
|
<orderedlist>
|
|
|
|
|
<listitem><para>Expand the list of branches by clicking <filename>[…]</filename></para></listitem>
|
2012-04-26 22:04:12 +00:00
|
|
|
|
<listitem><para>Click on the <filename>standard/default/common-pc/atom-pc</filename>
|
2011-07-27 16:32:27 +00:00
|
|
|
|
branch</para></listitem>
|
|
|
|
|
<listitem><para>Click on the commit column header to view the top commit</para></listitem>
|
|
|
|
|
<listitem><para>Copy the commit string for use in the
|
2012-04-26 21:30:35 +00:00
|
|
|
|
<filename>linux-yocto_3.2.bbappend</filename> file</para></listitem>
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</orderedlist>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
For the <filename>SRCREV</filename> statement that points to the <filename>meta</filename>
|
|
|
|
|
branch use the same procedure except expand the <filename>meta</filename>
|
|
|
|
|
branch in step 2 above.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2012-04-26 21:30:35 +00:00
|
|
|
|
Also in the <filename>linux-yocto_3.2.bbappend</filename> file are
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<filename>COMPATIBLE_MACHINE</filename>, <filename>KMACHINE</filename>,
|
2012-05-24 13:21:31 +00:00
|
|
|
|
and <filename>KBRANCH</filename> statements.
|
2011-07-27 16:32:27 +00:00
|
|
|
|
Two sets of these exist: one set supports EMGD and one set does not.
|
2012-05-24 13:21:31 +00:00
|
|
|
|
Because we are not interested in supporting EMGD those three can be deleted.
|
|
|
|
|
The remaining three must be changed so that <filename>mymachine</filename> replaces
|
2011-07-27 16:32:27 +00:00
|
|
|
|
<filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
|
2012-04-26 22:04:12 +00:00
|
|
|
|
Because we are using the <filename>atom-pc</filename> branch for this new BSP, we can also find
|
2012-04-26 23:31:44 +00:00
|
|
|
|
the exact branch we need for the <filename>KMACHINE</filename>
|
|
|
|
|
and <filename>KBRANCH</filename> variables in our new BSP from the value
|
2011-11-03 17:58:14 +00:00
|
|
|
|
we find in the
|
2012-04-26 21:30:35 +00:00
|
|
|
|
<filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend</filename>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
file we looked at in a previous step.
|
2012-04-26 23:31:44 +00:00
|
|
|
|
In this case, the values we want are in the <filename>KMACHINE_atom-pc</filename> variable
|
|
|
|
|
and the <filename>KBRANCH_atom-pc</filename> variables in that file.
|
2012-04-26 21:30:35 +00:00
|
|
|
|
Here is the final <filename>linux-yocto_3.2.bbappend</filename> file after all
|
2011-07-27 16:32:27 +00:00
|
|
|
|
the edits:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
|
|
|
|
|
|
|
|
|
|
COMPATIBLE_MACHINE_mymachine = "mymachine"
|
2012-04-26 22:04:12 +00:00
|
|
|
|
KMACHINE_mymachine = "atom-pc"
|
|
|
|
|
KBRANCH_mymachine = "standard/default/common-pc/atom-pc"
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
|
|
|
|
SRCREV_machine_pn-linux-yocto_mymachine ?= \
|
2012-04-26 22:04:12 +00:00
|
|
|
|
"f29531a41df15d74be5ad47d958e4117ca9e489e"
|
2011-07-27 14:03:00 +00:00
|
|
|
|
SRCREV_meta_pn-linux-yocto_mymachine ?= \
|
2012-04-26 22:04:12 +00:00
|
|
|
|
"b14a08f5c7b469a5077c10942f4e1aec171faa9d"
|
2011-07-27 16:32:27 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='bsp-recipe-change-summary'>
|
|
|
|
|
<title>BSP Recipe Change Summary</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
In summary, the edits to the layer’s recipe files result in removal of any files and
|
|
|
|
|
statements that do not support your targeted hardware in addition to the inclusion
|
|
|
|
|
of any new recipes you might need.
|
|
|
|
|
In this example, it was simply a matter of ridding the new layer
|
2011-11-02 21:06:36 +00:00
|
|
|
|
<filename>meta-mymachine</filename> of any code that supported the EMGD features
|
2011-07-27 16:32:27 +00:00
|
|
|
|
and making sure we were identifying the kernel that supports our example, which
|
|
|
|
|
is the <filename>atom-pc-standard</filename> kernel.
|
|
|
|
|
We did not introduce any new recipes to the layer.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Finally, it is also important to update the layer’s <filename>README</filename>
|
|
|
|
|
file so that the information in it reflects your BSP.
|
|
|
|
|
</para>
|
|
|
|
|
</section>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</section>
|
|
|
|
|
|
|
|
|
|
<section id='preparing-for-the-build-app'>
|
|
|
|
|
<title>Preparing for the Build</title>
|
|
|
|
|
|
|
|
|
|
<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
|
|
|
|
|
script.
|
2012-07-02 16:57:20 +00:00
|
|
|
|
The environment script is in the top-level of the source directory.
|
2011-07-27 14:55:55 +00:00
|
|
|
|
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:
|
2011-07-27 14:03:00 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
$ source oe-init-build-env yocto-build
|
2011-07-27 14:03:00 +00:00
|
|
|
|
</literallayout>
|
2012-07-02 16:57:20 +00:00
|
|
|
|
When you source the script, a build directory is created in the current
|
2011-07-27 14:55:55 +00:00
|
|
|
|
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.
|
|
|
|
|
If you do not provide a name for the build directory it defaults to
|
|
|
|
|
<filename>build</filename>.
|
2011-11-02 21:06:36 +00:00
|
|
|
|
The <filename>yocto-build</filename> directory contains a
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<filename>conf</filename> directory that has
|
|
|
|
|
two configuration files you will need to check: <filename>bblayers.conf</filename>
|
|
|
|
|
and <filename>local.conf</filename>.</para></listitem>
|
|
|
|
|
<listitem><para>Check and edit the resulting <filename>local.conf</filename> file.
|
|
|
|
|
This file minimally identifies the machine for which to build the image by
|
|
|
|
|
configuring the <filename>MACHINE</filename> variable.
|
|
|
|
|
For this example you must set the variable to mymachine as follows:
|
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
|
MACHINE ??= “mymachine”
|
2011-07-27 14:03:00 +00:00
|
|
|
|
</literallayout>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
You should also be sure any other variables in which you are interested are set.
|
|
|
|
|
Some variables to consider are <filename>BB_NUMBER_THREADS</filename>
|
|
|
|
|
and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time
|
2011-11-16 17:42:53 +00:00
|
|
|
|
if your development system supports multiple cores.
|
|
|
|
|
For development systems that support multiple cores, a good rule of thumb is to set
|
|
|
|
|
both the <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
|
|
|
|
|
variables to twice the number of cores your system supports.</para></listitem>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes
|
2012-04-27 02:52:38 +00:00
|
|
|
|
both the path to your new BSP layer and the path to the
|
|
|
|
|
<filename>meta-intel</filename> layer.
|
|
|
|
|
In this example, you need to include both these paths as part of the
|
|
|
|
|
<filename>BBLAYERS</filename> variable:
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<literallayout class='monospaced'>
|
2012-04-27 02:52:38 +00:00
|
|
|
|
$HOME/poky/meta-intel
|
2011-07-27 14:55:55 +00:00
|
|
|
|
$HOME/poky/meta-intel/meta-mymachine
|
|
|
|
|
</literallayout></para></listitem>
|
|
|
|
|
</orderedlist>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
The appendix
|
2012-03-09 19:40:39 +00:00
|
|
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glos'>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information
|
|
|
|
|
on configuration variables.
|
|
|
|
|
</para>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
</section>
|
|
|
|
|
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<section id='building-the-image-app'>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
<title>Building and Booting the Image</title>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
2011-07-27 14:55:55 +00:00
|
|
|
|
<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.
|
|
|
|
|
For example, moving your working directory around could cause problems.
|
|
|
|
|
Here is the command for this example:
|
|
|
|
|
<literallayout class='monospaced'>
|
2011-10-03 18:41:12 +00:00
|
|
|
|
$ bitbake -k core-image-sato
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
</para>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
This command specifies an image that has Sato support and that can be run from a USB device or
|
|
|
|
|
from a CD without having to first install anything.
|
|
|
|
|
The build process takes significant time and includes thousands of tasks, which are reported
|
|
|
|
|
at the console.
|
|
|
|
|
If the build results in any type of error you should check for misspellings in the
|
|
|
|
|
files you changed or problems with your host development environment such as missing packages.
|
2011-07-27 14:03:00 +00:00
|
|
|
|
</para>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Finally, once you have an image, you can try booting it from a device
|
|
|
|
|
(e.g. a USB device).
|
|
|
|
|
To prepare a bootable USB device, insert a USB flash drive into your build system and
|
2011-11-04 21:22:05 +00:00
|
|
|
|
copy the <filename>.hddimg</filename> file, located in the
|
2011-11-03 17:58:14 +00:00
|
|
|
|
<filename>poky/build/tmp/deploy/images</filename>
|
|
|
|
|
directory after a successful build to the flash drive.
|
|
|
|
|
Assuming the USB flash drive takes device <filename>/dev/sdf</filename>,
|
|
|
|
|
use <filename>dd</filename> to copy the live image to it.
|
|
|
|
|
For example:
|
|
|
|
|
<literallayout class='monospaced'>
|
|
|
|
|
# dd if=core-image-sato-mymachine-20111101223904.hddimg of=/dev/sdf
|
|
|
|
|
# sync
|
|
|
|
|
# eject /dev/sdf
|
|
|
|
|
</literallayout>
|
|
|
|
|
You should now have a bootable USB flash device.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Insert the device
|
|
|
|
|
into a bootable USB socket on the target, and power it on.
|
|
|
|
|
The system should boot to the Sato graphical desktop.
|
2011-11-04 23:00:00 +00:00
|
|
|
|
<footnote><para>Because
|
|
|
|
|
this new image is not in any way tailored to the system you're
|
|
|
|
|
booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
|
|
|
|
|
example, it might not be completely functional though it should at least boot to a text
|
|
|
|
|
prompt.
|
|
|
|
|
Specifically, it might fail to boot into graphics without some tweaking.
|
|
|
|
|
If this ends up being the case, a possible next step would be to replace the
|
|
|
|
|
<filename>mymachine.conf</filename>
|
|
|
|
|
contents with the contents of <filename>atom-pc.conf</filename> and replace
|
|
|
|
|
<filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
|
|
|
|
|
in <filename>meta-yocto</filename> and see if it fares any better.
|
|
|
|
|
In any case, following the previous steps will give you a buildable image that
|
|
|
|
|
will probably boot on most systems.
|
|
|
|
|
Getting things working like you want
|
|
|
|
|
them to for your hardware will normally require some amount of experimentation with
|
|
|
|
|
configuration settings.</para></footnote>
|
2011-11-03 17:58:14 +00:00
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2012-04-23 20:41:10 +00:00
|
|
|
|
For reference, the sato image produced by the previous steps for &DISTRO_NAME;
|
2011-11-03 17:58:14 +00:00
|
|
|
|
should look like the following in terms of size.
|
|
|
|
|
If your sato image is much different from this,
|
|
|
|
|
you probably made a mistake in one of the above steps:
|
|
|
|
|
<literallayout class='monospaced'>
|
2012-04-27 11:40:29 +00:00
|
|
|
|
260538368 2012-04-27 01:44 core-image-sato-mymachine-20120427025051.hddimg
|
2011-11-03 17:58:14 +00:00
|
|
|
|
</literallayout>
|
|
|
|
|
<note>The previous instructions are also present in the README that was copied
|
|
|
|
|
from meta-crownbay, which should also be updated to reflect the specifics of your
|
|
|
|
|
new BSP.
|
|
|
|
|
That file and the <filename>README.hardware</filename> file in the top-level
|
|
|
|
|
<filename>poky</filename> directory
|
|
|
|
|
also provides some suggestions for things to try if booting fails and produces
|
|
|
|
|
strange error messages.</note>
|
|
|
|
|
</para>
|
2011-07-27 14:03:00 +00:00
|
|
|
|
</section>
|
2011-07-27 14:55:55 +00:00
|
|
|
|
</appendix>
|
|
|
|
|
|
2011-07-27 14:03:00 +00:00
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
vim: expandtab tw=80 ts=4
|
|
|
|
|
-->
|