Correct typographical errors
Corrects typos in core code, documentation files, drivers, Arm
platforms and services.
None of the corrections affect code; changes are limited to comments
and other documentation.
Change-Id: I5c1027b06ef149864f315ccc0ea473e2a16bfd1d
Signed-off-by: Paul Beesley <paul.beesley@arm.com>
diff --git a/docs/auth-framework.rst b/docs/auth-framework.rst
index c934824..e0b569f 100644
--- a/docs/auth-framework.rst
+++ b/docs/auth-framework.rst
@@ -160,7 +160,7 @@
particular image in BL1 or BL2. For each BL image that requires authentication,
the Generic code asks recursively the Authentication module what is the parent
image until either an authenticated image or the ROT is reached. Then the
-Generic code calls the IO framewotk to load the image and calls the
+Generic code calls the IO framework to load the image and calls the
Authentication module to authenticate it, following the CoT from ROT to Image.
TF-A Platform Port (PP)
@@ -422,7 +422,7 @@
- ``_name``: a string containing the IPL name for debugging purposes.
- ``_init``: initialization function pointer.
- ``_check_int``: check image integrity function pointer.
-- ``_get_param``: extract authentication parameter funcion pointer.
+- ``_get_param``: extract authentication parameter function pointer.
The ``init()`` function will be used to initialize the IPL.
@@ -925,7 +925,7 @@
The mbedTLS library algorithm support is configured by the
``TF_MBEDTLS_KEY_ALG`` variable which can take in 3 values: `rsa`, `ecdsa` or
`rsa+ecdsa`. This variable allows the Makefile to include the corresponding
-sources in the build for the various algorthms. Setting the variable to
+sources in the build for the various algorithms. Setting the variable to
`rsa+ecdsa` enables support for both rsa and ecdsa algorithms in the mbedTLS
library.
diff --git a/docs/change-log.rst b/docs/change-log.rst
index d329e83..11fcf21 100644
--- a/docs/change-log.rst
+++ b/docs/change-log.rst
@@ -10,7 +10,7 @@
New Features
------------
-- Removal of a number of deprecated API's
+- Removal of a number of deprecated APIs
- A new Platform Compatibility Policy document has been created which
references a wiki page that maintains a listing of deprecated
@@ -20,7 +20,7 @@
from the code base.
- Various Arm and partner platforms have been updated to remove the use of
- removed API's in this release.
+ removed APIs in this release.
- This release is otherwise unchanged from 1.6 release
@@ -130,7 +130,7 @@
the clang linker is not used because it is unable to link TF-A objects
due to immaturity of clang linker functionality at this time.
-- Refactor support API's into Libraries
+- Refactor support APIs into Libraries
- Evolve libfdt, mbed TLS library and standard C library sources as
proper libraries that TF-A may be linked against.
@@ -435,7 +435,7 @@
- Introduced APIs to get and set the memory attributes of a region.
- - Added support to manage both priviledge levels in translation regimes that
+ - Added support to manage both privilege levels in translation regimes that
describe translations for 2 Exception levels, specifically the EL1&0
translation regime, and extended the memory map region attributes to
include specifying Non-privileged access.
@@ -683,7 +683,7 @@
- Enhancements to Firmware Update feature:
- The FWU logic now checks for overlapping images to prevent execution of
- unauthenticated arbitary code.
+ unauthenticated arbitrary code.
- Introduced new FWU_SMC_IMAGE_RESET SMC that changes the image loading
state machine to go from COPYING, COPIED or AUTHENTICATED states to
@@ -855,7 +855,7 @@
- Essential control registers are fully initialised on EL3 start-up, when
initialising the non-secure and secure context structures and when
- preparing to leave EL3 for a lower EL. This gives better alignement with
+ preparing to leave EL3 for a lower EL. This gives better alignment with
the Arm ARM which states that software must initialise RES0 and RES1
fields with 0 / 1.
@@ -1345,7 +1345,7 @@
- It is now possible to specify the name of the FIP at build time by defining
the ``FIP_NAME`` variable.
-- Issues with depedencies on the 'fiptool' makefile target have been
+- Issues with dependencies on the 'fiptool' makefile target have been
rectified. The ``fip_create`` tool is now rebuilt whenever its source files
change.
@@ -1376,7 +1376,7 @@
the secure world. This can be done by setting the build flag
``FVP_TSP_RAM_LOCATION`` to the value ``dram``.
-- Separate transation tables are created for each boot loader image. The
+- Separate translation tables are created for each boot loader image. The
``IMAGE_BLx`` build options are used to do this. This allows each stage to
create mappings only for areas in the memory map that it needs.
@@ -1530,7 +1530,7 @@
- Clarified the platform porting interface to the TSP.
- Reworked the TSPD setup code to support the alternate BL3-2
- intialization flow where BL3-1 generic code hands control to BL3-2,
+ initialization flow where BL3-1 generic code hands control to BL3-2,
rather than expecting the TSPD to hand control directly to BL3-2.
- Considerable rework to PSCI generic code to support CPU specific
@@ -1569,7 +1569,7 @@
- Removed the concept of top/bottom image loading. The image loader now
automatically detects the position of the image inside the current memory
- layout and updates the layout to minimize fragementation. This resolves the
+ layout and updates the layout to minimize fragmentation. This resolves the
image loader limitations of previously releases. There are currently no
plans to support dynamic image loading.
diff --git a/docs/firmware-design.rst b/docs/firmware-design.rst
index 21a4d53..c79f03d 100644
--- a/docs/firmware-design.rst
+++ b/docs/firmware-design.rst
@@ -203,7 +203,7 @@
The ``plat_report_exception()`` implementation on the Arm FVP port programs
the Versatile Express System LED register in the following format to
- indicate the occurence of an unexpected exception:
+ indicate the occurrence of an unexpected exception:
::
@@ -1991,7 +1991,7 @@
The ``psci_non_cpu_pd_nodes`` data structure stores the platform's power domain
tree information for state management of power domains. By default, this data
structure is allocated in the coherent memory region in TF-A because it can be
-accessed by multple CPUs, either with caches enabled or disabled.
+accessed by multiple CPUs, either with caches enabled or disabled.
.. code:: c
@@ -2031,7 +2031,7 @@
The field ``local_state`` can be concurrently accessed by multiple CPUs in
different cache states. A Lamport's Bakery lock ``psci_locks`` is used to ensure
-mutual exlusion to this field and a clean and invalidate is needed after it
+mutual exclusion to this field and a clean and invalidate is needed after it
is written.
Bakery lock data
@@ -2225,7 +2225,7 @@
execute-never.
This has an impact on memory footprint, as padding bytes need to be introduced
-between the code and read-only data to ensure the segragation of the two. To
+between the code and read-only data to ensure the segregation of the two. To
limit the memory cost, this flag also changes the memory layout such that the
code and exception vectors are now contiguous, like so:
@@ -2352,12 +2352,12 @@
The build option ``RECLAIM_INIT_CODE`` can be set to mark this boot time code
with a ``.text.init.*`` attribute which can be filtered and placed suitably
-within the BL image for later reclaimation by the platform. The platform can
-specify the fiter and the memory region for this init section in BL31 via the
+within the BL image for later reclamation by the platform. The platform can
+specify the filter and the memory region for this init section in BL31 via the
plat.ld.S linker script. For example, on the FVP, this section is placed
overlapping the secondary CPU stacks so that after the cold boot is done, this
memory can be reclaimed for the stacks. The init memory section is initially
-mapped with ``RO``, ``EXECUTE`` attributes. After BL31 initilization has
+mapped with ``RO``, ``EXECUTE`` attributes. After BL31 initialization has
completed, the FVP changes the attributes of this section to ``RW``,
``EXECUTE_NEVER`` allowing it to be used for runtime data. The memory attributes
are changed within the ``bl31_plat_runtime_setup`` platform hook. The init
@@ -2553,7 +2553,7 @@
Platform implementing an Armv7-A system can to define from its target
Cortex-A architecture through ``ARM_CORTEX_A<X> = yes`` in their
-``plaform.mk`` script. For example ``ARM_CORTEX_A15=yes`` for a
+``platform.mk`` script. For example ``ARM_CORTEX_A15=yes`` for a
Cortex-A15 target.
Platform can also set ``ARM_WITH_NEON=yes`` to enable neon support.
diff --git a/docs/firmware-update.rst b/docs/firmware-update.rst
index e10e148..3ee57bc 100644
--- a/docs/firmware-update.rst
+++ b/docs/firmware-update.rst
@@ -266,14 +266,14 @@
if (image_id is invalid) return -EPERM
if (secure world caller)
if (image_id state is not RESET) return -EPERM
- if (image_addr/image_size is not mappped into BL1) return -ENOMEM
+ if (image_addr/image_size is not mapped into BL1) return -ENOMEM
else // normal world caller
if (image_id is secure image)
if (image_id state is not COPIED) return -EPERM
else // image_id is non-secure image
if (image_id state is not RESET) return -EPERM
if (image_addr/image_size is in secure memory) return -ENOMEM
- if (image_addr/image_size not mappped into BL1) return -ENOMEM
+ if (image_addr/image_size not mapped into BL1) return -ENOMEM
This SMC authenticates the image specified by ``image_id``. If the image is in the
RESET state, BL1 authenticates the image in place using the provided
diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst
index f1a26f4..7fc5297 100644
--- a/docs/porting-guide.rst
+++ b/docs/porting-guide.rst
@@ -390,7 +390,7 @@
- **#define : SCP\_BL2\_IMAGE\_ID**
SCP\_BL2 image identifier, used by BL2 to load SCP\_BL2 into secure memory
- from platform storage before being transfered to the SCP.
+ from platform storage before being transferred to the SCP.
- **#define : SCP\_FW\_KEY\_CERT\_ID**
@@ -439,9 +439,9 @@
- **#define : TSP\_SEC\_MEM\_SIZE**
Defines the size of the secure memory used by the BL32 image on the
- platform. ``TSP_SEC_MEM_BASE`` and ``TSP_SEC_MEM_SIZE`` must fully accomodate
- the memory required by the BL32 image, defined by ``BL32_BASE`` and
- ``BL32_LIMIT``.
+ platform. ``TSP_SEC_MEM_BASE`` and ``TSP_SEC_MEM_SIZE`` must fully
+ accommodate the memory required by the BL32 image, defined by ``BL32_BASE``
+ and ``BL32_LIMIT``.
- **#define : TSP\_IRQ\_SEC\_PHY\_TIMER**
@@ -821,11 +821,11 @@
Argument : void
Return : unsigned int
-This funtion returns the index of the calling CPU which is used as a
+This function returns the index of the calling CPU which is used as a
CPU-specific linear index into blocks of memory (for example while allocating
per-CPU stacks). This function will be invoked very early in the
initialization sequence which mandates that this function should be
-implemented in assembly and should not rely on the avalability of a C
+implemented in assembly and should not rely on the availability of a C
runtime environment. This function can clobber x0 - x8 and must preserve
x9 - x29.
@@ -929,7 +929,7 @@
A platform may need to do additional initialization after reset. This function
allows the platform to do the platform specific intializations. Platform
-specific errata workarounds could also be implemented here. The api should
+specific errata workarounds could also be implemented here. The API should
preserve the values of callee saved registers x19 to x29.
The default implementation doesn't do anything. If a platform needs to override
@@ -1543,7 +1543,7 @@
process and is executed only by the primary CPU. BL1 passes control to BL2U at
``BL2U_BASE``. BL2U executes in Secure-EL1 and is responsible for:
-#. (Optional) Transfering the optional SCP\_BL2U binary image from AP secure
+#. (Optional) Transferring the optional SCP\_BL2U binary image from AP secure
memory to SCP RAM. BL2U uses the SCP\_BL2U ``image_info`` passed by BL1.
``SCP_BL2U_BASE`` defines the address in AP secure memory where SCP\_BL2U
should be copied from. Subsequent handling of the SCP\_BL2U image is
@@ -1649,7 +1649,7 @@
implementation.
#. Optionally passing control to the BL32 image, pre-loaded at a platform-
- specific address by BL2. BL31 exports a set of apis that allow runtime
+ specific address by BL2. BL31 exports a set of APIs that allow runtime
services to specify the security state in which the next image should be
executed and run the corresponding image. On ARM platforms, BL31 uses the
``bl_params`` list populated by BL2 in memory to do this.
@@ -1800,7 +1800,7 @@
``include/lib/xlat_tables/xlat_mmu_helpers.h``.
On DynamIQ systems, this function must not use stack while enabling MMU, which
-is how the function in xlat table library version 2 is implementated.
+is how the function in xlat table library version 2 is implemented.
Function : plat\_get\_syscnt\_freq2() [mandatory]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2030,7 +2030,7 @@
This function returns a pointer to the byte array containing the power domain
topology tree description. The format and method to construct this array are
-described in `Power Domain Topology Design`_. The BL31 PSCI initilization code
+described in `Power Domain Topology Design`_. The BL31 PSCI initialization code
requires this array to be described by the platform, either statically or
dynamically, to initialize the power domain topology tree. In case the array
is populated dynamically, then plat\_core\_pos\_by\_mpidr() and
@@ -2070,7 +2070,7 @@
Perform the platform-specific actions to enter the standby state for a cpu
indicated by the passed argument. This provides a fast path for CPU standby
-wherein overheads of PSCI state management and lock acquistion is avoided.
+wherein overheads of PSCI state management and lock acquisition is avoided.
For this handler to be invoked by the PSCI ``CPU_SUSPEND`` API implementation,
the suspend state type specified in the ``power-state`` parameter should be
STANDBY and the target power domain level specified should be the CPU. The
@@ -2345,7 +2345,7 @@
described in the `IMF Design Guide`_
A platform should export the following APIs to support the IMF. The following
-text briefly describes each api and its implementation in Arm standard
+text briefly describes each API and its implementation in Arm standard
platforms. The API implementation depends upon the type of interrupt controller
present in the platform. Arm standard platform layer supports both
`Arm Generic Interrupt Controller version 2.0 (GICv2)`_
@@ -2552,7 +2552,7 @@
BL31 implements a crash reporting mechanism which prints the various registers
of the CPU to enable quick crash analysis and debugging. This mechanism relies
-on the platform implementating ``plat_crash_console_init``,
+on the platform implementing ``plat_crash_console_init``,
``plat_crash_console_putc`` and ``plat_crash_console_flush``.
The file ``plat/common/aarch64/crash_console_helpers.S`` contains sample
diff --git a/docs/psci-lib-integration-guide.rst b/docs/psci-lib-integration-guide.rst
index d86fc29..1be2240 100644
--- a/docs/psci-lib-integration-guide.rst
+++ b/docs/psci-lib-integration-guide.rst
@@ -240,7 +240,7 @@
the EL3 Runtime Software may want to perform some bookkeeping during power
management operations. This function is used to register the ``spd_pm_ops_t``
(first argument) callbacks with the PSCI library which will be called
-ppropriately during power management. Calling this function is optional and
+appropriately during power management. Calling this function is optional and
need to be called by the primary CPU during the cold boot sequence after
``psci_setup()`` has completed.
diff --git a/docs/ras.rst b/docs/ras.rst
index 4c82022..cea74e9 100644
--- a/docs/ras.rst
+++ b/docs/ras.rst
@@ -203,8 +203,8 @@
Engaging the RAS framework
--------------------------
-Enabling RAS support is a platform choice conjunctional of three distinct but
-related build options:
+Enabling RAS support is a platform choice constructed from three distinct, but
+related, build options:
- ``RAS_EXTENSION=1`` includes the RAS framework in the run time firmware;
@@ -244,7 +244,7 @@
.. __: exception-handling.rst#partitioning-priority-levels
-Handling of both `interrrupt`__ and `non-interrupt`__ exceptions follow the
+Handling of both `interrupt`__ and `non-interrupt`__ exceptions follow the
sequences outlined in the |EHF| documentation. I.e., for interrupts, the
priority management is implicit; but for non-interrupt exceptions, they're
explicit using `EHF APIs`__.
diff --git a/docs/secure-partition-manager-design.rst b/docs/secure-partition-manager-design.rst
index 73406b2..3c301d0 100644
--- a/docs/secure-partition-manager-design.rst
+++ b/docs/secure-partition-manager-design.rst
@@ -309,7 +309,7 @@
allows the Secure Partition to:
- Register with the SPM a service that it provides.
-- Indicate completion of a service request delagated by the SPM
+- Indicate completion of a service request delegated by the SPM
Miscellaneous interfaces
------------------------
diff --git a/docs/user-guide.rst b/docs/user-guide.rst
index 103f1c7..b50de37 100644
--- a/docs/user-guide.rst
+++ b/docs/user-guide.rst
@@ -108,7 +108,7 @@
``CC`` needs to point to the clang or armclang binary, which will
also select the clang or armclang assembler. Be aware that the
GNU linker is used by default. In case of being needed the linker
- can be overriden using the ``LD`` variable. Clang linker version 6 is
+ can be overridden using the ``LD`` variable. Clang linker version 6 is
known to work with TF-A.
In both cases ``CROSS_COMPILE`` should be set as described above.
@@ -357,8 +357,8 @@
supports the format used by GCC when T32 interworking is disabled. For this
reason enabling this option in AArch32 will force the compiler to only
generate A32 code. This option is enabled by default only in AArch64 debug
- builds, but this behaviour can be overriden in each platform's Makefile or in
- the build command line.
+ builds, but this behaviour can be overridden in each platform's Makefile or
+ in the build command line.
- ``ENABLE_MPAM_FOR_LOWER_ELS``: Boolean option to enable lower ELs to use MPAM
feature. MPAM is an optional Armv8.4 extension that enables various memory
@@ -428,7 +428,7 @@
handled at EL3, and a panic will result. This is supported only for AArch64
builds.
-- ``FAULT_INJECTION_SUPPORT``: ARMv8.4 externsions introduced support for fault
+- ``FAULT_INJECTION_SUPPORT``: ARMv8.4 extensions introduced support for fault
injection from lower ELs, and this build option enables lower ELs to use
Error Records accessed via System Registers to inject faults. This is
applicable only to AArch64 builds.