diff --git a/docs/plat/hikey.rst b/docs/plat/hikey.rst
index 33e6514..5c0a927 100644
--- a/docs/plat/hikey.rst
+++ b/docs/plat/hikey.rst
@@ -11,7 +11,7 @@
 Code Locations
 --------------
 
--  ARM Trusted Firmware:
+-  Trusted Firmware-A:
    `link <https://github.com/ARM-software/arm-trusted-firmware>`__
 
 -  OP-TEE
@@ -76,13 +76,13 @@
        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.
+       # Build fastboot for Trusted Firmware-A. 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
+       # Build UEFI & Trusted Firmware-A
        ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware -s ../optee_os hikey
 
 -  Generate l-loader.bin and partition table for aosp. The eMMC capacity is either 8GB or 4GB. Just change "aosp-8g" to "linux-8g" for debian.
diff --git a/docs/plat/hikey960.rst b/docs/plat/hikey960.rst
index 63cfc92..7900b6d 100644
--- a/docs/plat/hikey960.rst
+++ b/docs/plat/hikey960.rst
@@ -11,7 +11,7 @@
 Code Locations
 --------------
 
--  ARM Trusted Firmware:
+-  Trusted Firmware-A:
    `link <https://github.com/ARM-software/arm-trusted-firmware>`__
 
 -  OP-TEE:
@@ -73,7 +73,7 @@
        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
+       # Build UEFI & Trusted Firmware-A
        ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware -s ../optee_os hikey960
 
 -  Generate l-loader.bin and partition table.
diff --git a/docs/plat/nvidia-tegra.rst b/docs/plat/nvidia-tegra.rst
index 7aac7e5..56dfacf 100644
--- a/docs/plat/nvidia-tegra.rst
+++ b/docs/plat/nvidia-tegra.rst
@@ -4,10 +4,10 @@
 -  .. 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
+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-A, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
+including legacy Armv7-A 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.
@@ -16,7 +16,7 @@
       :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
+fully Armv8-A 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
@@ -94,5 +94,5 @@
 =============
 
 -  '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
+   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/poplar.rst b/docs/plat/poplar.rst
index 0129478..5884ed9 100644
--- a/docs/plat/poplar.rst
+++ b/docs/plat/poplar.rst
@@ -5,7 +5,7 @@
 Edition TV Platform specification.
 
 The board features the Hi3798C V200 with an integrated quad-core 64-bit
-ARM Cortex A53 processor and high performance Mali T720 GPU, making it capable
+Arm Cortex A53 processor and high performance Mali T720 GPU, making it capable
 of running any commercial set-top solution based on Linux or Android.
 
 It supports a premium user experience with up to H.265 HEVC decoding of 4K
@@ -14,7 +14,7 @@
 ::
 
     SOC Hisilicon Hi3798CV200
-    CPU Quad-core ARM Cortex-A53 64 bit
+    CPU Quad-core Arm Cortex-A53 64 bit
     DRAM DDR3/3L/4 SDRAM interface, maximum 32-bit data width 2 GB
     USB Two USB 2.0 ports One USB 3.0 ports
     CONSOLE USB-micro port for console support
@@ -28,11 +28,11 @@
 
 At the start of the boot sequence, the bootROM executes the so called l-loader
 binary whose main role is to change the processor state to 64bit mode. This
-must  happen prior invoking the arm trusted  firmware:
+must happen prior to invoking Trusted Firmware-A:
 
 ::
 
-    l-loader --> arm_trusted_firmware --> u-boot
+    l-loader --> Trusted Firmware-A --> u-boot
 
 How to build
 ============
@@ -40,7 +40,7 @@
 Code Locations
 --------------
 
--  ARM Trusted Firmware:
+-  Trusted Firmware-A:
    `link <https://github.com/ARM-software/arm-trusted-firmware>`__
 
 -  l-loader:
diff --git a/docs/plat/qemu.rst b/docs/plat/qemu.rst
index 4e2cd7c..57ed629 100644
--- a/docs/plat/qemu.rst
+++ b/docs/plat/qemu.rst
@@ -1,8 +1,8 @@
-ARM Trusted Firmware for QEMU virt ARMv8-A
-==========================================
+Trusted Firmware-A 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.
+Trusted Firmware-A (TF-A) 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.
@@ -10,7 +10,7 @@
 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
+An ARM64 defconfig v4.5 Linux kernel is known to boot, FDT doesn't need to be
 provided as it's generated by QEMU.
 
 Current limitations:
diff --git a/docs/plat/rpi3.rst b/docs/plat/rpi3.rst
index 219faaf..c30110e 100644
--- a/docs/plat/rpi3.rst
+++ b/docs/plat/rpi3.rst
@@ -1,5 +1,5 @@
-Arm Trusted Firmware for Raspberry Pi 3
-=======================================
+Trusted Firmware-A for Raspberry Pi 3
+=====================================
 
 .. section-numbering::
     :suffix: .
@@ -7,16 +7,16 @@
 .. contents::
 
 The `Raspberry Pi 3`_ is an inexpensive single-board computer that contains four
-Cortex-A53 cores, which makes it possible to have a port of the Arm Trusted
-Firmware.
+Arm Cortex-A53 cores, which makes it possible to have a port of Trusted
+Firmware-A (TF-A).
 
-The following instructions explain how to use this port of the Trusted Firmware
-with the default distribution of `Raspbian`_ because that's the distribution
-officially supported by the Raspberry Pi Foundation. At the moment of writing
-this, the officially supported kernel is a AArch32 kernel. This doesn't mean
-that this port of the Trusted Firmware can't boot a AArch64 kernel. The `Linux
-tree fork`_ maintained by the Foundation can be compiled for AArch64 by
-following the steps in `AArch64 kernel build instructions`_.
+The following instructions explain how to use this port of the TF-A with the
+default distribution of `Raspbian`_ because that's the distribution officially
+supported by the Raspberry Pi Foundation. At the moment of writing this, the
+officially supported kernel is a AArch32 kernel. This doesn't mean that this
+port of TF-A can't boot a AArch64 kernel. The `Linux tree fork`_ maintained by
+the Foundation can be compiled for AArch64 by following the steps in
+`AArch64 kernel build instructions`_.
 
 **IMPORTANT NOTE**: This port isn't secure. All of the memory used is DRAM,
 which is available from both the Non-secure and Secure worlds. This port
@@ -46,15 +46,15 @@
   the cores are powered on at the same time and start at address **0x0**.
 
 This means that we can use the default AArch32 kernel provided in the official
-`Raspbian`_ distribution by renaming it to ``kernel8.img``, while the Trusted
-Firmware and anything else we need is in ``armstub8.bin``. This way we can
-forget about the default bootstrap code. When using a AArch64 kernel, it is only
-needed to make sure that the name on the SD card is ``kernel8.img``.
+`Raspbian`_ distribution by renaming it to ``kernel8.img``, while TF-A and
+anything else we need is in ``armstub8.bin``. This way we can forget about the
+default bootstrap code. When using a AArch64 kernel, it is only needed to make
+sure that the name on the SD card is ``kernel8.img``.
 
 Ideally, we want to load the kernel and have all cores available, which means
 that we need to make the secondary cores work in the way the kernel expects, as
 explained in `Secondary cores`_. In practice, a small bootstrap is needed
-between the Trusted Firmware and the kernel.
+between TF-A and the kernel.
 
 To get the most out of a AArch32 kernel, we want to boot it in Hypervisor mode
 in AArch32. This means that BL33 can't be in EL2 in AArch64 mode. The
@@ -66,7 +66,7 @@
 
 The file ``armstub8.bin`` contains BL1 and the FIP. It is needed to add padding
 between them so that the addresses they are loaded to match the ones specified
-when compiling the Trusted Firmware.
+when compiling TF-A.
 
 The device tree block is loaded by the VideoCore loader from an appropriate
 file, but we can specify the address it is loaded to in ``config.txt``.
@@ -87,8 +87,8 @@
 ``Documentation/arm64/booting.txt``.
 
 This means that we need to avoid the first 128 MiB of RAM when placing the
-Trusted Firmware images (and specially the first 32 MiB, as they are directly
-used to place the uncompressed AArch32 kernel image. This way, both AArch32 and
+TF-A images (and specially the first 32 MiB, as they are directly used to
+place the uncompressed AArch32 kernel image. This way, both AArch32 and
 AArch64 kernels can be placed at the same address.
 
 In the end, the images look like the following diagram when placed in memory.
@@ -143,18 +143,17 @@
 the DRAM. The memory reserved to be used by the VideoCore is always placed at
 the end of the DRAM, so this space isn't wasted.
 
-Considering the 128 MiB allocated to the GPU and the 16 MiB allocated for the
-Trusted Firmware, there are 880 MiB available for Linux.
+Considering the 128 MiB allocated to the GPU and the 16 MiB allocated for
+TF-A, there are 880 MiB available for Linux.
 
 Boot sequence
 ~~~~~~~~~~~~~
 
-The boot sequence of the Trusted Firmware is the usual one except when booting
-a AArch32 kernel. In that case, BL33 is booted in AArch32 Hypervisor mode so
-that it can jump to the kernel in the same mode and let it take over that
-privilege level. If BL33 was running in EL2 in AArch64 (as in the default
-bootflow of the Trusted Firmware) it could only jump to the kernel in AArch32 in
-Supervisor mode.
+The boot sequence of TF-A is the usual one except when booting an AArch32
+kernel. In that case, BL33 is booted in AArch32 Hypervisor mode so that it
+can jump to the kernel in the same mode and let it take over that privilege
+level. If BL33 was running in EL2 in AArch64 (as in the default bootflow of
+TF-A) it could only jump to the kernel in AArch32 in Supervisor mode.
 
 The `Linux kernel tree`_ has instructions on how to jump to the Linux kernel
 in ``Documentation/arm/Booting`` and ``Documentation/arm64/booting.txt``. The
@@ -168,9 +167,9 @@
 kernel. This mailbox is located at a different address in the AArch32 default
 kernel than in the AArch64 kernel.
 
-Also, this port of the Trusted Firmware has another Trusted Mailbox in Shared BL
-RAM. During cold boot, all secondary cores wait in a loop until they are given
-given an address to jump to in this Mailbox (``bl31_warm_entrypoint``).
+Also, this port of TF-A has another Trusted Mailbox in Shared BL RAM. During
+cold boot, all secondary cores wait in a loop until they are given given an
+address to jump to in this Mailbox (``bl31_warm_entrypoint``).
 
 Once BL31 has finished and the primary core has jumped to the BL33 payload, it
 has to call ``PSCI_CPU_ON`` to release the secondary CPUs from the wait loop.
@@ -188,11 +187,10 @@
 AArch32 toolchain is needed for the AArch32 bootstrap needed to load a 32-bit
 kernel.
 
-First, clone and compile `Raspberry Pi 3 Arm Trusted Firmware bootstrap`_.
-Choose the one needed for the architecture of your kernel.
+First, clone and compile `Raspberry Pi 3 TF-A bootstrap`_. Choose the one
+needed for the architecture of your kernel.
 
-Then compile the Arm Trusted Firmware. For a AArch32 kernel, use the following
-command line:
+Then compile TF-A. For a AArch32 kernel, use the following command line:
 
 .. code:: shell
 
@@ -219,8 +217,8 @@
     cat bl1.pad.bin build/rpi3/release/fip.bin > armstub8.bin
 
 The resulting file, ``armstub8.bin``, contains BL1 and the FIP in the place they
-need to be for the Trusted Firmware to boot correctly. Now, follow the
-instructions in `Setup SD card`_.
+need to be for TF-A to boot correctly. Now, follow the instructions in
+`Setup SD card`_.
 
 The following build options are supported:
 
@@ -235,17 +233,17 @@
   is reserved by the command line passed to the kernel.
 
 - ``RPI3_BL33_IN_AARCH32``: This port can load a AArch64 or AArch32 BL33 image.
-  By default this option is 0, which means that the Trusted Firmware will jump
-  to BL33 in EL2 in AArch64 mode. If set to 1, it will jump to BL33 in
-  Hypervisor in AArch32 mode.
+  By default this option is 0, which means that TF-A will jump to BL33 in EL2
+  in AArch64 mode. If set to 1, it will jump to BL33 in Hypervisor in AArch32
+  mode.
 
 The following is not currently supported:
 
-- AArch32 for the Trusted Firmware itself.
+- AArch32 for TF-A itself.
 
 - ``EL3_PAYLOAD_BASE``: The reason is that you can already load anything to any
   address by changing the file ``armstub8.bin``, so there's no point in using
-  the Trusted Firmware in this case.
+  TF-A in this case.
 
 - ``LOAD_IMAGE_V2=0``: Only version 2 is supported.
 
@@ -307,16 +305,16 @@
 1. Insert the SD card and open the ``boot`` partition.
 
 2. Rename ``kernel7.img`` to ``kernel8.img``. This tricks the VideoCore
-   bootloader into booting the Arm cores in AArch64 mode, like the Trusted
-   Firmware needs, even though the kernel is not compiled for AArch64.
+   bootloader into booting the Arm cores in AArch64 mode, like TF-A needs,
+   even though the kernel is not compiled for AArch64.
 
 3. Copy ``armstub8.bin`` here. When ``kernel8.img`` is available, The VideoCore
    bootloader will look for a file called ``armstub8.bin`` and load it at
    address **0x0** instead of a predefined one.
 
 4. Open ``cmdline.txt`` and add ``memmap=256M$16M`` to prevent the kernel from
-   using the memory needed by the Trusted Firmware. If you want to enable the
-   serial port "Mini UART", make sure that this file also contains
+   using the memory needed by TF-A. If you want to enable the serial port
+   "Mini UART", make sure that this file also contains
    ``console=serial0,115200 console=tty1``.
 
    Note that the 16 MiB reserved this way won't be available for Linux, the same
@@ -359,6 +357,6 @@
 .. _Linux kernel tree: https://github.com/torvalds/linux
 .. _Linux tree fork: https://github.com/raspberrypi/linux
 .. _Raspberry Pi 3: https://www.raspberrypi.org/products/raspberry-pi-3-model-b/
-.. _Raspberry Pi 3 Arm Trusted Firmware bootstrap: https://github.com/AntonioND/rpi3-arm-tf-bootstrap
+.. _Raspberry Pi 3 TF-A bootstrap: https://github.com/AntonioND/rpi3-arm-tf-bootstrap
 .. _Raspberry Pi 3 documentation: https://www.raspberrypi.org/documentation/
 .. _Raspbian: https://www.raspberrypi.org/downloads/raspbian/
diff --git a/docs/plat/socionext-uniphier.rst b/docs/plat/socionext-uniphier.rst
index 590ff62..37cab3b 100644
--- a/docs/plat/socionext-uniphier.rst
+++ b/docs/plat/socionext-uniphier.rst
@@ -1,19 +1,19 @@
-ARM Trusted Firmware for Socionext UniPhier SoCs
-================================================
+Trusted Firmware-A for Socionext UniPhier SoCs
+==============================================
 
 
-Socionext UniPhier ARMv8-A SoCs use ARM Trusted Firmware as the secure world
-firmware, supporting BL2 and BL31.
+Socionext UniPhier Armv8-A SoCs use Trusted Firmware-A (TF-A) as the secure
+world firmware, supporting BL2 and BL31.
 
 UniPhier SoC family implements its internal boot ROM, which loads 64KB [1]_
 image from a non-volatile storage to the on-chip SRAM, and jumps over to it.
-ARM Trusted Firmware provides a special mode, BL2-AT-EL3, which enables BL2 to
-execute at EL3. It is useful for platforms with non-TF boot ROM, like UniPhier.
-Here, a problem is BL2 does not fit in the 64KB limit if `Trusted Board Boot`_
-(TBB) is enabled. To solve this issue, Socionext provides a first stage loader
+TF-A provides a special mode, BL2-AT-EL3, which enables BL2 to execute at EL3.
+It is useful for platforms with non-TF-A boot ROM, like UniPhier. Here, a
+problem is BL2 does not fit in the 64KB limit if `Trusted Board Boot`_ (TBB)
+is enabled. To solve this issue, Socionext provides a first stage loader
 called `UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the
 DRAM, expands BL2 there, and hands the control over to it. Therefore, all images
-of ARM Trusted Firmware run in DRAM.
+of TF-A 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
@@ -46,7 +46,7 @@
 
    This runs in the DRAM. It extracts more images such as BL31, BL33 (optionally
    SCP_BL2, BL32 as well) from Firmware Image Package (FIP). If TBB is enabled,
-   they are all authenticated by the standard mechanism of ARM Trusted Firmware.
+   they are all authenticated by the standard mechanism of TF-A.
    After loading all the images, it jumps to the BL31 entry.
 
 4. BL31, BL32, and BL33
diff --git a/docs/plat/xilinx-zynqmp.rst b/docs/plat/xilinx-zynqmp.rst
index b9c7825..4280241 100644
--- a/docs/plat/xilinx-zynqmp.rst
+++ b/docs/plat/xilinx-zynqmp.rst
@@ -1,12 +1,12 @@
-ARM Trusted Firmware for Xilinx Zynq UltraScale+ MPSoC
-======================================================
+Trusted Firmware-A for Xilinx Zynq UltraScale+ MPSoC
+====================================================
 
-ARM Trusted Firmware implements the EL3 firmware layer for Xilinx Zynq
+Trusted Firmware-A (TF-A) implements the EL3 firmware layer for Xilinx Zynq
 UltraScale + MPSoC.
-The platform only uses the runtime part of ATF as ZynqMP already has a
+The platform only uses the runtime part of TF-A as ZynqMP already has a
 BootROM (BL1) and FSBL (BL2).
 
-BL31 is ATF.
+BL31 is TF-A.
 BL32 is an optional Secure Payload.
 BL33 is the non-secure world software (U-Boot, Linux etc).
 
@@ -35,20 +35,20 @@
    -  ``cadence``, ``cadence0``: Cadence UART 0
    -  ``cadence1`` : Cadence UART 1
 
-FSBL->ATF Parameter Passing
+FSBL->TF-A 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
+The FSBL populates a data structure with image information for TF-A. TF-A 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
+register is free to be used by other software once TF-A has brought up
 further firmware images.
 
 Power Domain Tree
 =================
 
-The following power domain tree represents the power domain model used by the
-ATF for ZynqMP:
+The following power domain tree represents the power domain model used by TF-A
+for ZynqMP:
 
 ::