diff --git a/poky/documentation/README b/poky/documentation/README
index b0a3cb1..be03bb1 100644
--- a/poky/documentation/README
+++ b/poky/documentation/README
@@ -2,7 +2,7 @@
 =============
 
 This is the directory that contains the Yocto Project documentation.  The Yocto
-Project source repositories at http://git.yoctoproject.org/cgit.cgi have two
+Project source repositories at https://git.yoctoproject.org/cgit.cgi have two
 instances of the "documentation" directory.  You should understand each of
 these instances.
 
@@ -47,12 +47,12 @@
 Each folder is self-contained regarding content and figures.
 
 If you want to find HTML versions of the Yocto Project manuals on the web,
-go to http://www.yoctoproject.org and click on the "Documentation" tab.  From
+go to https://www.yoctoproject.org and click on the "Documentation" tab.  From
 there you have access to archived documentation from previous releases, current
 documentation for the latest release, and "Docs in Progress" for the release
 currently being developed.
 
-In general, the Yocto Project site (http://www.yoctoproject.org) is a great
+In general, the Yocto Project site (https://www.yoctoproject.org) is a great
 reference for both information and downloads.
 
 poky.yaml
@@ -228,7 +228,7 @@
 
 Variables can be nested, like it was the case for DocBook:
 
-  YOCTO_HOME_URL : "http://www.yoctoproject.org"
+  YOCTO_HOME_URL : "https://www.yoctoproject.org"
   YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs"
 
 Note directive
diff --git a/poky/documentation/boilerplate.rst b/poky/documentation/boilerplate.rst
index ddffdac..2ad60eb 100644
--- a/poky/documentation/boilerplate.rst
+++ b/poky/documentation/boilerplate.rst
@@ -8,7 +8,7 @@
 
 Permission is granted to copy, distribute and/or modify this document under the
 terms of the `Creative Commons Attribution-Share Alike 2.0 UK: England & Wales
-<http://creativecommons.org/licenses/by-sa/2.0/uk/>`_ as published by Creative
+<https://creativecommons.org/licenses/by-sa/2.0/uk/>`_ as published by Creative
 Commons.
 
 To report any inaccuracies or problems with this (or any other Yocto Project)
diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst
index f077ee8..63083cb 100644
--- a/poky/documentation/brief-yoctoprojectqs/index.rst
+++ b/poky/documentation/brief-yoctoprojectqs/index.rst
@@ -397,7 +397,7 @@
    Development Community into which you can tap.
 
 -  **Developer Screencast:** The `Getting Started with the Yocto Project -
-   New Developer Screencast Tutorial <http://vimeo.com/36450321>`__
+   New Developer Screencast Tutorial <https://vimeo.com/36450321>`__
    provides a 30-minute video created for users unfamiliar with the
    Yocto Project but familiar with Linux build hosts. While this
    screencast is somewhat dated, the introductory and fundamental
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 068ab6c..93e9182 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -894,8 +894,8 @@
    ``recipes-*`` subdirectories specific to the recipe's function, or
    within a subdirectory containing a set of closely-related recipes.
    The recipes themselves should follow the general guidelines for
-   recipes used in the Yocto Project found in the "`OpenEmbedded Style
-   Guide <http://openembedded.org/wiki/Styleguide>`__".
+   recipes used in the Yocto Project found in the ":oe_wiki:`OpenEmbedded
+   Style Guide </Styleguide>`".
 
 -  *License File:* You must include a license file in the
    ``meta-bsp_root_name`` directory. This license covers the BSP
diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py
index a626b1f..407ea32 100644
--- a/poky/documentation/conf.py
+++ b/poky/documentation/conf.py
@@ -68,7 +68,7 @@
 
 # external links and substitutions
 extlinks = {
-    'yocto_home': ('https://yoctoproject.org%s', None),
+    'yocto_home': ('https://www.yoctoproject.org%s', None),
     'yocto_wiki': ('https://wiki.yoctoproject.org/wiki%s', None),
     'yocto_dl': ('https://downloads.yoctoproject.org%s', None),
     'yocto_lists': ('https://lists.yoctoproject.org%s', None),
@@ -79,6 +79,9 @@
     'oe_home': ('https://www.openembedded.org%s', None),
     'oe_lists': ('https://lists.openembedded.org%s', None),
     'oe_git': ('https://git.openembedded.org%s', None),
+    'oe_wiki': ('https://www.openembedded.org/wiki%s', None),
+    'oe_layerindex': ('https://layers.openembedded.org%s', None),
+    'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None),
 }
 
 # Intersphinx config to use cross reference with Bitbake user manual
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index ada3bac..e1dee8e 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -38,9 +38,8 @@
 
 1. *Check Existing Layers:* Before creating a new layer, you should be
    sure someone has not already created a layer containing the Metadata
-   you need. You can see the `OpenEmbedded Metadata
-   Index <https://layers.openembedded.org/layerindex/layers/>`__ for a
-   list of layers from the OpenEmbedded community that can be used in
+   you need. You can see the :oe_layerindex:`OpenEmbedded Metadata Index <>`
+   for a list of layers from the OpenEmbedded community that can be used in
    the Yocto Project. You could find a layer that is identical or close
    to what you need.
 
@@ -322,7 +321,7 @@
    successful compatibility registration.
 
 2. Completion of an application acceptance form, which you can find at
-   https://www.yoctoproject.org/webform/yocto-project-compatible-registration.
+   :yocto_home:`/webform/yocto-project-compatible-registration`.
 
 To be granted permission to use the logo, you need to satisfy the
 following:
@@ -346,7 +345,7 @@
 layer and the application that uses your layer.
 
 To access the form, use this link:
-https://www.yoctoproject.org/webform/yocto-project-compatible-registration.
+:yocto_home:`/webform/yocto-project-compatible-registration`.
 Follow the instructions on the form to complete your application.
 
 The application consists of the following sections:
@@ -1194,8 +1193,8 @@
 whether someone else has already written one that meets (or comes close
 to meeting) your needs. The Yocto Project and OpenEmbedded communities
 maintain many recipes that might be candidates for what you are doing.
-You can find a good central index of these recipes in the `OpenEmbedded
-Layer Index <https://layers.openembedded.org>`__.
+You can find a good central index of these recipes in the
+:oe_layerindex:`OpenEmbedded Layer Index <>`.
 
 Working from an existing recipe or a skeleton recipe is the best way to
 get started. Here are some points on both methods:
@@ -2540,7 +2539,7 @@
 ---------------------------------
 
 When writing recipes, it is good to conform to existing style
-guidelines. The :oe_home:`OpenEmbedded Styleguide </wiki/Styleguide>` wiki page
+guidelines. The :oe_wiki:`OpenEmbedded Styleguide </Styleguide>` wiki page
 provides rough guidelines for preferred recipe style.
 
 It is common for existing recipes to deviate a bit from this style.
@@ -6044,7 +6043,7 @@
    Botnet
 
 -  *"*\ `Security Issues for Embedded
-   Devices <http://elinux.org/images/6/6f/Security-issues.pdf>`__\ *"*
+   Devices <https://elinux.org/images/6/6f/Security-issues.pdf>`__\ *"*
    by Jake Edge
 
 When securing your image is of concern, there are steps, tools, and
diff --git a/poky/documentation/kernel-dev/intro.rst b/poky/documentation/kernel-dev/intro.rst
index c95d2f7..f6c9b97 100644
--- a/poky/documentation/kernel-dev/intro.rst
+++ b/poky/documentation/kernel-dev/intro.rst
@@ -72,8 +72,7 @@
 
 The remainder of this manual provides instructions for completing
 specific Linux kernel development tasks. These instructions assume you
-are comfortable working with
-`BitBake <https://openembedded.org/wiki/Bitbake>`__ recipes and basic
+are comfortable working with :oe_wiki:`BitBake </Bitbake>` recipes and basic
 open-source development tools. Understanding these concepts will
 facilitate the process of working with the kernel recipes. If you find
 you need some additional background, please be sure to review and
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 8fbbabb..257de44 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -141,12 +141,10 @@
 using a different layer where that metadata might be common across
 several pieces of hardware.
 
-Many layers exist that work in the Yocto Project development
-environment. The `Yocto Project Curated Layer
-Index <https://www.yoctoproject.org/software-overview/layers/>`__
-and `OpenEmbedded Layer
-Index <http://layers.openembedded.org/layerindex/branch/master/layers/>`__
-both contain layers from which you can use or leverage.
+Many layers exist that work in the Yocto Project development environment. The
+:yocto_home:`Yocto Project Curated Layer Index </software-overview/layers/>`
+and :oe_layerindex:`OpenEmbedded Layer Index <>` both contain layers from
+which you can use or leverage.
 
 By convention, layers in the Yocto Project follow a specific form.
 Conforming to a known structure allows BitBake to make assumptions
@@ -380,13 +378,11 @@
 
 -  *Metadata (.bb + Patches):* Software layers containing
    user-supplied recipe files, patches, and append files. A good example
-   of a software layer might be the
-   `meta-qt5 layer <https://github.com/meta-qt5/meta-qt5>`__ from
-   the `OpenEmbedded Layer
-   Index <http://layers.openembedded.org/layerindex/branch/master/layers/>`__.
-   This layer is for version 5.0 of the popular
-   `Qt <https://wiki.qt.io/About_Qt>`__ cross-platform application
-   development framework for desktop, embedded and mobile.
+   of a software layer might be the :oe_layer:`meta-qt5 layer </meta-qt5>`
+   from the :oe_layerindex:`OpenEmbedded Layer Index <>`. This layer is for
+   version 5.0 of the popular `Qt <https://wiki.qt.io/About_Qt>`__
+   cross-platform application development framework for desktop, embedded and
+   mobile.
 
 -  *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e.
    "BSP Layer" in the following figure) providing machine-specific
@@ -2096,10 +2092,8 @@
 the BitBake keyword/variable flag that requests a fake root environment
 for a task.
 
-In the :term:`OpenEmbedded Build System`,
-the program that
-implements fakeroot is known as
-`Pseudo <https://www.yoctoproject.org/software-item/pseudo/>`__. Pseudo
+In the :term:`OpenEmbedded Build System`, the program that implements
+fakeroot is known as :yocto_home:`Pseudo </software-item/pseudo/>`. Pseudo
 overrides system calls by using the environment variable ``LD_PRELOAD``,
 which results in the illusion of running as root. To keep track of
 "fake" file ownership and permissions resulting from operations that
diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst
index 9a2997d..011a479 100644
--- a/poky/documentation/overview-manual/development-environment.rst
+++ b/poky/documentation/overview-manual/development-environment.rst
@@ -40,7 +40,7 @@
 Microsoft Corporation.
 
 Wikipedia has a good historical description of the Open Source
-Philosophy `here <http://en.wikipedia.org/wiki/Open_source>`__. You can
+Philosophy `here <https://en.wikipedia.org/wiki/Open_source>`__. You can
 also find helpful information on how to participate in the Linux
 Community
 `here <https://www.kernel.org/doc/html/latest/process/index.html>`__.
@@ -291,7 +291,7 @@
 practices or methods that help development run smoothly. The following
 list describes some of these practices. For more information about Git
 workflows, see the workflow topics in the `Git Community
-Book <http://book.git-scm.com>`__.
+Book <https://book.git-scm.com>`__.
 
 -  *Make Small Changes:* It is best to keep the changes you commit small
    as compared to bundling many disparate changes into a single commit.
@@ -368,12 +368,12 @@
 .. note::
 
    -  For more information on Git, see
-      http://git-scm.com/documentation.
+      https://git-scm.com/documentation.
 
    -  If you need to download Git, it is recommended that you add Git to
       your system through your distribution's "software store" (e.g. for
       Ubuntu, use the Ubuntu Software feature). For the Git download
-      page, see http://git-scm.com/download.
+      page, see https://git-scm.com/download.
 
    -  For information beyond the introductory nature in this section,
       see the ":ref:`dev-manual/start:locating yocto project source files`"
@@ -507,7 +507,7 @@
 you understand the basic philosophy behind Git. You do not have to be an
 expert in Git to be functional. A good place to look for instruction on
 a minimal set of Git commands is
-`here <http://git-scm.com/documentation>`__.
+`here <https://git-scm.com/documentation>`__.
 
 The following list of Git commands briefly describes some basic Git
 operations as a way to get started. As with any set of commands, this
@@ -614,10 +614,10 @@
 this history, you can find basic information here:
 
 -  `Open source license
-   history <http://en.wikipedia.org/wiki/Open-source_license>`__
+   history <https://en.wikipedia.org/wiki/Open-source_license>`__
 
 -  `Free software license
-   history <http://en.wikipedia.org/wiki/Free_software_license>`__
+   history <https://en.wikipedia.org/wiki/Free_software_license>`__
 
 In general, the Yocto Project is broadly licensed under the
 Massachusetts Institute of Technology (MIT) License. MIT licensing
@@ -626,9 +626,9 @@
 the GNU General Public License (GPL). Patches to the Yocto Project
 follow the upstream licensing scheme. You can find information on the
 MIT license
-`here <http://www.opensource.org/licenses/mit-license.php>`__. You can
+`here <https://www.opensource.org/licenses/mit-license.php>`__. You can
 find information on the GNU GPL
-`here <http://www.opensource.org/licenses/LGPL-3.0>`__.
+`here <https://www.opensource.org/licenses/LGPL-3.0>`__.
 
 When you build an image using the Yocto Project, the build process uses
 a known list of licenses to ensure compliance. You can find this list in
@@ -646,11 +646,11 @@
 
 The base list of licenses used by the build process is a combination of
 the Software Package Data Exchange (SPDX) list and the Open Source
-Initiative (OSI) projects. `SPDX Group <http://spdx.org>`__ is a working
+Initiative (OSI) projects. `SPDX Group <https://spdx.org>`__ is a working
 group of the Linux Foundation that maintains a specification for a
 standard format for communicating the components, licenses, and
 copyrights associated with a software package.
-`OSI <http://opensource.org>`__ is a corporation dedicated to the Open
+`OSI <https://opensource.org>`__ is a corporation dedicated to the Open
 Source Definition and the effort for reviewing and approving licenses
 that conform to the Open Source Definition (OSD).
 
diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index 66a88c9..0ec7e2b 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -221,8 +221,7 @@
 
    -  Familiarize yourself with the `Yocto Project curated layer
       index <https://www.yoctoproject.org/software-overview/layers/>`__
-      or the `OpenEmbedded layer
-      index <http://layers.openembedded.org/layerindex/branch/master/layers/>`__.
+      or the :oe_layerindex:`OpenEmbedded layer index <>`.
       The latter contains more layers but they are less universally
       validated.
 
@@ -364,13 +363,12 @@
    versions available for Yocto Project. The main purpose of the system
    is to help you manage the recipes you maintain and to offer a dynamic
    overview of the project. The Recipe Reporting System is built on top
-   of the `OpenEmbedded Layer
-   Index <http://layers.openembedded.org/layerindex/layers/>`__, which
+   of the :oe_layerindex:`OpenEmbedded Layer Index <>`, which
    is a website that indexes OpenEmbedded-Core layers.
 
 -  *Patchwork:* `Patchwork <http://jk.ozlabs.org/projects/patchwork/>`__
    is a fork of a project originally started by
-   `OzLabs <http://ozlabs.org/>`__. The project is a web-based tracking
+   `OzLabs <https://ozlabs.org/>`__. The project is a web-based tracking
    system designed to streamline the process of bringing contributions
    into a project. The Yocto Project uses Patchwork as an organizational
    tool to handle patches, which number in the thousands for every
@@ -402,7 +400,7 @@
 
    Historically, cross-prelink is a variant of prelink, which was
    conceived by `Jakub
-   Jelínek <http://people.redhat.com/jakub/prelink.pdf>`__ a number of
+   Jelínek <https://people.redhat.com/jakub/prelink.pdf>`__ a number of
    years ago. Both prelink and cross-prelink are maintained in the same
    repository albeit on separate branches. By providing an emulated
    runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation),
@@ -531,8 +529,7 @@
    Debian Package (dpkg) in operation.
 
    Opkg is intended for use on embedded Linux devices and is used in
-   this capacity in the
-   `OpenEmbedded <http://www.openembedded.org/wiki/Main_Page>`__ and
+   this capacity in the :oe_home:`OpenEmbedded <>` and
    `OpenWrt <https://openwrt.org/>`__ projects, as well as the Yocto
    Project.
 
diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst
index 418f4e9..b401cf9 100644
--- a/poky/documentation/profile-manual/usage.rst
+++ b/poky/documentation/profile-manual/usage.rst
@@ -39,7 +39,7 @@
 The coverage below details some of the most common ways you'll likely
 want to apply the tool; full documentation can be found either within
 the tool itself or in the man pages at
-`perf(1) <http://linux.die.net/man/1/perf>`__.
+`perf(1) <https://linux.die.net/man/1/perf>`__.
 
 Perf Setup
 ----------
@@ -860,7 +860,7 @@
 be derived from it.
 
 Documentation on using the `'perf script' python
-binding <http://linux.die.net/man/1/perf-script-python>`__.
+binding <https://linux.die.net/man/1/perf-script-python>`__.
 
 System-Wide Tracing and Profiling
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1136,32 +1136,31 @@
 Online versions of the man pages for the commands discussed in this
 section can be found here:
 
--  The `'perf stat' manpage <http://linux.die.net/man/1/perf-stat>`__.
+-  The `'perf stat' manpage <https://linux.die.net/man/1/perf-stat>`__.
 
 -  The `'perf record'
-   manpage <http://linux.die.net/man/1/perf-record>`__.
+   manpage <https://linux.die.net/man/1/perf-record>`__.
 
 -  The `'perf report'
-   manpage <http://linux.die.net/man/1/perf-report>`__.
+   manpage <https://linux.die.net/man/1/perf-report>`__.
 
--  The `'perf probe' manpage <http://linux.die.net/man/1/perf-probe>`__.
+-  The `'perf probe' manpage <https://linux.die.net/man/1/perf-probe>`__.
 
 -  The `'perf script'
-   manpage <http://linux.die.net/man/1/perf-script>`__.
+   manpage <https://linux.die.net/man/1/perf-script>`__.
 
 -  Documentation on using the `'perf script' python
-   binding <http://linux.die.net/man/1/perf-script-python>`__.
+   binding <https://linux.die.net/man/1/perf-script-python>`__.
 
--  The top-level `perf(1) manpage <http://linux.die.net/man/1/perf>`__.
+-  The top-level `perf(1) manpage <https://linux.die.net/man/1/perf>`__.
 
 Normally, you should be able to invoke the man pages via perf itself
 e.g. 'perf help' or 'perf help record'.
 
 However, by default Yocto doesn't install man pages, but perf invokes
 the man pages for most help functionality. This is a bug and is being
-addressed by a Yocto bug: `Bug 3388 - perf: enable man pages for basic
-'help'
-functionality <https://bugzilla.yoctoproject.org/show_bug.cgi?id=3388>`__.
+addressed by a Yocto bug: :yocto_bugs:`Bug 3388 - perf: enable man pages for
+basic 'help' functionality </show_bug.cgi?id=3388>`.
 
 The man pages in text form, along with some other files, such as a set
 of examples, can be found in the 'perf' directory of the kernel tree: ::
@@ -1719,7 +1718,7 @@
 
 The tool is pretty self-explanatory, but for more detailed information
 on navigating through the data, see the `kernelshark
-website <http://rostedt.homelinux.com/kernelshark/>`__.
+website <https://rostedt.homelinux.com/kernelshark/>`__.
 
 ftrace Documentation
 --------------------
@@ -1737,19 +1736,19 @@
 There is a nice series of articles on using ftrace and trace-cmd at LWN:
 
 -  `Debugging the kernel using Ftrace - part
-   1 <http://lwn.net/Articles/365835/>`__
+   1 <https://lwn.net/Articles/365835/>`__
 
 -  `Debugging the kernel using Ftrace - part
-   2 <http://lwn.net/Articles/366796/>`__
+   2 <https://lwn.net/Articles/366796/>`__
 
 -  `Secrets of the Ftrace function
-   tracer <http://lwn.net/Articles/370423/>`__
+   tracer <https://lwn.net/Articles/370423/>`__
 
 -  `trace-cmd: A front-end for
    Ftrace <https://lwn.net/Articles/410200/>`__
 
 There's more detailed documentation kernelshark usage here:
-`KernelShark <http://rostedt.homelinux.com/kernelshark/>`__
+`KernelShark <https://rostedt.homelinux.com/kernelshark/>`__
 
 An amusing yet useful README (a tracing mini-HOWTO) can be found in
 ``/sys/kernel/debug/tracing/README``.
@@ -1764,7 +1763,7 @@
 invoked under.
 
 For example, this probe from the `SystemTap
-tutorial <http://sourceware.org/systemtap/tutorial/>`__ simply prints a
+tutorial <https://sourceware.org/systemtap/tutorial/>`__ simply prints a
 line every time any process on the system open()s a file. For each line,
 it prints the executable name of the program that opened the file, along
 with its PID, and the name of the file it opened (or tried to open),
@@ -1937,11 +1936,11 @@
 -----------------------
 
 The SystemTap language reference can be found here: `SystemTap Language
-Reference <http://sourceware.org/systemtap/langref/>`__
+Reference <https://sourceware.org/systemtap/langref/>`__
 
 Links to other SystemTap documents, tutorials, and examples can be found
 here: `SystemTap documentation
-page <http://sourceware.org/systemtap/documentation.html>`__
+page <https://sourceware.org/systemtap/documentation.html>`__
 
 Sysprof
 =======
@@ -2215,7 +2214,7 @@
 efficient software tracing.
 
 For information on LTTng in general, visit the `LTTng
-Project <http://lttng.org/lttng2.0>`__ site. You can find a "Getting
+Project <https://lttng.org/lttng2.0>`__ site. You can find a "Getting
 Started" link on this site that takes you to an LTTng Quick Start.
 
 blktrace
@@ -2366,7 +2365,7 @@
 The report shows each event that was
 found in the blktrace data, along with a summary of the overall block
 I/O traffic during the run. You can look at the
-`blkparse <http://linux.die.net/man/1/blkparse>`__ manpage to learn the
+`blkparse <https://linux.die.net/man/1/blkparse>`__ manpage to learn the
 meaning of each field displayed in the trace listing.
 
 Live Mode
@@ -2565,11 +2564,11 @@
 Online versions of the man pages for the commands discussed in this
 section can be found here:
 
--  http://linux.die.net/man/8/blktrace
+-  https://linux.die.net/man/8/blktrace
 
--  http://linux.die.net/man/1/blkparse
+-  https://linux.die.net/man/1/blkparse
 
--  http://linux.die.net/man/8/btrace
+-  https://linux.die.net/man/8/btrace
 
 The above manpages, along with manpages for the other blktrace utilities
 (btt, blkiomon, etc) can be found in the /doc directory of the blktrace
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 5a30ce3..a152dca 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -278,7 +278,7 @@
 This class is used to give a minor performance boost during the build.
 However, using the class can lead to unexpected side-effects. Thus, it
 is recommended that you do not use this class. See
-http://ccache.samba.org/ for information on the C/C++ Compiler
+https://ccache.samba.org/ for information on the C/C++ Compiler
 Cache.
 
 .. _ref-classes-chrpath:
@@ -1374,36 +1374,36 @@
 ``kernel-fitimage.bbclass``
 ===========================
 
-The ``kernel-fitimage`` class provides support to pack a kernel Image,
+The ``kernel-fitimage`` class provides support to pack a kernel image,
 device trees and a RAM disk into a single FIT image. In theory, a FIT
-image can support any number of kernels, RAM disks and device-trees.
+image can support any number of kernels, RAM disks and device trees.
 However, ``kernel-fitimage`` currently only supports
 limited usescases: just one kernel image, an optional RAM disk, and
-any number of device tree.
+any number of device trees.
 
 To create a FIT image, it is required that :term:`KERNEL_CLASSES`
-is set to "kernel-fitimage" and :term:`KERNEL_IMAGETYPE`
+is set to include "kernel-fitimage" and :term:`KERNEL_IMAGETYPE`
 is set to "fitImage".
 
-The options for the device tree compiler passed to mkimage -D feature
+The options for the device tree compiler passed to ``mkimage -D``
 when creating the FIT image are specified using the
 :term:`UBOOT_MKIMAGE_DTCOPTS` variable.
 
 Only a single kernel can be added to the FIT image created by
 ``kernel-fitimage`` and the kernel image in FIT is mandatory. The
-address where the kernel image is to be loaded by U-boot is
+address where the kernel image is to be loaded by U-Boot is
 specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by
 :term:`UBOOT_ENTRYPOINT`.
 
 Multiple device trees can be added to the FIT image created by
 ``kernel-fitimage`` and the device tree is optional.
-The address where the device tree is to be loaded by U-boot is
+The address where the device tree is to be loaded by U-Boot is
 specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays
 and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries.
 
 Only a single RAM disk can be added to the FIT image created by
 ``kernel-fitimage`` and the RAM disk in FIT is optional.
-The address where the RAM disk image is to be loaded by U-boot
+The address where the RAM disk image is to be loaded by U-Boot
 is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by
 :term:`UBOOT_RD_ENTRYPOINT`. The ramdisk is added to FIT image when
 :term:`INITRAMFS_IMAGE` is specified.
@@ -2581,7 +2581,7 @@
 :term:`SYSTEMD_BOOT_TIMEOUT` variables.
 
 You can also see the `Systemd-boot
-documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__
+documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__
 for more information.
 
 .. _ref-classes-terminal:
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index f67c538..34b26ee 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -55,9 +55,9 @@
 **Q:** Are there any products built using the OpenEmbedded build system?
 
 **A:** The software running on the `Vernier
-LabQuest <http://vernier.com/labquest/>`__ is built using the
+LabQuest <https://vernier.com/labquest/>`__ is built using the
 OpenEmbedded build system. See the `Vernier
-LabQuest <http://www.vernier.com/products/interfaces/labq/>`__ website
+LabQuest <https://www.vernier.com/products/interfaces/labq/>`__ website
 for more information. There are a number of pre-production devices using
 the OpenEmbedded build system and the Yocto Project team announces them
 as soon as they are released.
@@ -273,7 +273,7 @@
 particular, "external-\*" refers to external toolchains. One example is
 the Sourcery G++ Toolchain. The support for this toolchain resides in
 the separate ``meta-sourcery`` layer at
-http://github.com/MentorEmbedded/meta-sourcery/.
+https://github.com/MentorEmbedded/meta-sourcery/.
 
 In addition to the toolchain configuration, you also need a
 corresponding toolchain recipe file. This recipe file needs to package
diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst
index 5e9374e..cf5cc11 100644
--- a/poky/documentation/ref-manual/images.rst
+++ b/poky/documentation/ref-manual/images.rst
@@ -37,9 +37,9 @@
    all the pieces required to run builds using the build system as well
    as the build system itself. You can boot and run the image using
    either the `VMware
-   Player <http://www.vmware.com/products/player/overview.html>`__ or
+   Player <https://www.vmware.com/products/player/overview.html>`__ or
    `VMware
-   Workstation <http://www.vmware.com/products/workstation/overview.html>`__.
+   Workstation <https://www.vmware.com/products/workstation/overview.html>`__.
    For more information on this image, see the :yocto_home:`Build
    Appliance </software-item/build-appliance>` page
    on the Yocto Project website.
diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst
index bb9c046..472820f 100644
--- a/poky/documentation/ref-manual/kickstart.rst
+++ b/poky/documentation/ref-manual/kickstart.rst
@@ -24,7 +24,7 @@
 Kickstart commands are based on the Fedora kickstart versions but with
 modifications to reflect Wic capabilities. You can see the original
 documentation for those commands at the following link:
-http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html
+https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html
 
 Command: part or partition
 ==========================
@@ -164,7 +164,7 @@
 -  ``--part-type``: This option is a Wic-specific option that
    specifies the partition type globally unique identifier (GUID) for
    GPT partitions. You can find the list of partition type GUIDs at
-   http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs.
+   https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs.
 
 -  ``--use-uuid``: This option is a Wic-specific option that causes
    Wic to generate a random GUID for the partition. The generated
diff --git a/poky/documentation/ref-manual/migration-1.7.rst b/poky/documentation/ref-manual/migration-1.7.rst
index 19275b3..54544e4 100644
--- a/poky/documentation/ref-manual/migration-1.7.rst
+++ b/poky/documentation/ref-manual/migration-1.7.rst
@@ -190,7 +190,7 @@
 
 The following recipes have been removed:
 
--  ``x-load``: This recipe has been superseded by U-boot SPL for all
+-  ``x-load``: This recipe has been superseded by U-Boot SPL for all
    Cortex-based TI SoCs. For legacy boards, the ``meta-ti`` layer, which
    contains a maintained recipe, should be used instead.
 
diff --git a/poky/documentation/ref-manual/migration-2.1.rst b/poky/documentation/ref-manual/migration-2.1.rst
index e8b3ada..861d048 100644
--- a/poky/documentation/ref-manual/migration-2.1.rst
+++ b/poky/documentation/ref-manual/migration-2.1.rst
@@ -89,7 +89,7 @@
 having ``libexecdir`` change between recipes makes it very difficult for
 different recipes to invoke binaries that have been installed into
 ``libexecdir``. The Filesystem Hierarchy Standard (i.e.
-http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) now
+https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) now
 recognizes the use of ``${prefix}/libexec/``, giving distributions the
 choice between ``${prefix}/lib`` or ``${prefix}/libexec`` without
 breaking FHS.
diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst
index ac247dc..5c6fecf 100644
--- a/poky/documentation/ref-manual/migration-2.2.rst
+++ b/poky/documentation/ref-manual/migration-2.2.rst
@@ -28,8 +28,8 @@
 introduces the new :term:`SYSROOT_DIRS`,
 :term:`SYSROOT_DIRS_NATIVE`, and
 :term:`SYSROOT_DIRS_BLACKLIST`. See the
-`v2 patch series on the OE-Core Mailing
-List <http://lists.openembedded.org/pipermail/openembedded-core/2016-May/121365.html>`__
+:oe_lists:`v2 patch series on the OE-Core Mailing List
+</pipermail/openembedded-core/2016-May/121365.html>`
 for additional information.
 
 .. _migration-2.2-removal-of-old-images-from-tmp-deploy-now-enabled:
diff --git a/poky/documentation/ref-manual/migration-2.3.rst b/poky/documentation/ref-manual/migration-2.3.rst
index 3e97581..04b11da 100644
--- a/poky/documentation/ref-manual/migration-2.3.rst
+++ b/poky/documentation/ref-manual/migration-2.3.rst
@@ -238,7 +238,7 @@
 .. note::
 
    You can ``find meta-gplv2`` layer in the OpenEmbedded layer index at
-   https://layers.openembedded.org/layerindex/branch/master/layer/meta-gplv2/.
+   :oe_layer:`/meta-gplv2`.
 
 These relocated GPLv2 recipes do not receive the same level of
 maintenance as other core recipes. The recipes do not get security fixes
@@ -274,7 +274,7 @@
    fixed.
 
    For more information, see the `DNF
-   Documentation <http://dnf.readthedocs.io/en/latest/>`__.
+   Documentation <https://dnf.readthedocs.io/en/latest/>`__.
 
 -  Rpm 5.x is replaced with Rpm 4.x. This is done for two major reasons:
 
diff --git a/poky/documentation/ref-manual/migration-2.7.rst b/poky/documentation/ref-manual/migration-2.7.rst
index 7e628fc..5af5947 100644
--- a/poky/documentation/ref-manual/migration-2.7.rst
+++ b/poky/documentation/ref-manual/migration-2.7.rst
@@ -159,7 +159,7 @@
    from the top-level ``scripts`` directory.
 
 -  Perl now builds for the target using
-   `perl-cross <http://arsv.github.io/perl-cross/>`_ for better
+   `perl-cross <https://arsv.github.io/perl-cross/>`_ for better
    maintainability and improved build performance. This change should
    not present any problems unless you have heavily customized your Perl
    recipe.
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index 54977dc..6cb767d 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -227,7 +227,7 @@
       CFLAGS_append = " -fPIC "
 
    For more information on text relocations at runtime, see
-   http://www.akkadia.org/drepper/textrelocs.html.
+   https://www.akkadia.org/drepper/textrelocs.html.
 
     
 .. _qa-check-ldflags:
diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst
index 77c3678..7554164 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -52,7 +52,7 @@
 
 -  The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
 
-For information on Bugzilla in general, see http://www.bugzilla.org/about/.
+For information on Bugzilla in general, see https://www.bugzilla.org/about/.
 
 .. _resources-mailinglist:
 
@@ -118,8 +118,7 @@
    distribution from which the Yocto Project derives its build system
    (Poky) and to which it contributes.
 
--  :oe_home:`BitBake </wiki/BitBake>`\ *:* The tool
-   used to process metadata.
+-  :oe_wiki:`BitBake </BitBake>`\ *:* The tool used to process metadata.
 
 -  :doc:`BitBake User Manual <bitbake:index>`\ *:* A comprehensive
    guide to the BitBake tool. If you want information on BitBake, see
@@ -194,5 +193,5 @@
    available for Yocto Project and Poky discussions: ``#yocto`` and
    ``#poky``, respectively.
 
--  `Quick EMUlator (QEMU) <http://wiki.qemu.org/Index.html>`__\ *:* An
+-  `Quick EMUlator (QEMU) <https://wiki.qemu.org/Index.html>`__\ *:* An
    open-source machine emulator and virtualizer.
diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst
index c07dd4b..9669620 100644
--- a/poky/documentation/ref-manual/terms.rst
+++ b/poky/documentation/ref-manual/terms.rst
@@ -349,7 +349,8 @@
      Source Directory is derived from the Yocto Project release tarball.
      For example, downloading and unpacking
      :yocto_dl:`/releases/yocto/&DISTRO_REL_TAG;/&YOCTO_POKY;.tar.bz2`
-     results in a Source Directory whose root folder is named ``poky``.
+     results in a Source Directory whose root folder is named
+     ``&YOCTO_POKY;``.
 
      It is important to understand the differences between the Source
      Directory created by unpacking a released tarball as compared to
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 8c6cc46..4ce2648 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -2538,6 +2538,13 @@
       For guidance on how to create your own file permissions settings
       table file, examine the existing ``fs-perms.txt``.
 
+   :term:`FIT_DESC`
+      Specifies the description string encoded into a fitImage. The default
+      value is set by the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>`
+      class as follows::
+
+         FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
+
    :term:`FIT_GENERATE_KEYS`
       Decides whether to generate the keys for signing fitImage if they
       don't already exist. The keys are created in ``UBOOT_SIGN_KEYDIR``.
@@ -2568,6 +2575,13 @@
       Size of private key in number of bits used in fitImage. The default
       value is "2048".
 
+   :term:`FIT_SIGN_INDIVIDUAL`
+      If set to "1", then the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>`
+      class will sign the kernel, dtb and ramdisk images individually in addition
+      to signing the fitImage itself. This could be useful if you are
+      intending to verify signatures in another context than booting via
+      U-Boot.
+
    :term:`FONT_EXTRA_RDEPENDS`
       When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
       this variable specifies the runtime dependencies for font packages.
@@ -2648,7 +2662,7 @@
          GROUPADD_PARAM_${PN} = "-r netdev"
 
       For information on the standard Linux shell command
-      ``groupadd``, see http://linux.die.net/man/8/groupadd.
+      ``groupadd``, see https://linux.die.net/man/8/groupadd.
 
    :term:`GROUPMEMS_PARAM`
       When inheriting the :ref:`useradd <ref-classes-useradd>` class,
@@ -2657,7 +2671,7 @@
       of a group when the package is installed.
 
       For information on the standard Linux shell command ``groupmems``,
-      see http://linux.die.net/man/8/groupmems.
+      see https://linux.die.net/man/8/groupmems.
 
    :term:`GRUB_GFXSERIAL`
       Configures the GNU GRand Unified Bootloader (GRUB) to have graphics
@@ -3870,6 +3884,15 @@
 
          KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
 
+   :term:`KERNEL_DTC_FLAGS`
+      Specifies the ``dtc`` flags that are passed to the Linux kernel build
+      system when generating the device trees (via ``DTC_FLAGS`` environment
+      variable).
+
+      In order to use this variable, the
+      :ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class must
+      be inherited.
+
    :term:`KERNEL_EXTRA_ARGS`
       Specifies additional ``make`` command-line arguments the OpenEmbedded
       build system passes on when compiling the kernel.
@@ -3983,8 +4006,9 @@
       when building the kernel and is passed to ``make`` as the target to
       build.
 
-      If you want to build an alternate kernel image type, use the
-      :term:`KERNEL_ALT_IMAGETYPE` variable.
+      If you want to build an alternate kernel image type in addition to that
+      specified by ``KERNEL_IMAGETYPE``, use the :term:`KERNEL_ALT_IMAGETYPE`
+      variable.
 
    :term:`KERNEL_MODULE_AUTOLOAD`
       Lists kernel modules that need to be auto-loaded during boot.
@@ -4679,7 +4703,7 @@
       See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information.
 
    module_conf
-      Specifies `modprobe.d <http://linux.die.net/man/5/modprobe.d>`_
+      Specifies `modprobe.d <https://linux.die.net/man/5/modprobe.d>`_
       syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf``
       file.
 
@@ -7604,7 +7628,7 @@
          SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf"
 
       For information on Systemd-boot, see the `Systemd-boot
-      documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
+      documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
 
    :term:`SYSTEMD_BOOT_ENTRIES`
       When :term:`EFI_PROVIDER` is set to
@@ -7618,7 +7642,7 @@
           SYSTEMD_BOOT_ENTRIES ?= ""
 
       For information on Systemd-boot, see the `Systemd-boot
-      documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
+      documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
 
    :term:`SYSTEMD_BOOT_TIMEOUT`
       When :term:`EFI_PROVIDER` is set to
@@ -7631,7 +7655,7 @@
          SYSTEMD_BOOT_TIMEOUT ?= "10"
 
       For information on Systemd-boot, see the `Systemd-boot
-      documentation <http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
+      documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
 
    :term:`SYSTEMD_PACKAGES`
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
@@ -7662,7 +7686,7 @@
       When using
       :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
       specifies a space-separated list of the virtual terminals that should
-      run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
+      run a `getty <https://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
       (allowing login), assuming :term:`USE_VT` is not set to
       "0".
 
@@ -7886,7 +7910,7 @@
       toolchain. One example is the Sourcery G++ Toolchain. The support for
       this toolchain resides in the separate Mentor Graphics
       ``meta-sourcery`` layer at
-      http://github.com/MentorEmbedded/meta-sourcery/.
+      https://github.com/MentorEmbedded/meta-sourcery/.
 
       The layer's ``README`` file contains information on how to use the
       Sourcery G++ Toolchain as an external toolchain. In summary, you must
@@ -8389,21 +8413,21 @@
       In this example, "sd" is selected as the configuration of the possible four for the
       ``UBOOT_MACHINE``. The "sd" configuration defines
       "mx6qsabreauto_config" as the value for ``UBOOT_MACHINE``, while the
-      "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-boot image.
+      "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-Boot image.
 
       For more information on how the ``UBOOT_CONFIG`` is handled, see the
       :ref:`uboot-config <ref-classes-uboot-config>`
       class.
 
    :term:`UBOOT_DTB_LOADADDRESS`
-      Specifies the load address for the dtb image used by U-boot. During FIT
+      Specifies the load address for the dtb image used by U-Boot. During FIT
       image creation, the ``UBOOT_DTB_LOADADDRESS`` variable is used in
       :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify
       the load address to be used in
       creating the dtb sections of Image Tree Source for the FIT image.
 
    :term:`UBOOT_DTBO_LOADADDRESS`
-      Specifies the load address for the dtbo image used by U-boot.  During FIT
+      Specifies the load address for the dtbo image used by U-Boot.  During FIT
       image creation, the ``UBOOT_DTBO_LOADADDRESS`` variable is used in
       :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used in
       creating the dtbo sections of Image Tree Source for the FIT image.
@@ -8440,9 +8464,29 @@
       Specifies the target called in the ``Makefile``. The default target
       is "all".
 
+   :term:`UBOOT_MKIMAGE`
+      Specifies the name of the mkimage command as used by the
+      :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to assemble
+      the FIT image. This can be used to substitute an alternative command, wrapper
+      script or function if desired. The default is "uboot-mkimage".
+
    :term:`UBOOT_MKIMAGE_DTCOPTS`
       Options for the device tree compiler passed to mkimage '-D'
       feature while creating FIT image in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class.
+      If ``UBOOT_MKIMAGE_DTCOPTS`` is not set then kernel-fitimage will not
+      pass the ``-D`` option to mkimage.
+
+   :term:`UBOOT_MKIMAGE_SIGN`
+      Specifies the name of the mkimage command as used by the
+      :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to sign
+      the FIT image after it has been assembled (if enabled). This can be used
+      to substitute an alternative command, wrapper script or function if
+      desired. The default is "${:term:`UBOOT_MKIMAGE`}".
+
+   :term:`UBOOT_MKIMAGE_SIGN_ARGS`
+      Optionally specifies additional arguments for the
+      :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to pass to the
+      mkimage command when signing the FIT image.
 
    :term:`UBOOT_RD_ENTRYPOINT`
       Specifies the entrypoint for the RAM disk image.
@@ -8468,7 +8512,7 @@
       certificate used for signing FIT image.
 
    :term:`UBOOT_SIGN_KEYNAME`
-      The name of keys used for signing U-boot FIT image stored in
+      The name of keys used for signing U-Boot FIT image stored in
       :term:`UBOOT_SIGN_KEYDIR` directory. For e.g. dev.key key and dev.crt
       certificate stored in :term:`UBOOT_SIGN_KEYDIR` directory will have
       :term:`UBOOT_SIGN_KEYNAME` set to "dev".
@@ -8562,7 +8606,7 @@
       When using
       :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
       determines whether or not to run a
-      `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any
+      `getty <https://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any
       virtual terminals in order to enable logging in through those
       terminals.
 
@@ -8673,7 +8717,7 @@
 
       For information on the
       standard Linux shell command ``useradd``, see
-      http://linux.die.net/man/8/useradd.
+      https://linux.die.net/man/8/useradd.
 
    :term:`USERADD_UID_TABLES`
       Specifies a password file to use for obtaining static user
diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst
index 2546300..b409072 100644
--- a/poky/documentation/releases.rst
+++ b/poky/documentation/releases.rst
@@ -9,6 +9,7 @@
 *******************************
 
 - :yocto_docs:`3.2 Documentation </3.2>`
+- :yocto_docs:`3.2.1 Documentation </3.2.1>`
 
 ****************************
 3.1 'dunfell' Release Series
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index 66b12cd..e4b9b05 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -210,7 +210,7 @@
 3. *Develop and Test your Application:* At this point, you have the
    tools to develop your application. If you need to separately install
    and use the QEMU emulator, you can go to `QEMU Home
-   Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
+   Page <https://wiki.qemu.org/Main_Page>`__ to download and learn about
    the emulator. See the ":doc:`/dev-manual/qemu`" chapter in the
    Yocto Project Development Tasks Manual for information on using QEMU
    within the Yocto Project.
diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js
index fc901d3..754de2e 100644
--- a/poky/documentation/sphinx-static/switchers.js
+++ b/poky/documentation/sphinx-static/switchers.js
@@ -3,7 +3,7 @@
 
   var all_versions = {
     'dev': 'dev (3.3)',
-    '3.2': '3.2',
+    '3.2.1': '3.2.1',
     '3.1.4': '3.1.4',
     '3.0.4': '3.0.4',
     '2.7.4': '2.7.4',
diff --git a/poky/documentation/toaster-manual/intro.rst b/poky/documentation/toaster-manual/intro.rst
index c78b3f5..57e5b2b 100644
--- a/poky/documentation/toaster-manual/intro.rst
+++ b/poky/documentation/toaster-manual/intro.rst
@@ -27,7 +27,7 @@
    -  Browse layers listed in the various
       :ref:`layer sources <toaster-manual/reference:layer source>`
       that are available in your project (e.g. the OpenEmbedded Layer Index at
-      http://layers.openembedded.org/layerindex/).
+      :oe_layerindex:`/`).
 
    -  Browse images, recipes, and machines provided by those layers.
 
diff --git a/poky/documentation/toaster-manual/reference.rst b/poky/documentation/toaster-manual/reference.rst
index dfe5188..d2ab14c 100644
--- a/poky/documentation/toaster-manual/reference.rst
+++ b/poky/documentation/toaster-manual/reference.rst
@@ -24,12 +24,12 @@
 A layer index is a web application that contains information about a set
 of custom layers. A good example of an existing layer index is the
 OpenEmbedded Layer Index. A public instance of this layer index exists
-at http://layers.openembedded.org. You can find the code for this
+at :oe_layerindex:`/`. You can find the code for this
 layer index's web application at :yocto_git:`/layerindex-web/`.
 
 When you tie a layer source into Toaster, it can query the layer source
 through a
-`REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__
+`REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__
 API, store the information about the layers in the Toaster database, and
 then show the information to users. Users are then able to view that
 information and build layers from Toaster itself without worrying about
@@ -81,7 +81,7 @@
 index.
 
 In the previous section, the code for the OpenEmbedded Metadata Index
-(i.e. http://layers.openembedded.org) was referenced. You can use
+(i.e. :oe_layerindex:`/`) was referenced. You can use
 this code, which is at :yocto_git:`/layerindex-web/`, as a base to create
 your own layer index.
 
@@ -370,7 +370,7 @@
 Toaster has an API that allows remote management applications to
 directly query the state of the Toaster server and its builds in a
 machine-to-machine manner. This API uses the
-`REST <http://en.wikipedia.org/wiki/Representational_state_transfer>`__
+`REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__
 interface and the transfer of JSON files. For example, you might monitor
 a build inside a container through well supported known HTTP ports in
 order to easily access a Toaster server inside the container. In this
diff --git a/poky/documentation/toaster-manual/setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst
index 2cb7884..ded771e 100644
--- a/poky/documentation/toaster-manual/setup-and-use.rst
+++ b/poky/documentation/toaster-manual/setup-and-use.rst
@@ -462,9 +462,8 @@
 
 The Toaster web interface allows you to do the following:
 
--  Browse published layers in the `OpenEmbedded Layer
-   Index <http://layers.openembedded.org>`__ that are available for your
-   selected version of the build system.
+-  Browse published layers in the :oe_layerindex:`OpenEmbedded Layer Index <>`
+   that are available for your selected version of the build system.
 
 -  Import your own layers for building.
 
@@ -573,11 +572,11 @@
 compatible layers, other than the three core layers that come with the
 Yocto Project:
 
--  `openembedded-core <http://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/>`__
+-  :oe_layer:`openembedded-core </openembedded-core>`
 
--  `meta-poky <http://layers.openembedded.org/layerindex/branch/master/layer/meta-poky/>`__
+-  :oe_layer:`meta-poky </meta-poky>`
 
--  `meta-yocto-bsp <http://layers.openembedded.org/layerindex/branch/master/layer/meta-yocto-bsp/>`__
+-  :oe_layer:`meta-yocto-bsp </meta-yocto-bsp>`
 
 .. image:: figures/compatible-layers.png
    :align: center
diff --git a/poky/documentation/transitioning-to-a-custom-environment.rst b/poky/documentation/transitioning-to-a-custom-environment.rst
index 415f295..abbd74c 100644
--- a/poky/documentation/transitioning-to-a-custom-environment.rst
+++ b/poky/documentation/transitioning-to-a-custom-environment.rst
@@ -29,8 +29,8 @@
 
 #. **Find and acquire the best BSP for your target**.
    Use the :yocto_home:`Yocto Project curated layer index
-   </software-overview/layers/>` or even the `OpenEmbedded layer index
-   <https://layers.openembedded.org>`_ to find and acquire the best BSP for your
+   </software-overview/layers/>` or even the :oe_layerindex:`OpenEmbedded
+   layer index <>` to find and acquire the best BSP for your
    target board. The Yocto Project layer index BSPs are regularly validated. The
    best place to get your first BSP is from your silicon manufacturer or board
    vendor – they can point you to their most qualified efforts. In general, for
diff --git a/poky/documentation/what-i-wish-id-known.rst b/poky/documentation/what-i-wish-id-known.rst
index a051036..143f9fb 100644
--- a/poky/documentation/what-i-wish-id-known.rst
+++ b/poky/documentation/what-i-wish-id-known.rst
@@ -27,11 +27,10 @@
    to be responsible for your own updates.
 
 #. **Get to know the layer index:**
-   All layers can be found in the `layer index
-   <https://layers.openembedded.org/>`_. Layers which have applied for Yocto
-   Project Compatible status (structure continuity assurance and testing) can be
-   found in the :yocto_home:`Yocto Project Compatible index
-   </software-over/layer/>`.  Generally check the Compatible layer index first,
+   All layers can be found in the :oe_layerindex:`layer index <>`. Layers which
+   have applied for Yocto Project Compatible status (structure continuity
+   assurance and testing) can be found in the :yocto_home:`Yocto Project Compatible index
+   </software-over/layer/>`. Generally check the Compatible layer index first,
    and if you don't find the necessary layer check the general layer index. The
    layer index is an original artifact from the Open Embedded Project. As such,
    that index doesn't have the curating and testing that the Yocto Project
@@ -172,7 +171,7 @@
    * add an ssh server to an image (enable transferring of files to target)
    * know the anatomy of a recipe
    * know how to create and use layers
-   * find recipes (with the `OpenEmbedded Layer index <https://layers.openembedded.org>`_)
+   * find recipes (with the :oe_layerindex:`OpenEmbedded Layer index <>`)
    * understand difference between machine and distro settings
    * find and use the right BSP (machine) for your hardware
    * find examples of distro features and know where to set them