mirror of
https://git.yoctoproject.org/poky
synced 2026-01-30 13:28:43 +01:00
Compare commits
16 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
dc8508f609 | ||
|
|
bf5dd36042 | ||
|
|
746c681be4 | ||
|
|
73aa36e3ee | ||
|
|
cddb7f10b8 | ||
|
|
399903724b | ||
|
|
e09163a08b | ||
|
|
2c0efd2f33 | ||
|
|
fb1df184b9 | ||
|
|
e127d017e1 | ||
|
|
0915ee7dc3 | ||
|
|
7c3cdf8a17 | ||
|
|
9ae4ab56e7 | ||
|
|
e40a8d739a | ||
|
|
5e0d6341ab | ||
|
|
41e74881b0 |
@@ -3621,6 +3621,106 @@
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='platdev-building-targets-with-multiple-configurations'>
|
||||
<title>Building Targets with Multiple Configurations</title>
|
||||
|
||||
<para>
|
||||
Bitbake also has functionality that allows you to build
|
||||
multiple targets at the same time, where each target uses
|
||||
a different configuration.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In order to accomplish this, you setup each of the configurations
|
||||
you need to use in parallel by placing the configuration files in
|
||||
your current build directory alongside the usual
|
||||
<filename>local.conf</filename> file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Follow these guidelines to create an environment that supports
|
||||
multiple configurations:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<emphasis>Create Configuration Files</emphasis>:
|
||||
You need to create a single configuration file for each
|
||||
configuration for which you want to add support.
|
||||
These files would contain lines such as the following:
|
||||
<literallayout class='monospaced'>
|
||||
MACHINE = "A"
|
||||
</literallayout>
|
||||
The files would contain any other variables that can
|
||||
be set and built in the same directory.
|
||||
<note>
|
||||
You can change the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>
|
||||
to not conflict.
|
||||
</note></para>
|
||||
|
||||
<para>
|
||||
Furthermore, the configuration file must be located in the
|
||||
current build directory in a directory named
|
||||
<filename>multiconfig</filename> under the build's
|
||||
<filename>conf</filename> directory where
|
||||
<filename>local.conf</filename> resides.
|
||||
The reason for this restriction is because the
|
||||
<filename>BBPATH</filename> variable is not constructed
|
||||
until the layers are parsed.
|
||||
Consequently, using the configuration file as a
|
||||
pre-configuration file is not possible unless it is
|
||||
located in the current working directory.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Add the BitBake Multi-Config Variable to you Local Configuration File</emphasis>:
|
||||
Use the
|
||||
<filename>BBMULTICONFIG</filename>
|
||||
variable in your <filename>conf/local.conf</filename>
|
||||
configuration file to specify each separate configuration.
|
||||
For example, the following line tells BitBake it should load
|
||||
<filename>conf/multiconfig/configA.conf</filename>,
|
||||
<filename>conf/multiconfig/configB.conf</filename>, and
|
||||
<filename>conf/multiconfig/configC.conf</filename>.
|
||||
<literallayout class='monospaced'>
|
||||
BBMULTICONFIG = "configA configB configC"
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<emphasis>Launch BitBake</emphasis>:
|
||||
Use the following BitBake command form to launch the
|
||||
build:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake [multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ]
|
||||
</literallayout>
|
||||
Following is an example that supports building a minimal
|
||||
image for configuration A alongside a standard
|
||||
<filename>core-image-sato</filename>, which takes its
|
||||
configuration from <filename>local.conf</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake multiconfig:configA:core-image-minimal core-image-sato
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Support for multiple configurations in this current release of
|
||||
the Yocto Project (&DISTRO_NAME; &DISTRO;) has some known issues:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
No inter-multi-configuration dependencies exist.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Shared State (sstate) optimizations do not exist.
|
||||
Consequently, if the build uses the same object twice
|
||||
in, for example, two different
|
||||
<filename>TMPDIR</filename> directories, the build
|
||||
will either load from an existing sstate cache at the
|
||||
start or build the object twice.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="platdev-working-with-libraries">
|
||||
<title>Working With Libraries</title>
|
||||
|
||||
|
||||
@@ -257,12 +257,6 @@
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>SDK Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
the standard or extensible SDK:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo apt-get install autoconf automake libtool libglib2.0-dev libarchive-dev
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
|
||||
Packages needed if you are going to run
|
||||
<filename>oe-selftest</filename>:
|
||||
@@ -301,12 +295,6 @@
|
||||
$ sudo dnf install make docbook-style-dsssl docbook-style-xsl \
|
||||
docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>SDK Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
standard or extensible SDK:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo dnf install autoconf automake libtool glib2-devel libarchive-devel
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
|
||||
Packages needed if you are going to run
|
||||
<filename>oe-selftest</filename>:
|
||||
@@ -344,12 +332,6 @@
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo zypper install make fop xsltproc dblatex xmlto
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>SDK Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
standard or extensible SDK:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo zypper install autoconf automake libtool glib2-devel libarchive-devel
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
|
||||
Packages needed if you are going to run
|
||||
<filename>oe-selftest</filename>:
|
||||
@@ -399,12 +381,6 @@
|
||||
$ sudo yum install make docbook-style-dsssl docbook-style-xsl \
|
||||
docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>SDK Installer Extras:</emphasis>
|
||||
Packages needed if you are going to be using the
|
||||
standard or extensible SDK:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo yum install autoconf automake libtool glib2-devel libarchive-devel
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
|
||||
Packages needed if you are going to run
|
||||
<filename>oe-selftest</filename>:
|
||||
|
||||
@@ -3392,10 +3392,6 @@
|
||||
|
||||
<para>
|
||||
The following changes for Python occurred:
|
||||
<note>
|
||||
Python 2 and recipes that use it can still be built for the
|
||||
target as with previous versions.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<section id='migration-2.2-bitbake-now-requires-python-3.4'>
|
||||
@@ -3443,6 +3439,10 @@
|
||||
Unfortunately, systems using RPM as a package manager and
|
||||
providing online package-manager support through SMART still
|
||||
require Python 2.
|
||||
<note>
|
||||
Python 2 and recipes that use it can still be built for the
|
||||
target as with previous versions.
|
||||
</note>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
@@ -3489,23 +3489,26 @@
|
||||
<para>
|
||||
<filename>runqemu</filename> has been ported to Python and has
|
||||
changed behavior in some cases.
|
||||
Previous usage patterns continued to be supported.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The new <filename>runqemu</filename> is a Python script.
|
||||
The script requires a configuration file in the following
|
||||
form in order to boot the BSP:
|
||||
Machine knowledge is no longer hardcoded into
|
||||
<filename>runqemu</filename>.
|
||||
You can choose to use the <filename>qemuboot</filename>
|
||||
configuration file to define the BSP's own arguments and to make
|
||||
it bootable with <filename>runqemu</filename>.
|
||||
If you use a configuration file, use the following form:
|
||||
<literallayout class='monospaced'>
|
||||
<replaceable>image-name</replaceable>-<replaceable>machine</replaceable>.qemuboot.conf
|
||||
</literallayout>
|
||||
Machine knowledge is no longer hardcoded into
|
||||
<filename>runqemu</filename>.
|
||||
You can use the <filename>qemuboot</filename> configuration file
|
||||
to define the BSP's own arguments and to make it bootable
|
||||
with <filename>runqemu</filename>.
|
||||
<note>
|
||||
Previous usage patterns are continued to be supported.
|
||||
</note>
|
||||
The configuration file enables fine-grained tuning of options
|
||||
passed to QEMU without the <filename>runqemu</filename> script
|
||||
hard-coding any knowledge about different machines.
|
||||
Using a configuration file is particularly convenient when trying
|
||||
to use QEMU with machines other than the
|
||||
<filename>qemu*</filename> machines in OE-Core.
|
||||
The <filename>qemuboot.conf</filename> file is generated by the
|
||||
<filename>qemuboot</filename>
|
||||
class when the root filesystem is being build (i.e.
|
||||
@@ -3515,6 +3518,34 @@
|
||||
<filename>qemuboot.conf</filename>.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
If you want to use <filename>runqemu</filename> without a
|
||||
configuration file, use the following command form:
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu <replaceable>machine</replaceable> <replaceable>rootfs</replaceable> <replaceable>kernel</replaceable> [<replaceable>options</replaceable>]
|
||||
</literallayout>
|
||||
Supported <replaceable>machines</replaceable> are as follows:
|
||||
<literallayout class='monospaced'>
|
||||
qemuarm
|
||||
qemuarm64
|
||||
qemux86
|
||||
qemux86-64
|
||||
qemuppc
|
||||
qemumips
|
||||
qemumips64
|
||||
qemumipsel
|
||||
qemumips64el
|
||||
</literallayout>
|
||||
Consider the following example, which uses the
|
||||
<filename>qemux86-64</filename> machine,
|
||||
provides a root filesystem, provides an image, and uses
|
||||
the <filename>nographic</filename> option:
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Following is a list of variables that can be set in configuration
|
||||
files such as <filename>bsp.conf</filename> to enable the BSP
|
||||
@@ -3579,8 +3610,8 @@
|
||||
binary" QA issues when building such recipes.
|
||||
You need to fix these recipes so that they use the expected
|
||||
<filename>LDFLAGS</filename>.
|
||||
Depending on how the software is built, the build system might
|
||||
need to be patched.
|
||||
Depending on how the software is built, the build system used by
|
||||
the software (e.g. a Makefile) might need to be patched.
|
||||
However, sometimes making this fix is as simple as adding the
|
||||
following to the recipe:
|
||||
<literallayout class='monospaced'>
|
||||
|
||||
@@ -1225,6 +1225,42 @@
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm>
|
||||
<info>
|
||||
BBMULTICONFIG[doc] = "Specifies each separate configuration when you are building targets with multiple configurations."
|
||||
</info>
|
||||
<glossdef>
|
||||
<para role="glossdeffirst">
|
||||
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
|
||||
Specifies each separate configuration when you are
|
||||
building targets with multiple configurations.
|
||||
Use this variable in your
|
||||
<filename>conf/local.conf</filename> configuration file.
|
||||
Specify a <replaceable>multiconfigname</replaceable> for
|
||||
each configuration file you are using.
|
||||
For example, the following line specifies three
|
||||
configuration files:
|
||||
<literallayout class='monospaced'>
|
||||
BBMULTIFONFIG = "configA configB configC"
|
||||
</literallayout>
|
||||
Each configuration file you use must reside in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory's</ulink>
|
||||
<filename>conf/multiconfig</filename> directory
|
||||
(e.g.
|
||||
<replaceable>build_directory</replaceable><filename>/conf/multiconfig/configA.conf</filename>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For information on how to use
|
||||
<filename>BBMULTICONFIG</filename> in an environment that
|
||||
supports building targets with multiple configurations,
|
||||
see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-building-targets-with-multiple-configurations'>Building Targets with Multiple Configurations</ulink>"
|
||||
section in the Yocto Project Development Manual.
|
||||
</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
|
||||
<info>
|
||||
BBPATH[doc] = "Used by BitBake to locate .bbclass and configuration files. This variable is analogous to the PATH variable."
|
||||
|
||||
@@ -390,8 +390,8 @@
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can try out the Yocto Project using the command-line interface
|
||||
by finishing this quick start, which presents steps that let you
|
||||
To use the Yocto Project through the command-line interface,
|
||||
finish this quick start, which presents steps that let you
|
||||
do the following:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
@@ -400,230 +400,239 @@
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Easily change configurations so that you can quickly
|
||||
create a second image, which would be for MinnowBoard
|
||||
create a second image that you can load onto bootable
|
||||
media and actually boot target hardware.
|
||||
This example uses the MinnowBoard
|
||||
MAX-compatible boards.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
<note>
|
||||
The steps in this section do not provide detail, but rather
|
||||
provide minimal, working commands and examples designed to
|
||||
just get you started.
|
||||
The steps in the following two sections do not provide detail,
|
||||
but rather provide minimal, working commands and examples
|
||||
designed to just get you started.
|
||||
For more details, see the appropriate manuals in the
|
||||
<ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project manual set</ulink>.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Use the following commands to build your image.
|
||||
The OpenEmbedded build system creates an entire Linux
|
||||
distribution, including the toolchain, from source.
|
||||
<note><title>Note about Network Proxies</title>
|
||||
<para>
|
||||
By default, the build process searches for source code
|
||||
using a pre-determined order through a set of
|
||||
locations.
|
||||
If you are working behind a firewall and your build
|
||||
host is not set up for proxies, you could encounter
|
||||
problems with the build process when fetching source
|
||||
code (e.g. fetcher failures or Git failures).
|
||||
</para>
|
||||
<section id='building-an-image-for-emulation'>
|
||||
<title>Building an Image for Emulation</title>
|
||||
|
||||
<para>
|
||||
If you do not know your proxy settings, consult your
|
||||
local network infrastructure resources and get that
|
||||
information.
|
||||
A good starting point could also be to check your web
|
||||
browser settings.
|
||||
Finally, you can find more information on using the
|
||||
Yocto Project behind a firewall in the Yocto Project
|
||||
Reference Manual
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</ulink>
|
||||
and on the
|
||||
"<ulink url='https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
|
||||
wiki page.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
<para>
|
||||
Use the following commands to build your image.
|
||||
The OpenEmbedded build system creates an entire Linux
|
||||
distribution, including the toolchain, from source.
|
||||
<note><title>Note about Network Proxies</title>
|
||||
<para>
|
||||
By default, the build process searches for source code
|
||||
using a pre-determined order through a set of
|
||||
locations.
|
||||
If you are working behind a firewall and your build
|
||||
host is not set up for proxies, you could encounter
|
||||
problems with the build process when fetching source
|
||||
code (e.g. fetcher failures or Git failures).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Be Sure Your Build Host is Set Up:</emphasis>
|
||||
The steps to build an image in this section depend on
|
||||
your build host being properly set up.
|
||||
Be sure you have worked through the requirements
|
||||
described in the
|
||||
"<link linkend='yp-resources'>Setting Up to Use the Yocto Project</link>"
|
||||
section.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Check Out Your Branch:</emphasis>
|
||||
Be sure you are in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
(e.g. <filename>poky</filename>) and then check out
|
||||
the branch associated with the latest Yocto Project
|
||||
Release:
|
||||
<literallayout class='monospaced'>
|
||||
<para>
|
||||
If you do not know your proxy settings, consult your
|
||||
local network infrastructure resources and get that
|
||||
information.
|
||||
A good starting point could also be to check your web
|
||||
browser settings.
|
||||
Finally, you can find more information on using the
|
||||
Yocto Project behind a firewall in the Yocto Project
|
||||
Reference Manual
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</ulink>
|
||||
and on the
|
||||
"<ulink url='https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
|
||||
wiki page.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Be Sure Your Build Host is Set Up:</emphasis>
|
||||
The steps to build an image in this section depend on
|
||||
your build host being properly set up.
|
||||
Be sure you have worked through the requirements
|
||||
described in the
|
||||
"<link linkend='yp-resources'>Setting Up to Use the Yocto Project</link>"
|
||||
section.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Check Out Your Branch:</emphasis>
|
||||
Be sure you are in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
|
||||
(e.g. <filename>poky</filename>) and then check out
|
||||
the branch associated with the latest Yocto Project
|
||||
Release:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky
|
||||
$ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
|
||||
</literallayout>
|
||||
Git's <filename>checkout</filename> command checks out
|
||||
the current Yocto Project release into a local branch
|
||||
whose name matches the release (i.e.
|
||||
<filename>&DISTRO_NAME_NO_CAP;</filename>).
|
||||
The local branch tracks the upstream branch of the
|
||||
same name.
|
||||
Creating your own branch based on the released
|
||||
branch ensures you are using the latest files for
|
||||
that release.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Initialize the Build Environment:</emphasis>
|
||||
Run the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
|
||||
environment setup script to define the OpenEmbedded
|
||||
build environment on your build host.
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
Git's <filename>checkout</filename> command checks out
|
||||
the current Yocto Project release into a local branch
|
||||
whose name matches the release (i.e.
|
||||
<filename>&DISTRO_NAME_NO_CAP;</filename>).
|
||||
The local branch tracks the upstream branch of the
|
||||
same name.
|
||||
Creating your own branch based on the released
|
||||
branch ensures you are using the latest files for
|
||||
that release.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Initialize the Build Environment:</emphasis>
|
||||
Run the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
|
||||
environment setup script to define the OpenEmbedded
|
||||
build environment on your build host.
|
||||
<literallayout class='monospaced'>
|
||||
$ source &OE_INIT_FILE;
|
||||
</literallayout>
|
||||
Among other things, the script creates the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
|
||||
which is <filename>build</filename> in this case
|
||||
and is located in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
After the script runs, your current working directory
|
||||
is set to the Build Directory.
|
||||
Later, when the build completes, the Build Directory
|
||||
contains all the files created during the build.
|
||||
<note>
|
||||
For information on running a memory-resident
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>,
|
||||
see the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>
|
||||
setup script.
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Examine Your Local Configuration File:</emphasis>
|
||||
When you set up the build environment, a local
|
||||
configuration file named
|
||||
<filename>local.conf</filename> becomes available in
|
||||
a <filename>conf</filename> subdirectory of the
|
||||
Build Directory.
|
||||
Before using BitBake to start the build, you can
|
||||
look at this file and be sure your general
|
||||
configurations are how you want them:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
To help conserve disk space during builds,
|
||||
you can add the following statement to your
|
||||
project's configuration file, which for this
|
||||
example is
|
||||
<filename>poky/build/conf/local.conf</filename>.
|
||||
Adding this statement deletes the work
|
||||
directory used for building a recipe once the
|
||||
recipe is built.
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
Among other things, the script creates the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
|
||||
which is <filename>build</filename> in this case
|
||||
and is located in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
After the script runs, your current working directory
|
||||
is set to the Build Directory.
|
||||
Later, when the build completes, the Build Directory
|
||||
contains all the files created during the build.
|
||||
<note>
|
||||
For information on running a memory-resident
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>,
|
||||
see the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>
|
||||
setup script.
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Examine Your Local Configuration File:</emphasis>
|
||||
When you set up the build environment, a local
|
||||
configuration file named
|
||||
<filename>local.conf</filename> becomes available in
|
||||
a <filename>conf</filename> subdirectory of the
|
||||
Build Directory.
|
||||
Before using BitBake to start the build, you can
|
||||
look at this file and be sure your general
|
||||
configurations are how you want them:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
To help conserve disk space during builds,
|
||||
you can add the following statement to your
|
||||
project's configuration file, which for this
|
||||
example is
|
||||
<filename>poky/build/conf/local.conf</filename>.
|
||||
Adding this statement deletes the work
|
||||
directory used for building a recipe once the
|
||||
recipe is built.
|
||||
<literallayout class='monospaced'>
|
||||
INHERIT += "rm_work"
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
By default, the target machine for the build is
|
||||
<filename>qemux86</filename>,
|
||||
which produces an image that can be used in
|
||||
the QEMU emulator and is targeted at an
|
||||
<trademark class='registered'>Intel</trademark>
|
||||
32-bit based architecture.
|
||||
Further on in this example, this default is
|
||||
easily changed through the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
variable so that you can quickly
|
||||
build an image for a different machine.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Another consideration before you build is the
|
||||
package manager used when creating the image.
|
||||
The default <filename>local.conf</filename>
|
||||
file selects the RPM package manager.
|
||||
You can control this configuration by using the
|
||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename>
|
||||
variable.</para>
|
||||
<para>Selection of the package manager is separate
|
||||
from whether package management is used at runtime
|
||||
in the target image.</para>
|
||||
<para>For additional package manager selection
|
||||
information, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package.bbclass</filename></ulink>"
|
||||
section in the Yocto Project Reference Manual.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Start the Build:</emphasis>
|
||||
Continue with the following command to build an OS image
|
||||
for the target, which is
|
||||
<filename>core-image-sato</filename> in this example:
|
||||
<note>
|
||||
Depending on the number of processors and cores, the
|
||||
amount of RAM, the speed of your Internet connection
|
||||
and other factors, the build process could take several
|
||||
hours the first time you run it.
|
||||
Subsequent builds run much faster since parts of the
|
||||
build are cached.
|
||||
</note>
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
By default, the target machine for the build is
|
||||
<filename>qemux86</filename>,
|
||||
which produces an image that can be used in
|
||||
the QEMU emulator and is targeted at an
|
||||
<trademark class='registered'>Intel</trademark>
|
||||
32-bit based architecture.
|
||||
Further on in this example, this default is
|
||||
easily changed through the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
variable so that you can quickly
|
||||
build an image for a different machine.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
Another consideration before you build is the
|
||||
package manager used when creating the image.
|
||||
The default <filename>local.conf</filename>
|
||||
file selects the RPM package manager.
|
||||
You can control this configuration by using the
|
||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename>
|
||||
variable.</para>
|
||||
<para>Selection of the package manager is separate
|
||||
from whether package management is used at runtime
|
||||
in the target image.</para>
|
||||
<para>For additional package manager selection
|
||||
information, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package.bbclass</filename></ulink>"
|
||||
section in the Yocto Project Reference Manual.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Start the Build:</emphasis>
|
||||
Continue with the following command to build an OS image
|
||||
for the target, which is
|
||||
<filename>core-image-sato</filename> in this example:
|
||||
<note>
|
||||
Depending on the number of processors and cores, the
|
||||
amount of RAM, the speed of your Internet connection
|
||||
and other factors, the build process could take several
|
||||
hours the first time you run it.
|
||||
Subsequent builds run much faster since parts of the
|
||||
build are cached.
|
||||
</note>
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake core-image-sato
|
||||
</literallayout>
|
||||
For information on using the
|
||||
<filename>bitbake</filename> command, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
|
||||
section in the Yocto Project Reference Manual, or see the
|
||||
"<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
|
||||
section in the BitBake User Manual.
|
||||
For information on other targets, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
|
||||
chapter in the Yocto Project Reference Manual.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Simulate Your Image Using QEMU:</emphasis>
|
||||
Once this particular image is built, you can start QEMU
|
||||
and run the image:
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
For information on using the
|
||||
<filename>bitbake</filename> command, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
|
||||
section in the Yocto Project Reference Manual, or see the
|
||||
"<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
|
||||
section in the BitBake User Manual.
|
||||
For information on other targets, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
|
||||
chapter in the Yocto Project Reference Manual.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Simulate Your Image Using QEMU:</emphasis>
|
||||
Once this particular image is built, you can start QEMU
|
||||
and run the image:
|
||||
<literallayout class='monospaced'>
|
||||
$ runqemu qemux86
|
||||
</literallayout>
|
||||
If you want to learn more about running QEMU, see the
|
||||
"<ulink url="&YOCTO_DOCS_DEV_URL;#dev-manual-qemu">Using the Quick EMUlator (QEMU)</ulink>"
|
||||
chapter in the Yocto Project Development Manual.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Exit QEMU:</emphasis>
|
||||
Exit QEMU by either clicking on the shutdown icon or by
|
||||
opening a terminal, typing
|
||||
<filename>poweroff</filename>, and then pressing "Enter".
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</literallayout>
|
||||
If you want to learn more about running QEMU, see the
|
||||
"<ulink url="&YOCTO_DOCS_DEV_URL;#dev-manual-qemu">Using the Quick EMUlator (QEMU)</ulink>"
|
||||
chapter in the Yocto Project Development Manual.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Exit QEMU:</emphasis>
|
||||
Exit QEMU by either clicking on the shutdown icon or by
|
||||
opening a terminal, typing
|
||||
<filename>poweroff</filename>, and then pressing "Enter".
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<para id='qs-minnowboard-example'>
|
||||
The following steps show how easy it is to set up to build an
|
||||
image for a new machine.
|
||||
These steps build an image for the MinnowBoard MAX, which is
|
||||
supported by the Yocto Project and the
|
||||
<filename>meta-intel</filename> <filename>intel-corei7-64</filename>
|
||||
and <filename>intel-core2-32</filename> Board Support Packages
|
||||
(BSPs).
|
||||
<note>
|
||||
The MinnowBoard MAX ships with 64-bit firmware.
|
||||
If you want to use the board in 32-bit mode, you must
|
||||
download the
|
||||
<ulink url='http://firmware.intel.com/projects/minnowboard-max'>32-bit firmware</ulink>.
|
||||
</note>
|
||||
</para>
|
||||
<section id='building-an-image-for-hardware'>
|
||||
<title>Building an Image for Hardware</title>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Create a Local Copy of the
|
||||
<filename>meta-intel</filename> Repository:</emphasis>
|
||||
Building an image for the MinnowBoard MAX requires the
|
||||
<filename>meta-intel</filename> layer.
|
||||
Use the <filename>git clone</filename> command to create
|
||||
a local copy of the repository inside your
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
|
||||
which is <filename>poky</filename> in this example:
|
||||
<literallayout class='monospaced'>
|
||||
<para id='qs-minnowboard-example'>
|
||||
The following steps show how easy it is to set up to build an
|
||||
image for a new machine.
|
||||
These steps build an image for the MinnowBoard MAX, which is
|
||||
supported by the Yocto Project and the
|
||||
<filename>meta-intel</filename> <filename>intel-corei7-64</filename>
|
||||
and <filename>intel-core2-32</filename> Board Support Packages
|
||||
(BSPs).
|
||||
<note>
|
||||
The MinnowBoard MAX ships with 64-bit firmware.
|
||||
If you want to use the board in 32-bit mode, you must
|
||||
download the
|
||||
<ulink url='http://firmware.intel.com/projects/minnowboard-max'>32-bit firmware</ulink>.
|
||||
</note>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Create a Local Copy of the
|
||||
<filename>meta-intel</filename> Repository:</emphasis>
|
||||
Building an image for the MinnowBoard MAX requires the
|
||||
<filename>meta-intel</filename> layer.
|
||||
Use the <filename>git clone</filename> command to create
|
||||
a local copy of the repository inside your
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
|
||||
which is <filename>poky</filename> in this example:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd $HOME/poky
|
||||
$ git clone git://git.yoctoproject.org/meta-intel
|
||||
Cloning into 'meta-intel'...
|
||||
@@ -633,137 +642,133 @@
|
||||
remote: Total 11988 (delta 6881), reused 11752 (delta 6645)
|
||||
Resolving deltas: 100% (6881/6881), done.
|
||||
Checking connectivity... done.
|
||||
</literallayout>
|
||||
By default when you clone a Git repository, the
|
||||
"master" branch is checked out.
|
||||
Before you build your image that uses the
|
||||
<filename>meta-intel</filename> layer, you must be
|
||||
sure that both repositories
|
||||
(<filename>meta-intel</filename> and
|
||||
<filename>poky</filename>) are using the same releases.
|
||||
Consequently, you need to checkout out the
|
||||
"<filename>&DISTRO_NAME_NO_CAP;</filename>" release after
|
||||
cloning <filename>meta-intel</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
By default when you clone a Git repository, the
|
||||
"master" branch is checked out.
|
||||
Before you build your image that uses the
|
||||
<filename>meta-intel</filename> layer, you must be
|
||||
sure that both repositories
|
||||
(<filename>meta-intel</filename> and
|
||||
<filename>poky</filename>) are using the same releases.
|
||||
Consequently, you need to checkout out the
|
||||
"<filename>&DISTRO_NAME_NO_CAP;</filename>" release after
|
||||
cloning <filename>meta-intel</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd $HOME/poky/meta-intel
|
||||
$ git checkout &DISTRO_NAME_NO_CAP;
|
||||
Branch &DISTRO_NAME_NO_CAP; set up to track remote branch &DISTRO_NAME_NO_CAP; from origin.
|
||||
Switched to a new branch '&DISTRO_NAME_NO_CAP;'
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Configure the Build:</emphasis>
|
||||
To configure the build, you edit the
|
||||
<filename>bblayers.conf</filename> and
|
||||
<filename>local.conf</filename> files, both of which are
|
||||
located in the <filename>build/conf</filename> directory.
|
||||
</para>
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Configure the Build:</emphasis>
|
||||
To configure the build, you edit the
|
||||
<filename>bblayers.conf</filename> and
|
||||
<filename>local.conf</filename> files, both of which are
|
||||
located in the <filename>build/conf</filename> directory.
|
||||
</para>
|
||||
|
||||
<para>Here is a quick way to make the edits.
|
||||
The first command uses the
|
||||
<filename>bitbake-layers add-layer</filename> command
|
||||
to add the <filename>meta-intel</filename>
|
||||
layer, which contains the <filename>intel-core*</filename>
|
||||
BSPs to the build.
|
||||
The second command selects the BSP by setting the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
variable.
|
||||
<literallayout class='monospaced'>
|
||||
<para>Here is a quick way to make the edits.
|
||||
The first command uses the
|
||||
<filename>bitbake-layers add-layer</filename> command
|
||||
to add the <filename>meta-intel</filename>
|
||||
layer, which contains the <filename>intel-core*</filename>
|
||||
BSPs to the build.
|
||||
The second command selects the BSP by setting the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
|
||||
variable.
|
||||
<literallayout class='monospaced'>
|
||||
$ cd $HOME/poky/build
|
||||
$ bitbake-layers add-layer "$HOME/poky/meta-intel"
|
||||
$ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
|
||||
</literallayout>
|
||||
<note><title>Notes</title>
|
||||
<para>
|
||||
If you want a 64-bit build, use the following:
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
<note><title>Notes</title>
|
||||
<para>
|
||||
If you want a 64-bit build, use the following:
|
||||
<literallayout class='monospaced'>
|
||||
$ echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf
|
||||
</literallayout>
|
||||
</para>
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you want 32-bit images, use the following:
|
||||
<literallayout class='monospaced'>
|
||||
<para>
|
||||
If you want 32-bit images, use the following:
|
||||
<literallayout class='monospaced'>
|
||||
$ echo 'MACHINE = "intel-core2-32"' >> conf/local.conf
|
||||
</literallayout>
|
||||
</para>
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Build an Image for MinnowBoard MAX:</emphasis>
|
||||
The type of image you build depends on your goals.
|
||||
For example, the previous build created a
|
||||
<filename>core-image-sato</filename> image, which is an
|
||||
image with Sato support.
|
||||
It is possible to build many image types for the
|
||||
MinnowBoard MAX.
|
||||
Some possibilities are <filename>core-image-base</filename>,
|
||||
which is a console-only image.
|
||||
Another choice could be a
|
||||
<filename>core-image-full-cmdline</filename>, which is
|
||||
another console-only image but has more full-features
|
||||
Linux system functionality installed.
|
||||
For types of images you can build using the Yocto
|
||||
Project, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
|
||||
chapter in the Yocto Project Reference Manual.</para>
|
||||
<para>Because configuration changes are minimal to set up
|
||||
for this second build, the OpenEmbedded build system can
|
||||
re-use files from previous builds as much as possible.
|
||||
Re-using files means this second build will be much faster
|
||||
than an initial build.
|
||||
For this example, the <filename>core-image-base</filename>
|
||||
image is built:
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
</para>
|
||||
</note>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Build an Image for MinnowBoard MAX:</emphasis>
|
||||
The type of image you build depends on your goals.
|
||||
For example, the previous build created a
|
||||
<filename>core-image-sato</filename> image, which is an
|
||||
image with Sato support.
|
||||
It is possible to build many image types for the
|
||||
MinnowBoard MAX.
|
||||
Some possibilities are <filename>core-image-base</filename>,
|
||||
which is a console-only image.
|
||||
Another choice could be a
|
||||
<filename>core-image-full-cmdline</filename>, which is
|
||||
another console-only image but has more full-features
|
||||
Linux system functionality installed.
|
||||
For types of images you can build using the Yocto
|
||||
Project, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
|
||||
chapter in the Yocto Project Reference Manual.</para>
|
||||
<para>Because configuration changes are minimal to set up
|
||||
for this second build, the OpenEmbedded build system can
|
||||
re-use files from previous builds as much as possible.
|
||||
Re-using files means this second build will be much faster
|
||||
than an initial build.
|
||||
For this example, the <filename>core-image-base</filename>
|
||||
image is built:
|
||||
<literallayout class='monospaced'>
|
||||
$ bitbake core-image-base
|
||||
</literallayout>
|
||||
Once the build completes, the resulting console-only image
|
||||
is located in the Build Directory here:
|
||||
<literallayout class='monospaced'>
|
||||
</literallayout>
|
||||
Once the build completes, the resulting console-only image
|
||||
is located in the Build Directory here:
|
||||
<literallayout class='monospaced'>
|
||||
tmp/deploy/images/intel-corei7-64/core-image-base-intel-corei7-64.hddimg
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Write the Image:</emphasis>
|
||||
You can write the image to a USB key, SATA drive, or SD
|
||||
card by using the <filename>mkefidisk.sh</filename> script,
|
||||
which is included in the <filename>poky</filename>
|
||||
repository at
|
||||
<filename>scripts/contrib/mkefidisk.sh</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo $HOME/source/poky/scripts/contrib/mkefidisk.sh <replaceable>HOST_DEVICE</replaceable> \
|
||||
tmp/deploy/images/intel-corei7-64/core-image-base-intel-corei7-64.hddimg <replaceable>TARGET_DEVICE</replaceable>
|
||||
</literallayout>
|
||||
In the previous command,
|
||||
<replaceable>HOST_DEVICE</replaceable> is the device node
|
||||
on the build host (e.g. <filename>/dev/sdc</filename> or
|
||||
<filename>/dev/mmcblk0</filename>).
|
||||
<replaceable>TARGET_DEVICE</replaceable> is the name of the
|
||||
device as the MinnowBoard MAX sees it (e.g.
|
||||
<filename>/dev/sda</filename> or
|
||||
<filename>/dev/mmcblk0</filename>).
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Boot the Hardware:</emphasis>
|
||||
With the boot device provisioned, you can insert the
|
||||
media into the MinnowBoard MAX and boot the hardware.
|
||||
The board should automatically detect the media and boot to
|
||||
the bootloader and subsequently the operating system.
|
||||
</para>
|
||||
</literallayout>
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Write the Image:</emphasis>
|
||||
You can write the image just built to a bootable media
|
||||
(e.g. a USB key, SATA drive, SD card, etc.) using the
|
||||
<filename>dd</filename> utility:
|
||||
<literallayout class='monospaced'>
|
||||
$ sudo dd if=tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.wic of=TARGET_DEVICE
|
||||
</literallayout>
|
||||
In the previous command, the
|
||||
<filename>TARGET_DEVICE</filename> is the device node in
|
||||
the host machine (e.g. <filename>/dev/sdc</filename>, which
|
||||
is most likely a USB stick, or
|
||||
<filename>/dev/mmcblk0</filename>, which is most likely an
|
||||
SD card.
|
||||
</para></listitem>
|
||||
<listitem><para><emphasis>Boot the Hardware:</emphasis>
|
||||
With the boot device provisioned, you can insert the
|
||||
media into the MinnowBoard MAX and boot the hardware.
|
||||
The board should automatically detect the media and boot to
|
||||
the bootloader and subsequently the operating system.
|
||||
</para>
|
||||
|
||||
<para>If the board does not boot automatically, you can
|
||||
boot it manually from the EFI shell as follows:
|
||||
<literallayout class='monospaced'>
|
||||
<para>If the board does not boot automatically, you can
|
||||
boot it manually from the EFI shell as follows:
|
||||
<literallayout class='monospaced'>
|
||||
Shell> connect -r
|
||||
Shell> map -r
|
||||
Shell> fs0:
|
||||
Shell> bootx64
|
||||
</literallayout>
|
||||
<note>
|
||||
For a 32-bit image use the following:
|
||||
<literallayout class='monospaced'>
|
||||
Shell> bootia32
|
||||
</literallayout>
|
||||
</note>
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
<note>
|
||||
For a 32-bit image use the following:
|
||||
<literallayout class='monospaced'>
|
||||
Shell> bootia32
|
||||
</literallayout>
|
||||
</note>
|
||||
</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id='qs-next-steps'>
|
||||
|
||||
@@ -7,11 +7,11 @@ KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
|
||||
KMACHINE_genericx86 ?= "common-pc"
|
||||
KMACHINE_genericx86-64 ?= "common-pc-64"
|
||||
|
||||
SRCREV_machine_genericx86 ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
|
||||
SRCREV_machine_genericx86-64 ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
|
||||
SRCREV_machine_edgerouter ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
|
||||
SRCREV_machine_beaglebone ?= "3e064525c427e128d08ea599ea3247e2963b54a5"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
|
||||
SRCREV_machine_genericx86 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
|
||||
SRCREV_machine_genericx86-64 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
|
||||
SRCREV_machine_edgerouter ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
|
||||
SRCREV_machine_beaglebone ?= "12532e753b50997690923e03edb3ac3368817a26"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
|
||||
|
||||
COMPATIBLE_MACHINE_genericx86 = "genericx86"
|
||||
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
|
||||
|
||||
@@ -7,11 +7,11 @@ KBRANCH_edgerouter = "standard/edgerouter"
|
||||
KBRANCH_beaglebone = "standard/beaglebone"
|
||||
KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
|
||||
|
||||
SRCREV_machine_genericx86 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
|
||||
SRCREV_machine_genericx86-64 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
|
||||
SRCREV_machine_edgerouter ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
|
||||
SRCREV_machine_beaglebone ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "50e000bc5fce1e04a1a3aea5ffc57c3d5fd71e72"
|
||||
SRCREV_machine_genericx86 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
|
||||
SRCREV_machine_genericx86-64 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
|
||||
SRCREV_machine_edgerouter ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
|
||||
SRCREV_machine_beaglebone ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "7fa42ad9a43ca4bb1e578e208ffeddae2d6150e2"
|
||||
|
||||
COMPATIBLE_MACHINE_genericx86 = "genericx86"
|
||||
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
|
||||
@@ -19,8 +19,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
|
||||
COMPATIBLE_MACHINE_beaglebone = "beaglebone"
|
||||
COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
|
||||
|
||||
LINUX_VERSION_genericx86 = "4.4.22"
|
||||
LINUX_VERSION_genericx86-64 = "4.4.22"
|
||||
LINUX_VERSION_edgerouter = "4.4.22"
|
||||
LINUX_VERSION_beaglebone = "4.4.22"
|
||||
LINUX_VERSION_mpc8315e-rdb = "4.4.22"
|
||||
LINUX_VERSION_genericx86 = "4.4.26"
|
||||
LINUX_VERSION_genericx86-64 = "4.4.26"
|
||||
LINUX_VERSION_edgerouter = "4.4.26"
|
||||
LINUX_VERSION_beaglebone = "4.4.26"
|
||||
LINUX_VERSION_mpc8315e-rdb = "4.4.26"
|
||||
|
||||
@@ -7,11 +7,11 @@ KBRANCH_edgerouter = "standard/edgerouter"
|
||||
KBRANCH_beaglebone = "standard/beaglebone"
|
||||
KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
|
||||
|
||||
SRCREV_machine_genericx86 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
|
||||
SRCREV_machine_genericx86-64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
|
||||
SRCREV_machine_edgerouter ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
|
||||
SRCREV_machine_beaglebone ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "4c9e17100b1f8ce45a60ad8984c12b00febbc685"
|
||||
SRCREV_machine_genericx86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_machine_genericx86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_machine_edgerouter ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_machine_beaglebone ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_machine_mpc8315e-rdb ?= "4be88b03f6648004e74b68044fa2b05e81cf9a1b"
|
||||
|
||||
COMPATIBLE_MACHINE_genericx86 = "genericx86"
|
||||
COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
|
||||
@@ -19,8 +19,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
|
||||
COMPATIBLE_MACHINE_beaglebone = "beaglebone"
|
||||
COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
|
||||
|
||||
LINUX_VERSION_genericx86 = "4.8"
|
||||
LINUX_VERSION_genericx86-64 = "4.8"
|
||||
LINUX_VERSION_edgerouter = "4.8"
|
||||
LINUX_VERSION_beaglebone = "4.8"
|
||||
LINUX_VERSION_mpc8315e-rdb = "4.8"
|
||||
LINUX_VERSION_genericx86 = "4.8.3"
|
||||
LINUX_VERSION_genericx86-64 = "4.8.3"
|
||||
LINUX_VERSION_edgerouter = "4.8.3"
|
||||
LINUX_VERSION_beaglebone = "4.8.3"
|
||||
LINUX_VERSION_mpc8315e-rdb = "4.8.3"
|
||||
|
||||
@@ -184,7 +184,7 @@ IMAGE_CMD_ubi () {
|
||||
|
||||
IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.ubifs ${MKUBIFS_ARGS}"
|
||||
|
||||
WKS_FILE ?= "${IMAGE_BASENAME}.${MACHINE}.wks"
|
||||
WKS_FILE ??= "${IMAGE_BASENAME}.${MACHINE}.wks"
|
||||
WKS_FILES ?= "${WKS_FILE} ${IMAGE_BASENAME}.wks"
|
||||
WKS_SEARCH_PATH ?= "${THISDIR}:${@':'.join('%s/scripts/lib/wic/canned-wks' % l for l in '${BBPATH}:${COREBASE}'.split(':'))}"
|
||||
WKS_FULL_PATH = "${@wks_search('${WKS_FILES}'.split(), '${WKS_SEARCH_PATH}') or ''}"
|
||||
|
||||
@@ -22,8 +22,8 @@ IMAGE_FSTYPES = "vmdk"
|
||||
|
||||
inherit core-image module-base
|
||||
|
||||
SRCREV ?= "4b94b498e21aeba945fe7e72a6b7c4bb0314fb83"
|
||||
SRC_URI = "git://git.yoctoproject.org/poky;branch=master \
|
||||
SRCREV ?= "746c681be4c744d0c6c2d3225b94550241546f65"
|
||||
SRC_URI = "git://git.yoctoproject.org/poky;branch=morty \
|
||||
file://Yocto_Build_Appliance.vmx \
|
||||
file://Yocto_Build_Appliance.vmxf \
|
||||
file://README_VirtualBox_Guest_Additions.txt \
|
||||
|
||||
@@ -11,8 +11,8 @@ python () {
|
||||
raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
|
||||
}
|
||||
|
||||
SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
|
||||
SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
|
||||
SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
|
||||
SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
|
||||
|
||||
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \
|
||||
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
|
||||
|
||||
@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
|
||||
KCONF_BSP_AUDIT_LEVEL = "2"
|
||||
|
||||
SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
|
||||
SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
|
||||
|
||||
PV = "${LINUX_VERSION}+git${SRCPV}"
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
|
||||
SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
|
||||
SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
|
||||
SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
|
||||
|
||||
SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; \
|
||||
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
|
||||
|
||||
@@ -48,7 +48,12 @@ def runqemu(args, config, basepath, workspace):
|
||||
raise DevtoolError('Unable to determine image name to run, please specify one')
|
||||
|
||||
try:
|
||||
exec_build_env_command(config.init_path, basepath, 'runqemu %s %s %s' % (machine, imagename, " ".join(args.args)), watch=True)
|
||||
# FIXME runqemu assumes that if OECORE_NATIVE_SYSROOT is set then it shouldn't
|
||||
# run bitbake to find out the values of various environment variables, which
|
||||
# isn't the case for the extensible SDK. Work around it for now.
|
||||
newenv = dict(os.environ)
|
||||
newenv.pop('OECORE_NATIVE_SYSROOT', '')
|
||||
exec_build_env_command(config.init_path, basepath, 'runqemu %s %s %s' % (machine, imagename, " ".join(args.args)), watch=True, env=newenv)
|
||||
except bb.process.ExecutionError as e:
|
||||
# We've already seen the output since watch=True, so just ensure we return something to the user
|
||||
return e.exitcode
|
||||
|
||||
Reference in New Issue
Block a user