sphinx: overview-manual: add figures

The automatic conversion with pandoc skipped the figures. Add them
manually.

(From yocto-docs rev: 1c2d071b7963490e8126a0b81792bda7a7c0bc8c)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

3 files changed, 66 insertions, 1 deletions

diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index b37adbbba6..11614d0e6c 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -171,6 +171,9 @@ The following diagram represents the high-level workflow of a build. The
 remainder of this section expands on the fundamental input, output,
 process, and metadata logical blocks that make up the workflow.
 
+.. image:: figures/YP-flow-diagram.png
+   :align: center
+
 In general, the build's workflow consists of several functional areas:
 
 -  *User Configuration:* metadata you can use to control the build
@@ -211,6 +214,9 @@ The following figure shows an expanded representation of the "User
 Configuration" box of the `general workflow
 figure <#general-workflow-figure>`__:
 
+.. image:: figures/user-configuration.png
+   :align: center
+
 BitBake needs some basic configuration files in order to complete a
 build. These files are ``*.conf`` files. The minimally necessary ones
 reside as example files in the ``build/conf`` directory of the `Source
@@ -405,6 +411,9 @@ figure <#general-workflow-figure>`__:
 The following figure shows an expanded representation of these three
 layers from the `general workflow figure <#general-workflow-figure>`__:
 
+.. image:: figures/layer-input.png
+   :align: center
+
 In general, all layers have a similar structure. They all contain a
 licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed,
 a ``README`` file as good practice and especially if the layer is to be
@@ -556,6 +565,9 @@ The remainder of this section provides a deeper look into the source
 files and the mirrors. Here is a more detailed look at the source file
 area of the `general workflow figure <#general-workflow-figure>`__:
 
+.. image:: figures/source-input.png
+   :align: center
+
 Upstream Project Releases
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -637,6 +649,9 @@ 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:
 
+.. image:: figures/package-feeds.png
+   :align: center
+
 Package feeds are an intermediary step in the build process. The
 OpenEmbedded build system provides classes to generate different package
 types, and you specify which classes to enable through the
@@ -711,6 +726,9 @@ Source Fetching
 The first stages of building a recipe are to fetch and unpack the source
 code:
 
+.. image:: figures/source-fetching.png
+   :align: center
+
 The ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__ and
 ```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__ tasks fetch
 the source files and unpack them into the `Build
@@ -802,6 +820,9 @@ Patching
 Once source code is fetched and unpacked, BitBake locates patch files
 and applies them to the source files:
 
+.. image:: figures/patching.png
+   :align: center
+
 The ```do_patch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-patch>`__ task uses a
 recipe's ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements
 and the ```FILESPATH`` <&YOCTO_DOCS_REF_URL;#var-FILESPATH>`__ variable
@@ -843,6 +864,9 @@ After source code is patched, BitBake executes tasks that configure and
 compile the source code. Once compilation occurs, the files are copied
 to a holding area (staged) in preparation for packaging:
 
+.. image:: figures/configuration-compile-autoreconf.png
+   :align: center
+
 This step in the build process consists of the following tasks:
 
 -  ```do_prepare_recipe_sysroot`` <&YOCTO_DOCS_REF_URL;#ref-tasks-prepare_recipe_sysroot>`__:
@@ -900,6 +924,9 @@ Package Splitting
 After source code is configured, compiled, and staged, the build system
 analyzes the results and splits the output into packages:
 
+.. image:: figures/analysis-for-package-splitting.png
+   :align: center
+
 The ```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ and
 ```do_packagedata`` <&YOCTO_DOCS_REF_URL;#ref-tasks-packagedata>`__
 tasks combine to analyze the files found in the
@@ -979,6 +1006,9 @@ Image Generation
 Once packages are split and stored in the Package Feeds area, the build
 system uses BitBake to generate the root filesystem image:
 
+.. image:: figures/image-generation.png
+   :align: center
+
 The image generation process consists of several stages and depends on
 several tasks and variables. The
 ```do_rootfs`` <&YOCTO_DOCS_REF_URL;#ref-tasks-rootfs>`__ task creates
@@ -1093,6 +1123,9 @@ The OpenEmbedded build system uses BitBake to generate the Software
 Development Kit (SDK) installer scripts for both the standard SDK and
 the extensible SDK (eSDK):
 
+.. image:: figures/sdk-generation.png
+   :align: center
+
 .. note::
 
    For more information on the cross-development toolchain generation,
@@ -1272,6 +1305,9 @@ the `general workflow figure <#general-workflow-figure>`__ that BitBake
 output, in part, consists of images. This section takes a closer look at
 this output:
 
+.. image:: figures/images.png
+   :align: center
+
 .. note::
 
    For a list of example images that the Yocto Project provides, see the
@@ -1331,6 +1367,9 @@ SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK
 (e.g. ``bitbake -c populate_sdk`` imagename). This section takes a
 closer look at this output:
 
+.. image:: figures/sdk.png
+   :align: center
+
 The specific form of this output is a set of files that includes a
 self-extracting SDK installer (``*.sh``), host and target manifest
 files, and files used for SDK testing. When the SDK installer file is
@@ -1450,6 +1489,9 @@ creates these necessary toolchains for you.
 The following figure shows a high-level build environment regarding
 toolchain construction and use.
 
+.. image:: figures/cross-development-toolchains.png
+   :align: center
+
 Most of the work occurs on the Build Host. This is the machine used to
 build images and generally work within the the Yocto Project
 environment. When you run
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 4e6770c4f4..abd775be84 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -179,6 +179,9 @@ development:
    Yocto Metadata Layers. You can create local copies of Git
    repositories for each of these areas.
 
+   .. image:: figures/source-repos.png
+      :align: center
+
    For steps on how to view and access these upstream Git repositories,
    see the "`Accessing Source
    Repositories <&YOCTO_DOCS_DEV_URL;#accessing-source-repositories>`__"
@@ -191,6 +194,9 @@ development:
    these files does not produce a local copy of the Git repository but
    rather a snapshot of a particular release or image.
 
+   .. image:: figures/index-downloads.png
+      :align: center
+
    For steps on how to view and access these files, see the "`Accessing
    Index of
    Releases <&YOCTO_DOCS_DEV_URL;#accessing-index-of-releases>`__"
@@ -205,6 +211,9 @@ development:
    form. The tarballs are similar to those found in the `Index of
    /releases: <&YOCTO_DL_URL;/releases/>`__ area.
 
+   .. image:: figures/yp-download.png
+      :align: center
+
    For steps on how to use the "DOWNLOADS" page, see the "`Using the
    Downloads Page <&YOCTO_DOCS_DEV_URL;#using-the-downloads-page>`__"
    section in the Yocto Project Development Tasks Manual.
@@ -285,6 +294,9 @@ develop, test, and submit changes to "contrib" areas for the maintainer
 to examine. The maintainer then chooses which changes are going to
 become a permanent part of the project.
 
+.. image:: figures/git-workflow.png
+   :align: center
+
 While each development environment is unique, there are some best
 practices or methods that help development run smoothly. The following
 list describes some of these practices. For more information about Git
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index 62257c26b9..06eeed5cb5 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -21,6 +21,9 @@ comes to delivering embedded software stacks. The project allows
 software customizations and build interchange for multiple hardware
 platforms as well as software stacks that can be maintained and scaled.
 
+.. image:: figures/key-dev-elements.png
+    :align: center
+
 For further introductory information on the Yocto Project, you might be
 interested in this
 `article <https://www.embedded.com/electronics-blogs/say-what-/4458600/Why-the-Yocto-Project-for-my-IoT-Project->`__
@@ -704,6 +707,9 @@ Repositories <&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/>`__.
 
 The following figure illustrates what generally comprises Poky:
 
+.. image:: figures/poky-reference-distribution.png
+    :align: center
+
 -  BitBake is a task executor and scheduler that is the heart of the
    OpenEmbedded build system.
 
@@ -784,7 +790,12 @@ The OpenEmbedded Build System Workflow
 The `OpenEmbedded build
 system <&YOCTO_DOCS_REF_URL;#build-system-term>`__ uses a "workflow" to
 accomplish image and SDK generation. The following figure overviews that
-workflow: Following is a brief summary of the "workflow":
+workflow:
+
+.. image:: figures/YP-flow-diagram.png
+    :align: center
+
+Following is a brief summary of the "workflow":
 
 1. Developers specify architecture, policies, patches and configuration
    details.