diff --git a/documentation/poky-ref-manual/extendpoky.xml b/documentation/poky-ref-manual/extendpoky.xml
index ebd9804431..1f14d7c9b0 100644
--- a/documentation/poky-ref-manual/extendpoky.xml
+++ b/documentation/poky-ref-manual/extendpoky.xml
@@ -1072,6 +1072,126 @@
+
+ Building Multiple Architecture Libraries into One Image
+
+
+ By taking steps you can create a single image that contains more than
+ one library for different architectures.
+ This feature is called "Multilib".
+ This section overviews the process only.
+ For more detail on how to implement this feature, see the
+ Multilib wiki
+ page.
+
+
+
+ Preparing to use Multilib
+
+
+ In order to implement Multilib, you need to prepare your recipes and packages as
+ follows:
+
+ Use the BBCLASSEXTEND variable to enable
+ a recipe for Multilib.
+ See the meta/conf/multilib.conf configuration file
+ in the Yocto Project Files directory to see how this variable is used.
+
+ Define a global variable ${MLPREFIX}
+ to specify the libraries (e.g. "lib32-'" or
+ "lib64-").
+ Rename your recipe to be ${MLPREFIX}${PN}.
+
+ For any recipe that uses Multilib and specifies lists of
+ recipes or packages with variables such as DEPENDS,
+ RDEPENDS,
+ RPROVIDES, RRECOMMENDS,
+ PACKAGES, PACKAGES_DYNAMIC,
+ map those recipes or packages with ${MLPREFIX}.
+
+
+
+
+
+ Next, be sure that the correct cross-toolchain parameters are used
+ by setting DEFAULTTUNE_virtclass-multilib-xxx
+ in the local.conf configuration file in the
+ Yocto Project build directory.
+
+
+
+ If you are using the RPM Package Management System, you need to consider the
+ following:
+
+ Define the unique architecure for the Multilib packages, along with
+ creating a unique deploy folder under tmp/deploy/rpm in
+ the Yocto Project build directory.
+ For example, consider lib32 in a
+ qemux86-64 image.
+ The possible architectures in the system are "all", "qemux86_64", "lib32_qemux86_64",
+ and "lib32_x86".
+ Because the ${MLPREFIX} is stripped from
+ ${PN} during RPM packaging, the naming for a normal
+ RPM package and a Multilib RPM package in a qemux86-64
+ system resolves to something similar to bash-4.1-r2.x86_64.rpm and
+ bash-4.1.r2.lib32_x86.rpm, respectively.
+ When installing a Multilib image, the RPM backend first installs
+ the base image and then installs the Multilib libraries.
+
+
+
+
+ If you are using the IPK Package Management System, you need to consider the
+ following:
+
+ ${MLPREFIX} is not stripped from
+ ${PN} during IPK packaging, the naming for a normal
+ RPM package and a Multilib IPK package in a qemux86-64
+ system resolves to something like bash_4.1-r2.x86_64.ipk and
+ lib32-bash_4.1-rw_x86.ipk, respectively.
+ The IPK deploy folder is not modified with
+ ${MLPREFIX} because packages with and without
+ the Multilib feature can exist in the same folder due to the
+ ${PN} differences.
+ IPK defines a sanity check for Multilib installation using certain
+ rules for file comparison, overridden, etc.
+
+
+
+
+
+ Using Multilib
+
+
+ After you have set up the recipies and configurations to use the Multilib feature,
+ you are ready to build the image.
+ Follow these steps:
+
+ Make changes in your local.conf
+ configuration file in the Yocto Project build directory.
+ Here is an example:
+
+ MULTILIB_IMAGE(INSTALL = "lib32-connman"
+ require conf/multilib.con
+ MULTILIBS = "multilib:lib32"
+ DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+
+ Build the image using the BitBake command.
+ For example:
+
+ $ bitbake core-image-sato
+
+ If you want to build a particular recipe only,
+ use the BitBake command and specify the recipe only.
+ For example:
+
+ $ bitbake lib32-connman
+
+
+
+
+
+