Merge "Fix documentation typos and misspellings" into integration

docs/change-log.rst

@@ -689,10 +689,10 @@ New Features
    - arm/common: Allow boards to specify second DRAM Base address
      and to define PLAT_ARM_TZC_FILTERS
 
-   - arm/cornstone700: Add support for mhuv2 and stack protector
+   - arm/corstone700: Add support for mhuv2 and stack protector
 
    - arm/fvp: Add support for fconf in BL31 and SP_MIN. Populate power
-     domain desciptor dynamically by leveraging fconf APIs.
+     domain descriptor dynamically by leveraging fconf APIs.
    - arm/fvp: Add Cactus/Ivy Secure Partition information and use two
      instances of Cactus at S-EL1
    - arm/fvp: Add support to run BL32 in TDRAM and BL31 in secure DRAM
@@ -967,7 +967,7 @@ Changed
      cpu clock, Move versal_def.h and versal_private to include directory
 
 - Tools
-   - sptool: Updated sptool to accomodate building secure partition packages.
+   - sptool: Updated sptool to accommodate building secure partition packages.
 
 Resolved Issues
 ^^^^^^^^^^^^^^^

docs/getting_started/build-options.rst

@@ -403,7 +403,7 @@ Common build options
    library is not supported.
 
 -  ``INVERTED_MEMMAP``: memmap tool print by default lower addresses at the
-   bottom, higher addresses at the top. This buid flag can be set to '1' to
+   bottom, higher addresses at the top. This build flag can be set to '1' to
    invert this behavior. Lower addresses will be printed at the top and higher
    addresses at the bottom.
 
@@ -570,7 +570,7 @@ Common build options
 -  ``SEPARATE_NOBITS_REGION``: Setting this option to ``1`` allows the NOBITS
    sections of BL31 (.bss, stacks, page tables, and coherent memory) to be
    allocated in RAM discontiguous from the loaded firmware image. When set, the
-   platform is expected to provide definitons for ``BL31_NOBITS_BASE`` and
+   platform is expected to provide definitions for ``BL31_NOBITS_BASE`` and
    ``BL31_NOBITS_LIMIT``. When the option is ``0`` (the default), NOBITS
    sections are placed in RAM immediately following the loaded firmware image.
 

docs/plat/marvell/armada/misc/mvebu-ccu.rst

 Marvell CCU address decoding bindings
 =====================================
 
-CCU configration driver (1st stage address translation) for Marvell Armada 8K and 8K+ SoCs.
+CCU configuration driver (1st stage address translation) for Marvell Armada 8K and 8K+ SoCs.
 
 The CCU node includes a description of the address decoding configuration.
 

docs/plat/marvell/armada/misc/mvebu-io-win.rst

 Marvell IO WIN address decoding bindings
 ========================================
 
-IO Window configration driver (2nd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
+IO Window configuration driver (2nd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
 
 The IO WIN includes a description of the address decoding configuration.
 

docs/plat/marvell/armada/misc/mvebu-iob.rst

 Marvell IOB address decoding bindings
 =====================================
 
-IO bridge configration driver (3rd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
+IO bridge configuration driver (3rd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
 
 The IOB includes a description of the address decoding configuration.
 

docs/plat/rpi4.rst

@@ -60,7 +60,7 @@ As with the previous models, the GPU and its firmware are the first entity to
 run after the SoC gets its power. The on-chip Boot ROM loads the next stage
 (bootcode.bin) from flash (EEPROM), which is again GPU code.
 This part knows how to access the MMC controller and how to parse a FAT
-filesystem, so it will load further compononents and configuration files
+filesystem, so it will load further components and configuration files
 from the first FAT partition on the SD card.
 
 To accommodate this existing way of configuring and setting up the board,