Fully initialise essential control registers ...

This patch updates the el3_arch_init_common macro so that it fully
initialises essential control registers rather then relying on hardware
to set the reset values.

The context management functions are also updated to fully initialise
the appropriate control registers when initialising the non-secure and
secure context structures and when preparing to leave EL3 for a lower
EL.

This gives better alignement with the ARM ARM which states that software
must initialise RES0 and RES1 fields with 0 / 1.

This patch also corrects the following typos:

"NASCR definitions" -> "NSACR definitions"

Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc
Signed-off-by: David Cunado <david.cunado@arm.com>

Merge pull request #927 from jeenu-arm/state-switch ...

Execution state switch

Use SPDX license identifiers ...

To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.

NOTE: Files that have been imported by FreeBSD have not been modified.

[0]: https://spdx.org/

Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

Add macro to check whether the CPU implements an EL ...

Replace all instances of checks with the new macro.

Change-Id: I0eec39b9376475a1a9707a3115de9d36f88f8a2a
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

PSCI: Build option to enable D-Caches early in warmboot ...

This patch introduces a build option to enable D-cache early on the CPU
after warm boot. This is applicable for platforms which do not require
interconnect programming to enable cache coherency (eg: single cluster
platforms). If this option is enabled, then warm boot path enables
D-caches immediately after enabling MMU.

Fixes ARM-Software/tf-issues#456

Change-Id: I44c8787d116d7217837ced3bcf0b1d3441c8d80e
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

Merge pull request #885 from antonio-nino-diaz-arm/an/console-flush ...

Implement console_flush()

Add support for GCC stack protection ...

Introduce new build option ENABLE_STACK_PROTECTOR. It enables
compilation of all BL images with one of the GCC -fstack-protector-*
options.

A new platform function plat_get_stack_protector_canary() is introduced.
It returns a value that is used to initialize the canary for stack
corruption detection. Returning a random value will prevent an attacker
from predicting the value and greatly increase the effectiveness of the
protection.

A message is printed at the ERROR level when a stack corruption is
detected.

To be effective, the global data must be stored at an address
lower than the base of the stacks. Failure to do so would allow an
attacker to overwrite the canary as part of an attack which would void
the protection.

FVP implementation of plat_get_stack_protector_canary is weak as
there is no real source of entropy on the FVP. It therefore relies on a
timer's value, which could be predictable.

Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Flush console where necessary ...

Call console_flush() before execution either terminates or leaves an
exception level.

Fixes: ARM-software/tf-issues#123

Change-Id: I64eeb92effb039f76937ce89f877b68e355588e3
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Add and use plat_crash_console_flush() API ...

This API makes sure that all the characters sent to the crash console
are output before returning from it.

Porting guide updated.

Change-Id: I1785f970a40f6aacfbe592b6a911b1f249bb2735
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Move plat/common source file definitions to generic Makefiles ...

These source file definitions should be defined in generic
Makefiles so that all platforms can benefit. Ensure that the
symbols are properly marked as weak so they can be overridden
by platforms.

NOTE: This change is a potential compatibility break for
non-upstream platforms.

Change-Id: I7b892efa9f2d6d216931360dc6c436e1d10cffed
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

Merge pull request #860 from jeenu-arm/hw-asstd-coh ...

Patches for platforms with hardware-assisted coherency

Simplify translation tables headers dependencies ...

The files affected by this patch don't really depend on `xlat_tables.h`.
By changing the included file it becomes easier to switch between the
two versions of the translation tables library.

Change-Id: Idae9171c490e0865cb55883b19eaf942457c4ccc
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Enable data caches early with hardware-assisted coherency ...

At present, warm-booted CPUs keep their caches disabled when enabling
MMU, and remains so until they enter coherency later.

On systems with hardware-assisted coherency, for which
HW_ASSISTED_COHERENCY build flag would be enabled, warm-booted CPUs can
have both caches and MMU enabled at once.

Change-Id: Icb0adb026e01aecf34beadf49c88faa9dd368327
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Introduce unified API to zero memory ...

Introduce zeromem_dczva function on AArch64 that can handle unaligned
addresses and make use of DC ZVA instruction to zero a whole block at a
time. This zeroing takes place directly in the cache to speed it up
without doing external memory access.

Remove the zeromem16 function on AArch64 and replace it with an alias to
zeromem. This zeromem16 function is now deprecated.

Remove the 16-bytes alignment constraint on __BSS_START__ in
firmware-design.md as it is now not mandatory anymore (it used to comply
with zeromem16 requirements).

Change the 16-bytes alignment constraints in SP min's linker script to a
8-bytes alignment constraint as the AArch32 zeromem implementation is now
more efficient on 8-bytes aligned addresses.

Introduce zero_normalmem and zeromem helpers in platform agnostic header
that are implemented this way:
* AArch32:
	* zero_normalmem: zero using usual data access
	* zeromem: alias for zero_normalmem
* AArch64:
	* zero_normalmem: zero normal memory  using DC ZVA instruction
	                  (needs MMU enabled)
	* zeromem: zero using usual data access

Usage guidelines: in most cases, zero_normalmem should be preferred.

There are 2 scenarios where zeromem (or memset) must be used instead:
* Code that must run with MMU disabled (which means all memory is
  considered device memory for data accesses).
* Code that fills device memory with null bytes.

Optionally, the following rule can be applied if performance is
important:
* Code zeroing small areas (few bytes) that are not secrets should use
  memset to take advantage of compiler optimizations.

  Note: Code zeroing security-related critical information should use
  zero_normalmem/zeromem instead of memset to avoid removal by
  compilers' optimizations in some cases or misbehaving versions of GCC.

Fixes ARM-software/tf-issues#408

Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Define and use no_ret macro where no return is expected ...

There are many instances in ARM Trusted Firmware where control is
transferred to functions from which return isn't expected. Such jumps
are made using 'bl' instruction to provide the callee with the location
from which it was jumped to. Additionally, debuggers infer the caller by
examining where 'lr' register points to. If a 'bl' of the nature
described above falls at the end of an assembly function, 'lr' will be
left pointing to a location outside of the function range. This misleads
the debugger back trace.

This patch defines a 'no_ret' macro to be used when jumping to functions
from which return isn't expected. The macro ensures to use 'bl'
instruction for the jump, and also, for debug builds, places a 'nop'
instruction immediately thereafter (unless instructed otherwise) so as
to leave 'lr' pointing within the function range.

Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0
Co-authored-by: Douglas Raillard <douglas.raillard@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Cosmetic change to exception table ...

* Move comments on unhandled exceptions at the right place.
* Reformat the existing comments to highlight the start of
  each block of 4 entries in the exception table to ease
  navigation (lines of dash reserved for head comments).
* Reflow comments to 80 columns.

Change-Id: I5ab88a93d0628af8e151852cb5b597eb34437677
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Merge pull request #724 from rockchip-linux/support-rk3399-sdram ...

rockchip: optimize the link mechanism for SRAM code

rockchip: optimize the link mechanism for SRAM code ...

Add the common extra.ld.S and customized rk3399.ld.S to extend
to more features for different platforms.
For example, we can add SRAM section and specific address to
load there if we need it, and the common bl31.ld.S not need to
be modified.

Therefore, we can remove the unused codes which copying explicitly
from the function pmusram_prepare(). It looks like more clear.

Change-Id: Ibffa2da5e8e3d1d2fca80085ebb296ceb967fce8
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>

Add PMF instrumentation points in TF ...

In order to quantify the overall time spent in the PSCI software
implementation, an initial collection of PMF instrumentation points
has been added.

Instrumentation has been added to the following code paths:

- Entry to PSCI SMC handler.  The timestamp is captured as early
  as possible during the runtime exception and stored in memory
  before entering the PSCI SMC handler.

- Exit from PSCI SMC handler.  The timestamp is captured after
  normal return from the PSCI SMC handler or if a low power state
  was requested it is captured in the bl31 warm boot path before
  return to normal world.

- Entry to low power state.  The timestamp is captured before entry
  to a low power state which implies either standby or power down.
  As these power states are mutually exclusive, only one timestamp
  is defined to describe both.  It is possible to differentiate between
  the two power states using the PSCI STAT interface.

- Exit from low power state.  The timestamp is captured after a standby
  or power up operation has completed.

To calculate the number of cycles spent running code in Trusted Firmware
one can perform the following calculation:

(exit_psci - enter_psci) - (exit_low_pwr - enter_low_pwr).

The resulting number of cycles can be converted to time given the
frequency of the counter.

Change-Id: Ie3b8f3d16409b6703747093b3a2d5c7429ad0166
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

PSCI: Do psci_setup() as part of std_svc_setup() ...

This patch moves the invocation of `psci_setup()` from BL31 and SP_MIN
into `std_svc_setup()` as part of ARM Standard Service initialization.
This allows us to consolidate ARM Standard Service initializations which
will be added to in the future. A new function `get_arm_std_svc_args()`
is introduced to get arguments corresponding to each standard service.
This function must be implemented by the EL3 Runtime Firmware and both
SP_MIN and BL31 implement it.

Change-Id: I38e1b644f797fa4089b20574bd4a10f0419de184

PSCI: Introduce PSCI Library argument structure ...

This patch introduces a `psci_lib_args_t` structure which must be
passed into `psci_setup()` which is then used to initialize the PSCI
library. The `psci_lib_args_t` is a versioned structure so as to enable
compatibility checks during library initialization. Both BL31 and SP_MIN
are modified to use the new structure.

SP_MIN is also modified to add version string and build message as part
of its cold boot log just like the other BLs in Trusted Firmware.

NOTE: Please be aware that this patch modifies the prototype of
`psci_setup()`, which breaks compatibility with EL3 Runtime Firmware
(excluding BL31 and SP_MIN) integrated with the PSCI Library.

Change-Id: Ic3761db0b790760a7ad664d8a437c72ea5edbcd6

Introduce PSCI Library Interface ...

This patch introduces the PSCI Library interface. The major changes
introduced are as follows:

* Earlier BL31 was responsible for Architectural initialization during cold
boot via bl31_arch_setup() whereas PSCI was responsible for the same during
warm boot. This functionality is now consolidated by the PSCI library
and it does Architectural initialization via psci_arch_setup() during both
cold and warm boots.

* Earlier the warm boot entry point was always `psci_entrypoint()`. This was
not flexible enough as a library interface. Now PSCI expects the runtime
firmware to provide the entry point via `psci_setup()`. A new function
`bl31_warm_entrypoint` is introduced in BL31 and the previous
`psci_entrypoint()` is deprecated.

* The `smc_helpers.h` is reorganized to separate the SMC Calling Convention
defines from the Trusted Firmware SMC helpers. The former is now in a new
header file `smcc.h` and the SMC helpers are moved to Architecture specific
header.

* The CPU context is used by PSCI for context initialization and
restoration after power down (PSCI Context). It is also used by BL31 for SMC
handling and context management during Normal-Secure world switch (SMC
Context). The `psci_smc_handler()` interface is redefined to not use SMC
helper macros thus enabling to decouple the PSCI context from EL3 runtime
firmware SMC context. This enables PSCI to be integrated with other runtime
firmware using a different SMC context.

NOTE: With this patch the architectural setup done in `bl31_arch_setup()`
is done as part of `psci_setup()` and hence `bl31_platform_setup()` will be
invoked prior to architectural setup. It is highly unlikely that the platform
setup will depend on architectural setup and cause any failure. Please be
be aware of this change in sequence.

Change-Id: I7f497a08d33be234bbb822c28146250cb20dab73

Introduce `el3_runtime` and `PSCI` libraries ...

This patch moves the PSCI services and BL31 frameworks like context
management and per-cpu data into new library components `PSCI` and
`el3_runtime` respectively. This enables PSCI to be built independently from
BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant
PSCI library sources and gets included by `bl31.mk`. Other changes which
are done as part of this patch are:

* The runtime services framework is now moved to the `common/` folder to
  enable reuse.
* The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture
  specific folder.
* The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder
  to `plat/common` folder. The original file location now has a stub which
  just includes the file from new location to maintain platform compatibility.

Most of the changes wouldn't affect platform builds as they just involve
changes to the generic bl1.mk and bl31.mk makefiles.

NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT
THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR
MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION.

Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86

Rework type usage in Trusted Firmware ...

This patch reworks type usage in generic code, drivers and ARM platform files
to make it more portable. The major changes done with respect to
type usage are as listed below:

* Use uintptr_t for storing address instead of uint64_t or unsigned long.
* Review usage of unsigned long as it can no longer be assumed to be 64 bit.
* Use u_register_t for register values whose width varies depending on
  whether AArch64 or AArch32.
* Use generic C types where-ever possible.

In addition to the above changes, this patch also modifies format specifiers
in print invocations so that they are AArch64/AArch32 agnostic. Only files
related to upcoming feature development have been reworked.

Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8

Introduce SEPARATE_CODE_AND_RODATA build flag ...

At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.

This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.

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 limit the memory cost, the memory layout
of the read-only section has been changed in this case.

 - When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
   the read-only section still looks like this (padding omitted):

   |        ...        |
   +-------------------+
   | Exception vectors |
   +-------------------+
   |  Read-only data   |
   +-------------------+
   |       Code        |
   +-------------------+ BLx_BASE

   In this case, the linker script provides the limits of the whole
   read-only section.

 - When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
   read-only data are swapped, such that the code and exception
   vectors are contiguous, followed by the read-only data. This
   gives the following new layout (padding omitted):

   |        ...        |
   +-------------------+
   |  Read-only data   |
   +-------------------+
   | Exception vectors |
   +-------------------+
   |       Code        |
   +-------------------+ BLx_BASE

   In this case, the linker script now exports 2 sets of addresses
   instead: the limits of the code and the limits of the read-only
   data. Refer to the Firmware Design guide for more details. This
   provides platform code with a finer-grained view of the image
   layout and allows it to map these 2 regions with the appropriate
   access permissions.

Note that SEPARATE_CODE_AND_RODATA applies to all BL images.

Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49

Add optional PSCI STAT residency & count functions ...

This patch adds following optional PSCI STAT functions:

- PSCI_STAT_RESIDENCY: This call returns the amount of time spent
  in power_state in microseconds, by the node represented by the
  `target_cpu` and the highest level of `power_state`.

- PSCI_STAT_COUNT: This call returns the number of times a
  `power_state` has been used by the node represented by the
  `target_cpu` and the highest power level of `power_state`.

These APIs provides residency statistics for power states that has
been used by the platform. They are implemented according to v1.0
of the PSCI specification.

By default this optional feature is disabled in the PSCI
implementation. To enable it, set the boolean flag
`ENABLE_PSCI_STAT` to 1. This also sets `ENABLE_PMF` to 1.

Change-Id: Ie62e9d37d6d416ccb1813acd7f616d1ddd3e8aff

Add Performance Measurement Framework(PMF) ...

This patch adds Performance Measurement Framework(PMF) in the
ARM Trusted Firmware. PMF is implemented as a library and the
SMC interface is provided through ARM SiP service.

The PMF provides capturing, storing, dumping and retrieving the
time-stamps, by enabling the development of services by different
providers, that can be easily integrated into ARM Trusted Firmware.
The PMF capture and retrieval APIs can also do appropriate cache
maintenance operations to the timestamp memory when the caller
indicates so.

`pmf_main.c` consists of core functions that implement service
registration, initialization, storing, dumping and retrieving
the time-stamp.
`pmf_smc.c` consists SMC handling for registered PMF services.
`pmf.h` consists of the macros that can be used by the PMF service
providers to register service and declare time-stamp functions.
`pmf_helpers.h` consists of internal macros that are used by `pmf.h`

By default this feature is disabled in the ARM trusted firmware.
To enable it set the boolean flag `ENABLE_PMF` to 1.

NOTE: The caller is responsible for specifying the appropriate cache
maintenance flags and for acquiring/releasing appropriate locks
before/after capturing/retrieving the time-stamps.

Change-Id: Ib45219ac07c2a81b9726ef6bd9c190cc55e81854

Merge pull request #636 from soby-mathew/sm/cpu_ctx_rem_aarch32_regs ...

Build option to include AArch32 registers in cpu context

Build option to include AArch32 registers in cpu context ...

The system registers that are saved and restored in CPU context include
AArch32 systems registers like SPSR_ABT, SPSR_UND, SPSR_IRQ, SPSR_FIQ,
DACR32_EL2, IFSR32_EL2 and FPEXC32_EL2. Accessing these registers on an
AArch64-only (i.e. on hardware that does not implement AArch32, or at
least not at EL1 and higher ELs) platform leads to an exception. This patch
introduces the build option `CTX_INCLUDE_AARCH32_REGS` to specify whether to
include these AArch32 systems registers in the cpu context or not. By default
this build option is set to 1 to ensure compatibility. AArch64-only platforms
must set it to 0. A runtime check is added in BL1 and BL31 cold boot path to
verify this.

Fixes ARM-software/tf-issues#386

Change-Id: I720cdbd7ed7f7d8516635a2ec80d025f478b95ee

Introduce some helper macros for exception vectors ...

This patch introduces some assembler macros to simplify the
declaration of the exception vectors. It abstracts the section
the exception code is put into as well as the alignments
constraints mandated by the ARMv8 architecture. For all TF images,
the exception code has been updated to make use of these macros.

This patch also updates some invalid comments in the exception
vector code.

Change-Id: I35737b8f1c8c24b6da89b0a954c8152a4096fa95