diff --git a/docs/plat/hikey.rst b/docs/plat/hikey.rst
new file mode 100644
index 0000000..027e14c
--- /dev/null
+++ b/docs/plat/hikey.rst
@@ -0,0 +1,156 @@
+Description
+===========
+
+HiKey is one of 96boards. Hisilicon Kirin6220 processor is installed on HiKey.
+
+More information are listed in `link`_.
+
+How to build
+============
+
+Code Locations
+--------------
+
+-  ARM Trusted Firmware:
+   `link <https://github.com/ARM-software/arm-trusted-firmware>`__
+
+-  edk2:
+   `link <https://github.com/96boards-hikey/edk2/tree/testing/hikey960_v2.5>`__
+
+-  OpenPlatformPkg:
+   `link <https://github.com/96boards-hikey/OpenPlatformPkg/tree/testing/hikey960_v1.3.4>`__
+
+-  l-loader:
+   `link <https://github.com/96boards-hikey/l-loader/tree/testing/hikey960_v1.2>`__
+
+-  uefi-tools:
+   `link <https://github.com/96boards-hikey/uefi-tools/tree/testing/hikey960_v1>`__
+
+-  atf-fastboot:
+   `link <https://github.com/96boards-hikey/atf-fastboot/tree/master>`__
+
+Build Procedure
+---------------
+
+-  Fetch all the above repositories into local host.
+   Make all the repositories in the same ${BUILD\_PATH}.
+
+-  Create the symbol link to OpenPlatformPkg in edk2.
+
+   .. code:: shell
+
+       $cd ${BUILD_PATH}/edk2
+       $ln -sf ../OpenPlatformPkg
+
+-  Prepare AARCH64 && AARCH32 toolchain. Prepare python.
+
+-  If your hikey hardware is built by CircuitCo, update *uefi-tools/platform.config* first. *(optional)*
+   **Uncomment the below sentence. Otherwise, UEFI can't output messages on serial
+   console on hikey.**
+
+   .. code:: shell
+
+       BUILDFLAGS=-DSERIAL_BASE=0xF8015000
+
+   If your hikey hardware is built by LeMarker, nothing to do.
+
+-  Build it as debug mode. Create your own build script file or you could refer to **build\_uefi.sh** in l-loader git repository.
+
+   .. code:: shell
+
+       BUILD_OPTION=DEBUG
+       export AARCH64_TOOLCHAIN=GCC5
+       export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools
+       export EDK2_DIR=${BUILD_PATH}/edk2
+       EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}
+       # Build fastboot for ARM Trust Firmware. It's used for recovery mode.
+       cd ${BUILD_PATH}/atf-fastboot
+       CROSS_COMPILE=aarch64-linux-gnu- make PLAT=hikey DEBUG=1
+       # Convert DEBUG/RELEASE to debug/release
+       FASTBOOT_BUILD_OPTION=$(echo ${BUILD_OPTION} | tr '[A-Z]' '[a-z]')
+       cd ${EDK2_DIR}
+       # Build UEFI & ARM Trust Firmware
+       ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey
+       # Generate l-loader.bin
+       cd ${BUILD_PATH}/l-loader
+       ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin
+       ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin
+       ln -sf ${BUILD_PATH}/atf-fastboot/build/hikey/${FASTBOOT_BUILD_OPTION}/bl1.bin fastboot.bin
+       python gen_loader.py -o l-loader.bin --img_bl1=bl1.bin --img_ns_bl1u=BL33_AP_UEFI.fd
+       arm-linux-gnueabihf-gcc -c -o start.o start.S
+       arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800 start.o -o loader
+       arm-linux-gnueabihf-objcopy -O binary loader temp
+       python gen_loader_hikey.py -o l-loader.bin --img_loader=temp --img_bl1=bl1.bin --img_ns_bl1u=fastboot.bin
+
+-  Generate partition table for aosp. The eMMC capacity is either 4GB or 8GB. Just change "aosp-4g" to "linux-4g" for debian.
+
+   .. code:: shell
+
+       $PTABLE=aosp-4g SECTOR_SIZE=512 bash -x generate_ptable.sh
+
+Setup Console
+-------------
+
+-  Install ser2net. Use telnet as the console since UEFI fails to display Boot Manager GUI in minicom. **If you don't need Boot Manager GUI, just ignore this section.**
+
+   .. code:: shell
+
+       $sudo apt-get install ser2net
+
+-  Configure ser2net.
+
+   .. code:: shell
+
+       $sudo vi /etc/ser2net.conf
+
+   Append one line for serial-over-USB in below.
+   *#ser2net.conf*
+
+   .. code:: shell
+
+       2004:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner
+
+-  Open the console.
+
+   .. code:: shell
+
+       $telnet localhost 2004
+
+   And you could open the console remotely, too.
+
+Flush images in recovery mode
+-----------------------------
+
+-  Make sure Pin3-Pin4 on J15 are connected for recovery mode. Then power on HiKey.
+
+-  Remove the modemmanager package. This package may cause the idt tool failure.
+
+   .. code:: shell
+
+       $sudo apt-get purge modemmanager
+
+-  Run the command to download l-loader.bin into HiKey.
+
+   .. code:: shell
+
+       $sudo python hisi-idt.py -d /dev/ttyUSB1 --img1 l-loader.bin
+
+-  Update images. All aosp or debian images could be fetched from `link <https://builds.96boards.org/>`__.
+
+   .. code:: shell
+
+       $sudo fastboot flash ptable prm_ptable.img
+       $sudo fastboot flash fastboot fip.bin
+       $sudo fastboot flash boot boot.img
+       $sudo fastboot flash cache cache.img
+       $sudo fastboot flash system system.img
+       $sudo  fastboot flash userdata userdata.img
+
+Boot UEFI in normal mode
+------------------------
+
+-  Make sure Pin3-Pin4 on J15 are open for normal boot mode. Then power on HiKey.
+
+-  Reference `link <https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md>`__
+
+.. _link: https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/Quickstart/README.md
diff --git a/docs/plat/hikey960.rst b/docs/plat/hikey960.rst
new file mode 100644
index 0000000..c28ef3a
--- /dev/null
+++ b/docs/plat/hikey960.rst
@@ -0,0 +1,172 @@
+Description
+===========
+
+HiKey960 is one of 96boards. Hisilicon Hi3660 processor is installed on HiKey960.
+
+More information are listed in `link`_.
+
+How to build
+============
+
+Code Locations
+--------------
+
+-  ARM Trusted Firmware:
+   `link <https://github.com/ARM-software/arm-trusted-firmware>`__
+
+-  edk2:
+   `link <https://github.com/96boards-hikey/edk2/tree/testing/hikey960_v2.5>`__
+
+-  OpenPlatformPkg:
+   `link <https://github.com/96boards-hikey/OpenPlatformPkg/tree/testing/hikey960_v1.3.4>`__
+
+-  l-loader:
+   `link <https://github.com/96boards-hikey/l-loader/tree/testing/hikey960_v1.2>`__
+
+-  uefi-tools:
+   `link <https://github.com/96boards-hikey/uefi-tools/tree/hikey960_v1>`__
+
+Build Procedure
+---------------
+
+-  Fetch all the above 5 repositories into local host.
+   Make all the repositories in the same ${BUILD\_PATH}.
+
+-  Create the symbol link to OpenPlatformPkg in edk2.
+
+   .. code:: shell
+
+       $cd ${BUILD_PATH}/edk2
+       $ln -sf ../OpenPlatformPkg
+
+-  Prepare AARCH64 toolchain.
+
+-  If your hikey960 hardware is v1, update *uefi-tools/platform.config* first. *(optional)*
+   **Uncomment the below sentence. Otherwise, UEFI can't output messages on serial
+   console on hikey960 v1.**
+
+   .. code:: shell
+
+       BUILDFLAGS=-DSERIAL_BASE=0xFDF05000
+
+   If your hikey960 hardware is v2 or newer, nothing to do.
+
+-  Build it as debug mode. Create script file for build.
+
+   .. code:: shell
+
+       BUILD_OPTION=DEBUG
+       export AARCH64_TOOLCHAIN=GCC48
+       export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools
+       export EDK2_DIR=${BUILD_PATH}/edk2
+       EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey960/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}
+       cd ${EDK2_DIR}
+       # Build UEFI & ARM Trust Firmware
+       ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey960
+       # Generate l-loader.bin
+       cd ${BUILD_PATH}/l-loader
+       ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin
+       ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin
+       ln -sf ${EDK2_OUTPUT_DIR}/FV/BL33_AP_UEFI.fd
+       python gen_loader.py -o l-loader.bin --img_bl1=bl1.bin --img_ns_bl1u=BL33_AP_UEFI.fd
+
+-  Generate partition table.
+   *Make sure that you're using the sgdisk in the l-loader directory.*
+
+   .. code:: shell
+
+       $PTABLE=aosp-32g SECTOR_SIZE=4096 SGDISK=./sgdisk bash -x generate_ptable.sh
+
+Setup Console
+-------------
+
+-  Install ser2net. Use telnet as the console since UEFI will output window
+   that fails to display in minicom.
+
+   .. code:: shell
+
+       $sudo apt-get install ser2net
+
+-  Configure ser2net.
+
+   .. code:: shell
+
+       $sudo vi /etc/ser2net.conf
+
+   Append one line for serial-over-USB in *#ser2net.conf*
+
+   ::
+
+       2004:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner
+
+-  Open the console.
+
+   .. code:: shell
+
+       $telnet localhost 2004
+
+   And you could open the console remotely, too.
+
+Boot UEFI in recovery mode
+--------------------------
+
+-  Fetch that are used in recovery mode. The code location is in below.
+   `link <https://github.com/96boards-hikey/tools-images-hikey960>`__
+
+-  Generate l-loader.bin.
+
+   .. code:: shell
+
+       $cd tools-images-hikey960
+       $ln -sf ${BUILD_PATH}/l-loader/l-loader.bin
+
+-  Prepare config file.
+
+   .. code:: shell
+
+       $vi config
+       # The content of config file
+       ./sec_user_xloader.img 0x00020000
+       ./sec_uce_boot.img 0x6A908000
+       ./l-loader.bin 0x1AC00000
+
+-  Remove the modemmanager package. This package may causes hikey\_idt tool failure.
+
+   .. code:: shell
+
+       $sudo apt-get purge modemmanager
+
+-  Run the command to download l-loader.bin into HiKey960.
+
+   .. code:: shell
+
+       $sudo ./hikey_idt -c config -p /dev/ttyUSB1
+
+-  UEFI running in recovery mode.
+   When prompt '.' is displayed on console, press hotkey 'f' in keyboard. Then Android fastboot app is running.
+   The timeout of prompt '.' is 10 seconds.
+
+-  Update images.
+
+   .. code:: shell
+
+       $sudo fastboot flash ptable prm_ptable.img
+       $sudo fastboot flash xloader sec_xloader.img
+       $sudo fastboot flash fastboot l-loader.bin
+       $sudo fastboot flash fip fip.bin
+       $sudo fastboot flash boot boot.img
+       $sudo fastboot flash cache cache.img
+       $sudo fastboot flash system system.img
+       $sudo fastboot flash userdata userdata.img
+
+-  Notice: UEFI could also boot kernel in recovery mode, but BL31 isn't loaded in
+   recovery mode.
+
+Boot UEFI in normal mode
+------------------------
+
+-  Make sure "Boot Mode" switch is OFF for normal boot mode. Then power on HiKey960.
+
+-  Reference `link <https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md>`__
+
+.. _link: http://www.96boards.org/documentation/ConsumerEdition/HiKey960/README.md
diff --git a/docs/plat/nvidia-tegra.rst b/docs/plat/nvidia-tegra.rst
new file mode 100644
index 0000000..7aac7e5
--- /dev/null
+++ b/docs/plat/nvidia-tegra.rst
@@ -0,0 +1,98 @@
+Tegra SoCs - Overview
+=====================
+
+-  .. rubric:: T210
+      :name: t210
+
+T210 has Quad ARM® Cortex®-A57 cores in a switched configuration with a
+companion set of quad ARM Cortex-A53 cores. The Cortex-A57 and A53 cores
+support ARMv8, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
+including legacy ARMv7 applications. The Cortex-A57 processors each have
+48 KB Instruction and 32 KB Data Level 1 caches; and have a 2 MB shared
+Level 2 unified cache. The Cortex-A53 processors each have 32 KB Instruction
+and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache.
+
+-  .. rubric:: T132
+      :name: t132
+
+Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is
+fully ARMv8 architecture compatible. Each of the two Denver cores
+implements a 7-way superscalar microarchitecture (up to 7 concurrent
+micro-ops can be executed per clock), and includes a 128KB 4-way L1
+instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2
+cache, which services both cores.
+
+Denver implements an innovative process called Dynamic Code Optimization,
+which optimizes frequently used software routines at runtime into dense,
+highly tuned microcode-equivalent routines. These are stored in a
+dedicated, 128MB main-memory-based optimization cache. After being read
+into the instruction cache, the optimized micro-ops are executed,
+re-fetched and executed from the instruction cache as long as needed and
+capacity allows.
+
+Effectively, this reduces the need to re-optimize the software routines.
+Instead of using hardware to extract the instruction-level parallelism
+(ILP) inherent in the code, Denver extracts the ILP once via software
+techniques, and then executes those routines repeatedly, thus amortizing
+the cost of ILP extraction over the many execution instances.
+
+Denver also features new low latency power-state transitions, in addition
+to extensive power-gating and dynamic voltage and clock scaling based on
+workloads.
+
+Directory structure
+===================
+
+-  plat/nvidia/tegra/common - Common code for all Tegra SoCs
+-  plat/nvidia/tegra/soc/txxx - Chip specific code
+
+Trusted OS dispatcher
+=====================
+
+Tegra supports multiple Trusted OS', Trusted Little Kernel (TLK) being one of
+them. In order to include the 'tlkd' dispatcher in the image, pass 'SPD=tlkd'
+on the command line while preparing a bl31 image. This allows other Trusted OS
+vendors to use the upstream code and include their dispatchers in the image
+without changing any makefiles.
+
+Preparing the BL31 image to run on Tegra SoCs
+=============================================
+
+.. code:: shell
+
+    CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf- make PLAT=tegra \
+    TARGET_SOC=<target-soc e.g. t210|t132> SPD=<dispatcher e.g. tlkd> bl31
+
+Platforms wanting to use different TZDRAM\_BASE, can add ``TZDRAM_BASE=<value>``
+to the build command line.
+
+The Tegra platform code expects a pointer to the following platform specific
+structure via 'x1' register from the BL2 layer which is used by the
+bl31\_early\_platform\_setup() handler to extract the TZDRAM carveout base and
+size for loading the Trusted OS and the UART port ID to be used. The Tegra
+memory controller driver programs this base/size in order to restrict NS
+accesses.
+
+typedef struct plat\_params\_from\_bl2 {
+/\* TZ memory size */
+uint64\_t tzdram\_size;
+/* TZ memory base */
+uint64\_t tzdram\_base;
+/* UART port ID \*/
+int uart\_id;
+} plat\_params\_from\_bl2\_t;
+
+Power Management
+================
+
+The PSCI implementation expects each platform to expose the 'power state'
+parameter to be used during the 'SYSTEM SUSPEND' call. The state-id field
+is implementation defined on Tegra SoCs and is preferably defined by
+tegra\_def.h.
+
+Tegra configs
+=============
+
+-  'tegra\_enable\_l2\_ecc\_parity\_prot': This flag enables the L2 ECC and Parity
+   Protection bit, for ARM Cortex-A57 CPUs, during CPU boot. This flag will
+   be enabled by Tegrs SoCs during 'Cluster power up' or 'System Suspend' exit.
diff --git a/docs/plat/qemu.rst b/docs/plat/qemu.rst
new file mode 100644
index 0000000..4e2cd7c
--- /dev/null
+++ b/docs/plat/qemu.rst
@@ -0,0 +1,48 @@
+ARM Trusted Firmware for QEMU virt ARMv8-A
+==========================================
+
+ARM Trusted Firmware implements the EL3 firmware layer for QEMU virt
+ARMv8-A. BL1 is used as the BootROM, supplied with the -bios argument.
+When QEMU starts all CPUs are released simultaneously, BL1 selects a
+primary CPU to handle the boot and the secondaries are placed in a polling
+loop to be released by normal world via PSCI.
+
+BL2 edits the Flattened Device Tree, FDT, generated by QEMU at run-time to
+add a node describing PSCI and also enable methods for the CPUs.
+
+An ARM64 defonfig v4.5 Linux kernel is known to boot, FTD doesn't need to be
+provided as it's generated by QEMU.
+
+Current limitations:
+
+-  Only cold boot is supported
+-  No build instructions for QEMU\_EFI.fd and rootfs-arm64.cpio.gz
+-  No instructions for how to load a BL32 (Secure Payload)
+
+``QEMU_EFI.fd`` can be dowloaded from
+http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-KERNEL-AARCH64/RELEASE_GCC49/QEMU_EFI.fd
+
+Boot binaries, except BL1, are primarily loaded via semi-hosting so all
+binaries has to reside in the same directory as QEMU is started from. This
+is conveniently achieved with symlinks the local names as:
+
+-  ``bl2.bin`` -> BL2
+-  ``bl31.bin`` -> BL31
+-  ``bl33.bin`` -> BL33 (``QEMU_EFI.fd``)
+-  ``Image`` -> linux/Image
+
+To build:
+
+::
+
+    make CROSS_COMPILE=aarch64-none-elf- PLAT=qemu 
+
+To start (QEMU v2.6.0):
+
+::
+
+    qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57  \
+        -kernel Image                           \
+        -append console=ttyAMA0,38400 keep_bootcon root=/dev/vda2   \
+        -initrd rootfs-arm64.cpio.gz -smp 2 -m 1024 -bios bl1.bin   \
+        -d unimp -semihosting-config enable,target=native
diff --git a/docs/plat/socionext-uniphier.rst b/docs/plat/socionext-uniphier.rst
new file mode 100644
index 0000000..fb6ebe5
--- /dev/null
+++ b/docs/plat/socionext-uniphier.rst
@@ -0,0 +1,124 @@
+ARM Trusted Firmware for Socionext UniPhier SoCs
+================================================
+
+Socionext UniPhier ARMv8-A SoCs use ARM Trusted Firmware as the secure world
+firmware, supporting BL1, BL2, and BL31.
+
+UniPhier SoC family implements its internal boot ROM, so BL1 is used as pseudo
+ROM (i.e. runs in RAM). The internal boot ROM loads 64KB `1`_ image from a
+non-volatile storage to the on-chip SRAM. Unfortunately, BL1 does not fit in
+the 64KB limit if `Trusted Board Boot`_ (TBB) is enabled. To solve this problem,
+Socionext provides a first stage loader called `UniPhier BL`_. This loader runs
+in the on-chip SRAM, initializes the DRAM, expands BL1 there, and hands the
+control over to it. Therefore, all images of ARM Trusted Firmware run in DRAM.
+
+The UniPhier platform works with/without TBB. See below for the build process
+of each case. The image authentication for the UniPhier platform fully
+complies with the Trusted Board Boot Requirements (TBBR) specification.
+
+The UniPhier BL does not implement the authentication functionality, that is,
+it can not verify the BL1 image by itself. Instead, the UniPhier BL assures
+the BL1 validity in a different way; BL1 is GZIP-compressed and appended to
+the UniPhier BL. The concatenation of the UniPhier BL and the compressed BL1
+fits in the 64KB limit. The concatenated image is loaded by the boot ROM
+(and verified if the chip fuses are blown).
+
+::
+
+     to the lowest common denominator.
+
+Boot Flow
+---------
+
+#. The Boot ROM
+
+This is hard-wired ROM, so never corrupted. It loads the UniPhier BL (with
+compressed-BL1 appended) into the on-chip SRAM. If the SoC fuses are blown,
+the image is verified by the SoC's own method.
+
+#. UniPhier BL
+
+This runs in the on-chip SRAM. After the minimum SoC initialization and DRAM
+setup, it decompresses the appended BL1 image into the DRAM, then jumps to
+the BL1 entry.
+
+#. BL1
+
+This runs in the DRAM. It extracts BL2 from FIP (Firmware Image Package).
+If TBB is enabled, the BL2 is authenticated by the standard mechanism of ARM
+Trusted Firmware.
+
+#. BL2, BL31, and more
+
+They all run in the DRAM, and are authenticated by the standard mechanism if
+TBB is enabled. See `Firmware Design`_ for details.
+
+Basic Build
+-----------
+
+BL1 must be compressed for the reason above. The UniPhier's platform makefile
+provides a build target ``bl1_gzip`` for this.
+
+For a non-secure boot loader (aka BL33), U-Boot is well supported for UniPhier
+SoCs. The U-Boot image (``u-boot.bin``) must be built in advance. For the build
+procedure of U-Boot, refer to the document in the `U-Boot`_ project.
+
+To build minimum functionality for UniPhier (without TBB):
+
+::
+
+    make CROSS_COMPILE=<gcc-prefix> PLAT=uniphier BL33=<path-to-BL33> bl1_gzip fip
+
+Output images:
+
+-  ``bl1.bin.gzip``
+-  ``fip.bin``
+
+Optional features
+-----------------
+
+-  Trusted Board Boot
+
+`mbed TLS`_ is needed as the cryptographic and image parser modules.
+Refer to the `User Guide`_ for the appropriate version of mbed TLS.
+
+To enable TBB, add the following options to the build command:
+
+::
+
+      TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 MBEDTLS_DIR=<path-to-mbedtls>
+
+-  System Control Processor (SCP)
+
+If desired, FIP can include an SCP BL2 image. If BL2 finds an SCP BL2 image
+in FIP, BL2 loads it into DRAM and kicks the SCP. Most of UniPhier boards
+still work without SCP, but SCP provides better power management support.
+
+To include SCP\_BL2, add the following option to the build command:
+
+::
+
+      SCP_BL2=<path-to-SCP>
+
+-  BL32 (Secure Payload)
+
+To enable BL32, add the following option to the build command:
+
+::
+
+      SPD=<spd> BL32=<path-to-BL32>
+
+If you use TSP for BL32, ``BL32=<path-to-BL32>`` is not required. Just add the
+following:
+
+::
+
+      SPD=tspd
+
+.. _1: Some%20SoCs%20can%20load%2080KB,%20but%20the%20software%20implementation%20must%20be%20aligned
+.. _Trusted Board Boot: ../trusted-board-boot.rst
+.. _UniPhier BL: https://github.com/uniphier/uniphier-bl
+.. _Firmware Design: ../firmware-design.rst
+.. _U-Boot: https://www.denx.de/wiki/U-Boot
+.. _mbed TLS: https://tls.mbed.org/
+.. _User Guide: ../user-guide.rst
diff --git a/docs/plat/xilinx-zynqmp.rst b/docs/plat/xilinx-zynqmp.rst
new file mode 100644
index 0000000..b9c7825
--- /dev/null
+++ b/docs/plat/xilinx-zynqmp.rst
@@ -0,0 +1,67 @@
+ARM Trusted Firmware for Xilinx Zynq UltraScale+ MPSoC
+======================================================
+
+ARM Trusted Firmware implements the EL3 firmware layer for Xilinx Zynq
+UltraScale + MPSoC.
+The platform only uses the runtime part of ATF as ZynqMP already has a
+BootROM (BL1) and FSBL (BL2).
+
+BL31 is ATF.
+BL32 is an optional Secure Payload.
+BL33 is the non-secure world software (U-Boot, Linux etc).
+
+To build:
+
+.. code:: bash
+
+    make ERROR_DEPRECATED=1 CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp bl31
+
+To build bl32 TSP you have to rebuild bl31 too:
+
+.. code:: bash
+
+    make ERROR_DEPRECATED=1 CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp SPD=tspd bl31 bl32
+
+ZynqMP platform specific build options
+======================================
+
+-  ``ZYNQMP_ATF_MEM_BASE``: Specifies the base address of the bl31 binary.
+-  ``ZYNQMP_ATF_MEM_SIZE``: Specifies the size of the memory region of the bl31 binary.
+-  ``ZYNQMP_BL32_MEM_BASE``: Specifies the base address of the bl32 binary.
+-  ``ZYNQMP_BL32_MEM_SIZE``: Specifies the size of the memory region of the bl32 binary.
+
+-  ``ZYNQMP_CONSOLE``: Select the console driver. Options:
+
+   -  ``cadence``, ``cadence0``: Cadence UART 0
+   -  ``cadence1`` : Cadence UART 1
+
+FSBL->ATF Parameter Passing
+===========================
+
+The FSBL populates a data structure with image information for the ATF. The ATF
+uses that data to hand off to the loaded images. The address of the handoff data
+structure is passed in the ``PMU_GLOBAL.GLOBAL_GEN_STORAGE6`` register. The
+register is free to be used by other software once the ATF is bringing up
+further firmware images.
+
+Power Domain Tree
+=================
+
+The following power domain tree represents the power domain model used by the
+ATF for ZynqMP:
+
+::
+
+                    +-+
+                    |0|
+                    +-+
+         +-------+---+---+-------+
+         |       |       |       |
+         |       |       |       |
+         v       v       v       v
+        +-+     +-+     +-+     +-+
+        |0|     |1|     |2|     |3|
+        +-+     +-+     +-+     +-+
+
+The 4 leaf power domains represent the individual A53 cores, while resources
+common to the cluster are grouped in the power domain on the top.