diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
index fb2d784..67b49d9 100644
--- a/poky/documentation/sdk-manual/appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -57,8 +57,7 @@
 ============================================================
 
 In most cases, the extensible SDK defaults should work with your :term:`Build
-Host`'s setup.
-However, some cases exist for which you might consider making
+Host`'s setup. However, there are cases when you might consider making
 adjustments:
 
 -  If your SDK configuration inherits additional classes using the
@@ -153,7 +152,7 @@
 
    SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
 
-While several ways exist to change this variable, an efficient method is
+While there are several ways of changing this variable, an efficient method is
 to set the variable in your distribution's configuration file. Doing so
 creates an SDK installer title that applies across your distribution. As
 an example, assume you have your own layer for your distribution named
@@ -223,7 +222,7 @@
 change this default installation directory by specifically setting the
 ``SDKEXTPATH`` variable.
 
-While a number of ways exist through which you can set this variable,
+While there are several ways of setting this variable,
 the method that makes the most sense is to set the variable in your
 distribution's configuration file. Doing so creates an SDK installer
 default directory that applies across your distribution. As an example,
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 04bafae..55bd7f6 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -194,7 +194,7 @@
    devtool
    quick reference.
 
-Three ``devtool`` subcommands exist that provide entry-points into
+Three ``devtool`` subcommands provide entry-points into
 development:
 
 -  *devtool add*: Assists in adding new software to be built.
@@ -276,7 +276,7 @@
          devtool
          always creates a Git repository locally during the extraction.
 
-      Furthermore, the first positional argument srctree in this case
+      Furthermore, the first positional argument ``srctree`` in this case
       identifies where the ``devtool add`` command will locate the
       extracted code outside of the workspace. You need to specify an
       empty directory::
@@ -285,13 +285,13 @@
 
       In summary,
       the source code is pulled from fetchuri and extracted into the
-      location defined by srctree as a local Git repository.
+      location defined by ``srctree`` as a local Git repository.
 
       Within workspace, ``devtool`` creates a recipe named recipe along
       with an associated append file.
 
    -  *Right*: The right scenario in the figure represents a situation
-      where the srctree has been previously prepared outside of the
+      where the ``srctree`` has been previously prepared outside of the
       ``devtool`` workspace.
 
       The following command provides a new recipe name and identifies
@@ -437,7 +437,7 @@
       locate the source code and any local patch files from other
       developers.
 
-      With this scenario, no srctree argument exists. Consequently, the
+      With this scenario, there is no ``srctree`` argument. Consequently, the
       default behavior of the ``devtool modify`` command is to extract
       the source files pointed to by the ``SRC_URI`` statements into a
       local Git structure. Furthermore, the location for the extracted
@@ -483,21 +483,21 @@
       under the newly created source tree.
 
       Once the files are located, the command by default extracts them
-      into srctree.
+      into ``srctree``.
 
       Within workspace, ``devtool`` creates an append file for the
       recipe. The recipe remains in its original location but the source
-      files are extracted to the location you provide with srctree.
+      files are extracted to the location you provide with ``srctree``.
 
    -  *Right*: The right scenario in the figure represents a situation
-      where the source tree (srctree) already exists locally as a
+      where the source tree (``srctree``) already exists locally as a
       previously extracted Git structure outside of the ``devtool``
       workspace. In this example, the recipe also exists elsewhere
       locally in its own layer.
 
       The following command tells ``devtool`` the recipe with which to
       work, uses the "-n" option to indicate source does not need to be
-      extracted, and uses srctree to point to the previously extracted
+      extracted, and uses ``srctree`` to point to the previously extracted
       source files::
 
          $ devtool modify -n recipe srctree
@@ -646,8 +646,9 @@
    code into the ``sources`` directory in the
    :ref:`devtool-the-workspace-layer-structure`.
    If you want the code extracted to any other location, you need to
-   provide the srctree positional argument with the command as follows:
-   $ devtool upgrade -V version recipe srctree
+   provide the ``srctree`` positional argument with the command as follows::
+
+      $ devtool upgrade -V version recipe srctree
 
    .. note::
 
@@ -674,8 +675,8 @@
    are incorporated into the build the next time you build the software
    just as are other changes you might have made to the source.
 
-2. *Resolve any Conflicts created by the Upgrade*: Conflicts could exist
-   due to the software being upgraded to a new version. Conflicts occur
+2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
+   after upgrading the software to a new version. Conflicts occur
    if your recipe specifies some patch files in ``SRC_URI`` that
    conflict with changes made in the new version of the software. For
    such cases, you need to resolve the conflicts by editing the source
@@ -908,8 +909,8 @@
    similar manner to the environment set up by the SDK's environment
    setup script. One easy way to see these variables is to run the
    ``devtool build`` command on the recipe and then look in
-   ``oe-logs/run.do_compile``. Towards the top of this file, a list of
-   environment variables exists that are being set. You can take
+   ``oe-logs/run.do_compile``. Towards the top of this file, there is
+   a list of environment variables that are set. You can take
    advantage of these variables within the Makefile.
 
 -  If the Makefile sets a default for a variable using "=", that default
@@ -953,7 +954,7 @@
    Specifying the name like this produces a recipe that only builds for
    the build host.
 
--  Specify the "DASHDASHalso-native" option with the ``devtool add``
+-  Specify the "--also-native" option with the ``devtool add``
    command. Specifying this option creates a recipe file that still
    builds for the target but also creates a variant with a "-native"
    suffix that builds for the build host.
@@ -964,7 +965,7 @@
    that builds code for the target, you can typically accomplish this by
    building the native and target parts separately rather than within
    the same compilation process. Realize though that with the
-   "DASHDASHalso-native" option, you can add the tool using just one
+   "--also-native" option, you can add the tool using just one
    recipe file.
 
 Adding Node.js Modules
@@ -1037,8 +1038,8 @@
 does not include complete instructions for building the software.
 Instead, common functionality is encapsulated in classes inherited with
 the ``inherit`` directive. This technique leaves the recipe to describe
-just the things that are specific to the software being built. A
-:ref:`base <ref-classes-base>` class exists that
+just the things that are specific to the software being built. There is
+a :ref:`base <ref-classes-base>` class that
 is implicitly inherited by all recipes and provides the functionality
 that most recipes typically need.
 
@@ -1100,7 +1101,7 @@
 exact options being passed, and shows them to you along with any custom
 arguments specified through ``EXTRA_OECONF`` or
 ``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you
-the output of the configure script's "DASHDASHhelp" option as a
+the output of the configure script's "--help" option as a
 reference.
 
 Sharing Files Between Recipes
@@ -1110,9 +1111,9 @@
 :term:`Build Host`. For example,
 an application linking to a common library needs access to the library
 itself and its associated headers. The way this access is accomplished
-within the extensible SDK is through the sysroot. One sysroot exists per
+within the extensible SDK is through the sysroot. There is one sysroot per
 "machine" for which the SDK is being built. In practical terms, this
-means a sysroot exists for the target machine, and a sysroot exists for
+means there is a sysroot for the target machine, and a sysroot for
 the build host.
 
 Recipes should never write files directly into the sysroot. Instead,
@@ -1159,8 +1160,8 @@
 ``${``\ :term:`PN`\ ``}`` evaluates to the
 recipe name). The order of the ``PACKAGES`` value is significant. For
 each installed file, the first package whose ``FILES`` value matches the
-file is the package into which the file goes. Defaults exist for both
-the ``PACKAGES`` and ``FILES`` variables. Consequently, you might find
+file is the package into which the file goes. Both the ``PACKAGES`` and
+``FILES`` variables have default values. Consequently, you might find
 you do not even need to set these variables in your recipe unless the
 software the recipe is building installs files into non-standard
 locations.
@@ -1230,7 +1231,7 @@
 
 It is important to remember that building the item from source
 takes significantly longer than installing the pre-built artifact. Also,
-if no recipe exists for the item you want to add to the SDK, you must
+if there is no recipe for the item you want to add to the SDK, you must
 instead add the item using the ``devtool add`` command.
 
 Applying Updates to an Installed Extensible SDK
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index d966efe..2f94aaf 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -8,8 +8,8 @@
 =================
 
 Welcome to the Yocto Project Application Development and the Extensible
-Software Development Kit (eSDK) manual. This manual provides information
-that explains how to use both the Yocto Project extensible and standard
+Software Development Kit (eSDK) manual. This manual
+explains how to use both the Yocto Project extensible and standard
 SDKs to develop applications and images.
 
 .. note::
@@ -25,12 +25,13 @@
 All SDKs consist of the following:
 
 -  *Cross-Development Toolchain*: This toolchain contains a compiler,
-   debugger, and various miscellaneous tools.
+   debugger, and various associated tools.
 
 -  *Libraries, Headers, and Symbols*: The libraries, headers, and
-   symbols are specific to the image (i.e. they match the image).
+   symbols are specific to the image (i.e. they match the image
+   against which the SDK was built).
 
--  *Environment Setup Script*: This ``*.sh`` file, once run, sets up the
+-  *Environment Setup Script*: This ``*.sh`` file, once sourced, sets up the
    cross-development environment by defining variables and preparing for
    SDK use.
 
@@ -48,14 +49,14 @@
 for a wrapper around the ``populate_sdk`` and ``populate_sdk_ext``
 archives.
 
-Another feature for the SDKs is that only one set of cross-compiler
+Another feature of the SDKs is that only one set of cross-compiler
 toolchain binaries are produced for any given architecture. This feature
 takes advantage of the fact that the target hardware can be passed to
 ``gcc`` as a set of compiler options. Those options are set up by the
 environment script and contained in variables such as
 :term:`CC` and
 :term:`LD`. This reduces the space needed
-for the tools. Understand, however, that every target still needs a
+for the tools. Understand, however, that every target still needs its own
 sysroot because those binaries are target-specific.
 
 The SDK development environment consists of the following:
@@ -118,8 +119,8 @@
 
 The :term:`Cross-Development Toolchain` consists
 of a cross-compiler, cross-linker, and cross-debugger that are used to
-develop user-space applications for targeted hardware. Additionally, for
-an extensible SDK, the toolchain also has built-in ``devtool``
+develop user-space applications for targeted hardware; in addition,
+the extensible SDK comes with built-in ``devtool``
 functionality. This toolchain is created by running a SDK installer
 script or through a :term:`Build Directory` that is based on
 your metadata configuration or extension for your targeted device. The
@@ -138,21 +139,19 @@
 -----------------
 
 The QEMU emulator allows you to simulate your hardware while running
-your application or image. QEMU is not part of the SDK but is made
-available a number of different ways:
+your application or image. QEMU is not part of the SDK but is
+automatically installed and available if you have done any one of
+the following:
 
--  If you have cloned the ``poky`` Git repository to create a
-   :term:`Source Directory` and you have
-   sourced the environment setup script, QEMU is installed and
-   automatically available.
+-  cloned the ``poky`` Git repository to create a
+   :term:`Source Directory` and sourced the environment setup script.
 
--  If you have downloaded a Yocto Project release and unpacked it to
-   create a Source Directory and you have sourced the environment setup
-   script, QEMU is installed and automatically available.
+-  downloaded a Yocto Project release and unpacked it to
+   create a Source Directory and sourced the environment setup
+   script.
 
--  If you have installed the cross-toolchain tarball and you have
-   sourced the toolchain's setup environment script, QEMU is also
-   installed and automatically available.
+-  installed the cross-toolchain tarball and
+   sourced the toolchain's setup environment script.
 
 SDK Development Model
 =====================
@@ -202,10 +201,9 @@
 
    .. note::
 
-      To use the root filesystem in QEMU, you need to extract it. See
-      the "
-      Extracting the Root Filesystem
-      " section for information on how to extract the root filesystem.
+      To use the root filesystem in QEMU, you need to extract it. See the
+      ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
+      section for information on how to do this extraction.
 
 3. *Develop and Test your Application:* At this point, you have the
    tools to develop your application. If you need to separately install
@@ -216,5 +214,5 @@
    within the Yocto Project.
 
 The remainder of this manual describes how to use the extensible and
-standard SDKs. Information also exists in appendix form that describes
+standard SDKs. There is also information in appendix form describing
 how you can build, install, and modify an SDK.
diff --git a/poky/documentation/sdk-manual/using.rst b/poky/documentation/sdk-manual/using.rst
index fa0e8d4..3016278 100644
--- a/poky/documentation/sdk-manual/using.rst
+++ b/poky/documentation/sdk-manual/using.rst
@@ -11,9 +11,8 @@
 .. note::
 
    For a side-by-side comparison of main features supported for a
-   standard SDK as compared to an extensible SDK, see the "
-   Introduction
-   " section.
+   standard SDK as compared to an extensible SDK, see the
+   ":ref:`sdk-manual/intro:introduction`" section.
 
 You can use a standard SDK to work on Makefile and Autotools-based
 projects. See the
@@ -49,7 +48,7 @@
 64-bit architectures with the ``x86_64`` directories, respectively. The
 toolchains the Yocto Project provides are based off the
 ``core-image-sato`` and ``core-image-minimal`` images and contain
-libraries appropriate for developing against that image.
+libraries appropriate for developing against the corresponding image.
 
 The names of the tarball installer scripts are such that a string
 representing the host system appears first in the filename and then is
@@ -84,9 +83,9 @@
 .. note::
 
    As an alternative to downloading an SDK, you can build the SDK
-   installer. For information on building the installer, see the "
-   Building an SDK Installer
-   " section.
+   installer. For information on building the installer, see the
+   ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
+   section.
 
 The SDK and toolchains are self-contained and by default are installed
 into the ``poky_sdk`` folder in your home directory. You can choose to