diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 4a6c3b2a6e..bfab8a6c68 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -743,223 +743,6 @@
-
- Package Feeds
-
-
- When the OpenEmbedded build system generates an image or an SDK,
- it gets the packages from a package feed area located in the
- Build Directory.
- The main
- Yocto Project Development Environment
- figure shows this package feeds area in the upper-right corner.
-
-
-
- This section looks a little closer into the package feeds area used
- by the build system.
- Here is a more detailed look at the area:
-
-
-
-
- Package feeds are an intermediary step in the build process.
- BitBake generates packages whose type is defined by the
- PACKAGE_CLASSES
- variable.
- Before placing the packages into package feeds,
- the build process validates them with generated output quality
- assurance checks through the
- insane.bbclass
- class.
-
-
-
- The package feed area resides in
- tmp/deploy of the Build Directory.
- Folders are created that correspond to the package type
- (IPK, DEB, or RPM) created.
- Further organization is derived through the value of the
- PACKAGE_ARCH
- variable for each package.
- For example, packages can exist for the i586 or qemux86
- architectures.
- The package files themselves reside within the appropriate
- architecture folder.
-
-
-
- BitBake uses the do_package_write_* task to
- place generated packages into the package holding area (e.g.
- do_package_write_ipk for IPK packages).
-
-
-
-
- Images
-
-
- The images produced by the OpenEmbedded build system
- are compressed forms of the
- root filesystems that are ready to boot on a target device.
- You can see from the main
- Yocto Project Development Environment
- figure that BitBake output in part consists of images.
- This section is going to look more closely at this output:
-
-
-
-
- For a list of example images that the Yocto Project provides,
- the
- "Images" chapter.
-
-
-
- Images are written out to the
- Build Directory
- inside the deploy/images folder as shown
- in the figure.
- This folder contains any files expected to be loaded on the
- target device.
- The
- DEPLOY_DIR
- variable points to the deploy directory.
-
- <kernel-image>:
- A kernel binary file.
- The KERNEL_IMAGETYPE
- variable setting determines the naming scheme for the
- kernel image file.
- Depending on that variable, the file could begin with
- a variety of naming strings.
- The deploy/images directory can
- contain multiple image files.
- <root-filesystem-image>:
- Root filesystems for the target device (e.g.
- *.ext3 or *.bz2
- files).
- The IMAGE_FSTYPES
- variable setting determines the root filesystem image
- type.
- The deploy/images directory can
- contain multiple root filesystems.
- <kernel-modules>:
- Tarballs that contain all the modules built for the kernel.
- Kernel module tarballs exist for legacy purposes and
- can be suppressed by setting the
- MODULE_TARBALL_DEPLOY
- variable to "0".
- The deploy/images directory can
- contain multiple kernel module tarballs.
-
- <bootloaders>:
- Bootloaders supporting the image, if applicable to the
- target machine.
- The deploy/images directory can
- contain multiple bootloaders.
-
- <symlinks>:
- The deploy/images folder contains
- a symbolic link that points to the most recently built file
- for each machine.
- These links might be useful for external scripts that
- need to obtain the latest version of each file.
-
-
-
-
-
-
- Application Development SDK
-
-
- In the overview figure of the
- Yocto Project Development Environment
- the output labeled "Application Development SDK" represents an
- SDK.
- This section is going to take a closer look at this output:
-
-
-
-
- The specific form of this output is a self-extracting
- SDK installer (*.sh) that, when run,
- installs the SDK, which consists of a cross-development
- toolchain, a set of libraries and headers, and an SDK
- environment setup script.
- Running this installer essentially sets up your
- cross-development environment.
- You can think of the cross-toolchain as the "host"
- part because it runs on the SDK machine.
- You can think of the libraries and headers as the "target"
- part because they are built for the target hardware.
- The setup script is added so that you can initialize the
- environment before using the tools.
-
-
-
-
- The Yocto Project supports several methods by which you can
- set up this cross-development environment.
- These methods include downloading pre-built SDK installers,
- building and installing your own SDK installer, or running
- an Application Development Toolkit (ADT) installer to
- install not just cross-development toolchains
- but also additional tools to help in this type of
- development.
-
-
-
- For background information on cross-development toolchains
- in the Yocto Project development environment, see the
- "Cross-Development Toolchain Generation"
- section.
- For information on setting up a cross-development
- environment, see the
- "Installing the ADT and Toolchains"
- section in the Yocto Project Application Developer's Guide.
-
-
-
-
- Once built, the SDK installers are written out to the
- deploy/sdk folder inside the
- Build Directory
- as shown in the figure at the beginning of this section.
- Several variables exist that help configure these files:
-
- DEPLOY_DIR:
- Points to the deploy
- directory.
- SDKMACHINE:
- Specifies the architecture of the machine
- on which the cross-development tools are run to
- create packages for the target hardware.
-
- SDKIMAGE_FEATURES:
- Lists the features to include in the "target" part
- of the SDK.
-
- TOOLCHAIN_HOST_TASK:
- Lists packages that make up the host
- part of the SDK (i.e. the part that runs on
- the SDKMACHINE).
- When you use
- bitbake -c populate_sdk <imagename>
- to create the SDK, a set of default packages
- apply.
- This variable allows you to add more packages.
-
- TOOLCHAIN_TARGET_TASK:
- Lists packages that make up the target part
- of the SDK (i.e. the part built for the
- target hardware).
-
-
-
-
-
BitBake
@@ -1190,6 +973,223 @@
+
+
+ Package Feeds
+
+
+ When the OpenEmbedded build system generates an image or an SDK,
+ it gets the packages from a package feed area located in the
+ Build Directory.
+ The main
+ Yocto Project Development Environment
+ figure shows this package feeds area in the upper-right corner.
+
+
+
+ This section looks a little closer into the package feeds area used
+ by the build system.
+ Here is a more detailed look at the area:
+
+
+
+
+ Package feeds are an intermediary step in the build process.
+ BitBake generates packages whose type is defined by the
+ PACKAGE_CLASSES
+ variable.
+ Before placing the packages into package feeds,
+ the build process validates them with generated output quality
+ assurance checks through the
+ insane.bbclass
+ class.
+
+
+
+ The package feed area resides in
+ tmp/deploy of the Build Directory.
+ Folders are created that correspond to the package type
+ (IPK, DEB, or RPM) created.
+ Further organization is derived through the value of the
+ PACKAGE_ARCH
+ variable for each package.
+ For example, packages can exist for the i586 or qemux86
+ architectures.
+ The package files themselves reside within the appropriate
+ architecture folder.
+
+
+
+ BitBake uses the do_package_write_* task to
+ place generated packages into the package holding area (e.g.
+ do_package_write_ipk for IPK packages).
+
+
+
+
+ Images
+
+
+ The images produced by the OpenEmbedded build system
+ are compressed forms of the
+ root filesystems that are ready to boot on a target device.
+ You can see from the main
+ Yocto Project Development Environment
+ figure that BitBake output in part consists of images.
+ This section is going to look more closely at this output:
+
+
+
+
+ For a list of example images that the Yocto Project provides,
+ the
+ "Images" chapter.
+
+
+
+ Images are written out to the
+ Build Directory
+ inside the deploy/images folder as shown
+ in the figure.
+ This folder contains any files expected to be loaded on the
+ target device.
+ The
+ DEPLOY_DIR
+ variable points to the deploy directory.
+
+ <kernel-image>:
+ A kernel binary file.
+ The KERNEL_IMAGETYPE
+ variable setting determines the naming scheme for the
+ kernel image file.
+ Depending on that variable, the file could begin with
+ a variety of naming strings.
+ The deploy/images directory can
+ contain multiple image files.
+ <root-filesystem-image>:
+ Root filesystems for the target device (e.g.
+ *.ext3 or *.bz2
+ files).
+ The IMAGE_FSTYPES
+ variable setting determines the root filesystem image
+ type.
+ The deploy/images directory can
+ contain multiple root filesystems.
+ <kernel-modules>:
+ Tarballs that contain all the modules built for the kernel.
+ Kernel module tarballs exist for legacy purposes and
+ can be suppressed by setting the
+ MODULE_TARBALL_DEPLOY
+ variable to "0".
+ The deploy/images directory can
+ contain multiple kernel module tarballs.
+
+ <bootloaders>:
+ Bootloaders supporting the image, if applicable to the
+ target machine.
+ The deploy/images directory can
+ contain multiple bootloaders.
+
+ <symlinks>:
+ The deploy/images folder contains
+ a symbolic link that points to the most recently built file
+ for each machine.
+ These links might be useful for external scripts that
+ need to obtain the latest version of each file.
+
+
+
+
+
+
+ Application Development SDK
+
+
+ In the overview figure of the
+ Yocto Project Development Environment
+ the output labeled "Application Development SDK" represents an
+ SDK.
+ This section is going to take a closer look at this output:
+
+
+
+
+ The specific form of this output is a self-extracting
+ SDK installer (*.sh) that, when run,
+ installs the SDK, which consists of a cross-development
+ toolchain, a set of libraries and headers, and an SDK
+ environment setup script.
+ Running this installer essentially sets up your
+ cross-development environment.
+ You can think of the cross-toolchain as the "host"
+ part because it runs on the SDK machine.
+ You can think of the libraries and headers as the "target"
+ part because they are built for the target hardware.
+ The setup script is added so that you can initialize the
+ environment before using the tools.
+
+
+
+
+ The Yocto Project supports several methods by which you can
+ set up this cross-development environment.
+ These methods include downloading pre-built SDK installers,
+ building and installing your own SDK installer, or running
+ an Application Development Toolkit (ADT) installer to
+ install not just cross-development toolchains
+ but also additional tools to help in this type of
+ development.
+
+
+
+ For background information on cross-development toolchains
+ in the Yocto Project development environment, see the
+ "Cross-Development Toolchain Generation"
+ section.
+ For information on setting up a cross-development
+ environment, see the
+ "Installing the ADT and Toolchains"
+ section in the Yocto Project Application Developer's Guide.
+
+
+
+
+ Once built, the SDK installers are written out to the
+ deploy/sdk folder inside the
+ Build Directory
+ as shown in the figure at the beginning of this section.
+ Several variables exist that help configure these files:
+
+ DEPLOY_DIR:
+ Points to the deploy
+ directory.
+ SDKMACHINE:
+ Specifies the architecture of the machine
+ on which the cross-development tools are run to
+ create packages for the target hardware.
+
+ SDKIMAGE_FEATURES:
+ Lists the features to include in the "target" part
+ of the SDK.
+
+ TOOLCHAIN_HOST_TASK:
+ Lists packages that make up the host
+ part of the SDK (i.e. the part that runs on
+ the SDKMACHINE).
+ When you use
+ bitbake -c populate_sdk <imagename>
+ to create the SDK, a set of default packages
+ apply.
+ This variable allows you to add more packages.
+
+ TOOLCHAIN_TARGET_TASK:
+ Lists packages that make up the target part
+ of the SDK (i.e. the part built for the
+ target hardware).
+
+
+
+