diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml
index f96b64c1a5..688fef8503 100644
--- a/documentation/ref-manual/faq.xml
+++ b/documentation/ref-manual/faq.xml
@@ -134,10 +134,10 @@
- Because you can use the same set of recipes to create output of
- various formats, the output of an OpenEmbedded build depends on
+ Because you can use the same set of recipes to create output of
+ various formats, the output of an OpenEmbedded build depends on
how you start it.
- Usually, the output is a flashable image ready for the target
+ Usually, the output is a flashable image ready for the target
device.
@@ -168,12 +168,12 @@
- The OpenEmbedded build system can build packages in various
- formats such as IPK for OPKG, Debian package
+ The OpenEmbedded build system can build packages in various
+ formats such as IPK for OPKG, Debian package
(.deb), or RPM.
- You can then upgrade the packages using the package tools on
- the device, much like on a desktop distribution such as
- Ubuntu or Fedora.
+ You can then upgrade the packages using the package tools on
+ the device, much like on a desktop distribution such as
+ Ubuntu or Fedora.
However, package management on the target is entirely optional.
@@ -249,7 +249,7 @@
For information on distributions that the Yocto Project
- uses during validation, see the
+ uses during validation, see the
Distribution Support
Wiki page.For notes about using the Yocto Project on a RHEL 4-based
@@ -297,8 +297,8 @@
= "0" in the .bb file but make sure the package is
manually marked as
machine-specific for the case that needs it.
- The code that handles
- SRC_URI_OVERRIDES_PACKAGE_ARCH is in
+ The code that handles
+ SRC_URI_OVERRIDES_PACKAGE_ARCH is in
the meta/classes/base.bbclass file.
@@ -320,8 +320,8 @@
http_proxy = http://proxy.yoyodyne.com:18023/
ftp_proxy = http://proxy.yoyodyne.com:18023/
- The Yocto Project also includes a
- site.conf.sample file that shows how to
+ The Yocto Project also includes a
+ site.conf.sample file that shows how to
configure CVS and Git proxy servers if needed.
@@ -352,19 +352,19 @@
- If the same build is failing in totally different and random
+ If the same build is failing in totally different and random
ways, the most likely explanation is:
- The hardware you are running the build on
+ The hardware you are running the build on
has some problem.
- You are running the build under
- virtualization, in which case the virtualization
- probably has bugs.
+ You are running the build under
+ virtualization, in which case the virtualization
+ probably has bugs.
- The OpenEmbedded build system processes a massive amount of
- data that causes lots of network, disk and CPU activity and
+ The OpenEmbedded build system processes a massive amount of
+ data that causes lots of network, disk and CPU activity and
is sensitive to even single-bit failures in any of these areas.
- True random failures have always been traced back to hardware
+ True random failures have always been traced back to hardware
or virtualization issues.
@@ -378,18 +378,18 @@
- This is a difficult question and you need to consult your lawyer
+ This is a difficult question and you need to consult your lawyer
for the answer for your specific case.
- It is worth bearing in mind that for GPL compliance, there needs
- to be enough information shipped to allow someone else to
+ It is worth bearing in mind that for GPL compliance, there needs
+ to be enough information shipped to allow someone else to
rebuild and produce the same end result you are shipping.
- This means sharing the source code, any patches applied to it,
- and also any configuration information about how that package
+ This means sharing the source code, any patches applied to it,
+ and also any configuration information about how that package
was configured and built.
- You can find more information on licensing in the
+ You can find more information on licensing in the
"Licensing"
and "Maintaining Open Source License Compliance During Your Product's Lifecycle"
sections, both of which are in the Yocto Project Development
@@ -410,7 +410,7 @@
"Miscellaneous BSP-Specific Recipe Files"
section in the Yocto Project Board Support Packages (BSP)
Developer's Guide.
- Set the HAVE_TOUCHSCREEN variable equal to
+ Set the HAVE_TOUCHSCREEN variable equal to
one as follows:
HAVE_TOUCHSCREEN=1
@@ -433,7 +433,7 @@
file.
See the "Miscellaneous BSP-Specific Recipe Files"
section in the Yocto Project Board Support Packages (BSP)
- Developer's Guide for information on creating these types of
+ Developer's Guide for information on creating these types of
miscellaneous recipe files.
@@ -454,32 +454,32 @@
- By default, the OpenEmbedded build system creates images
+ By default, the OpenEmbedded build system creates images
that are 1.3 times the size of the populated root filesystem.
- To affect the image size, you need to set various
+ To affect the image size, you need to set various
configurations:
Image Size:
- The OpenEmbedded build system uses the
+ The OpenEmbedded build system uses the
IMAGE_ROOTFS_SIZE
- variable to define the size of the image in Kbytes.
- The build system determines the size by taking into
+ variable to define the size of the image in Kbytes.
+ The build system determines the size by taking into
account the initial root filesystem size before any
- modifications such as requested size for the image and
- any requested additional free disk space to be
+ modifications such as requested size for the image and
+ any requested additional free disk space to be
added to the image.Overhead:
- Use the
+ Use the
IMAGE_OVERHEAD_FACTOR
- variable to define the multiplier that the build system
- applies to the initial image size, which is 1.3 by
+ variable to define the multiplier that the build system
+ applies to the initial image size, which is 1.3 by
default.Additional Free Space:
- Use the
+ Use the
IMAGE_ROOTFS_EXTRA_SPACE
variable to add additional free space to the image.
The build system adds this space to the image after
- it determines its
+ it determines its
IMAGE_ROOTFS_SIZE.
@@ -495,11 +495,11 @@
- The Yocto Project team has tried to do this before but too
- many of the tools the OpenEmbedded build system depends on,
- such as autoconf, break when they find
+ The Yocto Project team has tried to do this before but too
+ many of the tools the OpenEmbedded build system depends on,
+ such as autoconf, break when they find
spaces in pathnames.
- Until that situation changes, the team will not support spaces
+ Until that situation changes, the team will not support spaces
in pathnames.
@@ -515,11 +515,11 @@
The toolchain configuration is very flexible and customizable.
It is primarily controlled with the
- TCMODE
+ TCMODE
variable.
- This variable controls which tcmode-*.inc
- file to include from the
- meta/conf/distro/include directory within
+ This variable controls which tcmode-*.inc
+ file to include from the
+ meta/conf/distro/include directory within
the
Source Directory.
@@ -528,33 +528,37 @@
The default value of TCMODE is "default"
(i.e. tcmode-default.inc).
However, other patterns are accepted.
- In particular, "external-*" refers to external toolchains of
- which there are some basic examples included in the
+ In particular, "external-*" refers to external toolchains of
+ which there are some basic examples included in the
OpenEmbedded Core (meta).
- You can use your own custom toolchain definition in your own
- layer (or as defined in the local.conf
+ You can use your own custom toolchain definition in your own
+ layer (or as defined in the local.conf
file) at the location
conf/distro/include/tcmode-*.inc.
- In addition to the toolchain configuration, you also need a
+ In addition to the toolchain configuration, you also need a
corresponding toolchain recipe file.
- This recipe file needs to package up any pre-built objects in
- the toolchain such as libgcc,
- libstdcc++, any locales, and
+ This recipe file needs to package up any pre-built objects in
+ the toolchain such as libgcc,
+ libstdcc++, any locales, and
libc.
- An example is the
- external-sourcery-toolchain.bb, which is
- located in meta/recipes-core/meta/ within
+ An example is the
+ external-sourcery-toolchain.bb, which is
+ located in meta/recipes-core/meta/ within
the Source Directory.
- For information on installing and using cross-development
- toolchains, see the
+ For information on installing and using cross-development
+ toolchains, see the
"Installing the ADT and Toolchains"
section in the Yocto Project Application Developer's Guide.
+ For general information on cross-development toolchains, see
+ the
+ "Cross-Development Toolchain Generation"
+ section.
@@ -625,7 +629,7 @@
BB_FETCH_PREMIRRORONLY = "1"
- This statement limits the build system to pulling source
+ This statement limits the build system to pulling source
from the PREMIRRORS only.
Again, this technique is useful for reproducing builds.
@@ -634,7 +638,7 @@
BB_GENERATE_MIRROR_TARBALLS = "1"
- This statement tells the build system to generate mirror
+ This statement tells the build system to generate mirror
tarballs.
This technique is useful if you want to create a mirror server.
If not, however, the technique can simply waste time during
@@ -677,8 +681,8 @@
Yes - you can easily do this.
- When you use BitBake to build an image, all the build output
- goes into the directory created when you source the
+ When you use BitBake to build an image, all the build output
+ goes into the directory created when you source the
&OE_INIT_FILE;
setup script.
By default, this Build Directory
@@ -687,10 +691,10 @@
- Within the Build Directory, is the tmp
+ Within the Build Directory, is the tmp
directory.
- To remove all the build output yet preserve any source code or
- downloaded files from previous builds, simply remove the
+ To remove all the build output yet preserve any source code or
+ downloaded files from previous builds, simply remove the
tmp directory.