Merge pull request #474 from danh-arm/dh/v1.2-misc-doc-fixes

Misc documentation fixes for v1.2 release

Miscellaneous doc fixes for v1.2

Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b

Clarify "Getting the TF source code" in user guide

Remove the following redundant sentence from the user guide, which
implies the user should use the TF version from the Linaro release,
which was not the intention:

"However, the rest of this document assumes that you got the
Trusted Firmware as part of the Linaro release."

Also, tidied up the grammar in this section.

Change-Id: I5dae0b68d3683e2a85a7b3c6a31222182a66f6c8

Update `contributing.md` CLA instructions

Update `contributing.md` to make it clear that contributors should
wait for ARM to confirm acceptance of the completed CLA before
making contributions.

Change-Id: Ide62d893ad8cc0d2a0949c16605cd8689d9624bf

Remove out-dated comment in FVP PWRC code

fvp_pwr_domain_on() used to program the CPUs mailbox. This changed
with commit 804040d10 but the comment documenting this code still
refers to the mailbox programming. This patch removes this out-dated
information.

Change-Id: Ibfe2a426bdda6e71f20c83a99cb223ceca9c559c

Merge pull request #473 from labapart/documentation-clean-legacy-variables

Documentation: Clean legacy variables in User Guide

Merge pull request #472 from danh-arm/dh/fwu-docs

FWU: Add documentation for Firmware Update feature

FWU: Add documentation for Firmware Update feature

This patch adds design documentation for the Firmware Update (FWU)
feature in `firmware-update.md`. It provides an overview of FWU,
describes the BL1 SMC interface, and includes diagrams showing
an example FWU boot flow and the FWU state machine.

This patch also updates the existing TF documents where needed:

*   `porting-guide.md`
*   `user-guide.md`
*   `firmware-design.md`
*   `rt-svc-writers-guide.md`
*   `trusted_board_boot.md`

Change-Id: Ie6de31544429b18f01327bd763175e218299a4ce
Co-Authored-By: Dan Handley <dan.handley@arm.com>

docs/user-guide.md: Remove deprecated `FVP_SHARED_DATA_LOCATION`

docs/user-guide.md: Renamed legacy `FVP_TSP_RAM_LOCATION`

`FVP_TSP_RAM_LOCATION` has been renamed into `ARM_TSP_RAM_LOCATION`.

Merge pull request #471 from sandrine-bailleux/sb/reset-doc-v2

Introduce the ARM TF reset design document (v2)

Merge pull request #466 from soby-mathew/sm/giv3-doc

Documentation updates for the new GIC drivers

Merge pull request #470 from danh-arm/dh/fwu-done-fix

FWU: Pass client cookie to FWU_SMC_UPDATE_DONE

Introduce the ARM TF reset design document

This patch introduces a new document presenting the ARM Trusted
Firmware Reset Design. It shows the reset code flow, lists the
different build options that affect it, in which case to use them
and what their exact effect is.

The section about using BL31 entrypoint as the reset address has
been moved from the general firmware design document to this one.
It's also been improved to explain why the FVP port supports the
RESET_TO_BL31 configuration, even though the reset vector address
can't be programmed dynamically.

This document includes some images, which have been generated using
Dia version 0.97.2. This tool can be obtained from:
https://wiki.gnome.org/Apps/Dia/Download
This patch provides:
 - the image files describing the different reset flow diagrams;
 - the source '.dia' file;
 - a script automating the generation of the images from the '.dia'
   file.
Note that the 2 latter files are not actually needed for the document
and are provided for convenience only, in case the reset images need
to be modified.

Change-Id: Ib6302e8209d418a5b31c4e85e55fd9e83caf2ca2

Merge pull request #469 from danh-arm/dh/fwu-resume-fix

FWU: Remove image_id arg from FWU_SMC_IMAGE_RESUME

FWU: Pass client cookie to FWU_SMC_UPDATE_DONE

The current FWU_SMC_UPDATE_DONE implementation incorrectly passes
an unused framework cookie through to the 1st argument in the
platform function `bl1_plat_fwu_done`. The intent is to allow
the SMC caller to pass a cookie through to this function.

This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller
through to `bl1_plat_fwu_done`. The argument names are updated
for clarity.

Upstream platforms currently do not use this argument so no
impact is expected.

Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2

FWU: Remove image_id arg from FWU_SMC_IMAGE_RESUME

The current implementation of FWU_SMC_IMAGE_RESUME when called
from the normal world, uses the provided image_id argument to
determine which secure image to resume into. This implies that
the normal world has a choice of which secure image to resume
into when in fact it is only possible to resume into the
previously interrupted secure image.

This patch removes the argument, tightens up the pre-conditions
for the SMC and adds additional asserts.

The pre-conditions for FWU_SMC_SEC_IMAGE_DONE are also
tightened up.

Change-Id: Ia5a46753bb01e8f8dad8a2999314f90db8f300e8

Documentation updates for the new GIC drivers

This patch updates the relevant documentation in ARM Trusted Firmware
for the new GIC drivers. The user-guide.md and porting-guide.md have been
updated as follows:

*  The build option to compile Trusted Firmware with different GIC drivers
   for FVP has been explained in the user-guide.md.

*  The implementation details of interrupt management framework porting
   APIs for GICv3 have been added in porting-guide.md.

*  The Linaro tracking kernel release does not work OOB in GICv3 mode.
   The instructions for changing UEFI configuration in order to run with
   the new GICv3 driver in ARM TF have been added to user-guide.md.

The interrupt-framework-design.md has been updated as follows:

*  Describes support for registering and handling interrupts targeted to EL3
   e.g. Group 0 interrupts in GICv3.

*  Describes the build option `TSP_NS_INTR_ASYNC_PREEMPT` in detail.

*  Describes preemption of TSP in S-EL1 by non secure interrupts and
   also possibly by higher priority EL3 interrupts.

*  Describes the normal world sequence for issuing `standard` SMC calls.

*  Modifies the document to correspond to the current state of interrupt
   handling in TSPD and TSP.

*  Modifies the various functions names in the document to reflect
   the current names used in code.

Change-Id: I78c9514b5be834f193405aad3c1752a4a9e27a6c

Merge pull request #468 from danh-arm/dh/fwu-tweaks

FWU: Fix secure memory check in image auth

Merge pull request #467 from jcastillo-arm/jc/tbb_oid

Apply new image terminology

FWU: Fix secure memory check in image auth

The implementation of FWU_SMC_IMAGE_AUTH performs a number of
pre-condition checks before authenticating the image. One of
these checks calls `bl1_plat_mem_check()` to ensure the image
source is mapped in when authenticating an image in place.
The framework incorrectly passes the security state of the
caller into this function instead of the security state of
the source image.

This patch corrects the defect. The defect would only
manifest itself for secure world callers authenticating
non-secure images in place, which is not done by current
upstream platforms.

Change-Id: I617c7b43e02ac7149f266aeaf3874316e62f3003

Remove dashes from image names: 'BL3-x' --> 'BL3x'

This patch removes the dash character from the image name, to
follow the image terminology in the Trusted Firmware Wiki page:

    https://github.com/ARM-software/arm-trusted-firmware/wiki

Changes apply to output messages, comments and documentation.

non-ARM platform files have been left unmodified.

Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76

Replace all SCP FW (BL0, BL3-0) references

This patch replaces all references to the SCP Firmware (BL0, BL30,
BL3-0, bl30) with the image terminology detailed in the TF wiki
(https://github.com/ARM-software/arm-trusted-firmware/wiki):

    BL0          -->  SCP_BL1
    BL30, BL3-0  -->  SCP_BL2
    bl30         -->  scp_bl2

This change affects code, documentation, build system, tools and
platform ports that load SCP firmware. ARM plaforms have been
updated to the new porting API.

IMPORTANT: build option to specify the SCP FW image has changed:

    BL30 --> SCP_BL2

IMPORTANT: This patch breaks compatibility for platforms that use BL2
to load SCP firmware. Affected platforms must be updated as follows:

    BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
    BL30_BASE --> SCP_BL2_BASE
    bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
    bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()

Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58

TBB: apply TBBR naming convention to certificates and extensions

This patch applies the TBBR naming convention to the certificates
and the corresponding extensions defined by the CoT:

    * Certificate UUID names
    * Certificate identifier names
    * OID names

Changes apply to:

    * Generic code (variables and defines)
    * The default certificate identifiers provided in the generic
      code
    * Build system
    * ARM platforms port
    * cert_create tool internal definitions
    * fip_create and cert_create tools command line options
    * Documentation

IMPORTANT: this change breaks the compatibility with platforms
that use TBBR. The platform will need to adapt the identifiers
and OIDs to the TBBR naming convention introduced by this patch:

Certificate UUIDs:

    UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT
    UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT
    UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT
    UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT
    UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT
    UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT
    UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT
    UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT
    UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT

Certificate identifiers:

    BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID
    BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID
    BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID
    BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID
    BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID
    BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID
    BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID
    BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID
    BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID

OIDs:

    TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID
    NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID
    BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID
    TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID
    NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID
    BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID
    BL30_HASH_OID --> SCP_FW_HASH_OID
    BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID
    BL31_HASH_OID --> SOC_AP_FW_HASH_OID
    BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID
    BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID
    BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID
    BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID
    BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID
    SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID
    NS_BL2U_HASH_OID --> FWU_HASH_OID

Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079

Merge pull request #465 from jcastillo-arm/jc/tbb_mbedtls_2_x

Move up to mbed TLS 2.x

Move up to mbed TLS 2.x

The mbed TLS library has introduced some changes in the API from
the 1.3.x to the 2.x releases. Using the 2.x releases requires
some changes to the crypto and transport modules.

This patch updates both modules to the mbed TLS 2.x API.

All references to the mbed TLS library in the code or documentation
have been updated to 'mbed TLS'. Old references to PolarSSL have
been updated to 'mbed TLS'.

User guide updated to use mbed TLS 2.2.0.

NOTE: moving up to mbed TLS 2.x from 1.3.x is not backward compatible.
Applying this patch will require an mbed TLS 2.x release to be used.
Also note that the mbed TLS license changed to Apache version 2.0.

Change-Id: Iba4584408653cf153091f2ca2ee23bc9add7fda4

Merge pull request #464 from sandrine-bailleux/sb/update-deps

Move up dependency versions in user guide

Move up dependency versions in user guide

Move up the version numbers in the user guide of:

 * DS-5 (to v5.22)
 * Base FVP (to 7.0)
 * Foundation FVP (to 9.4)
 * Linaro release (to 15.10)

Note that, starting from Linaro release 15.10, the related release
instructions have migrated from http://releases.linaro.org to the
ARM Connected Community website. The URLs in the User Guide have
been updated accordingly.

The 'libssl-dev' package has been removed from the list of
prerequisite tools, as it is already referenced on the ARM Connected
Community page. Also, the 'device-tree-compiler' package has been
marked as an optional dependency, since the Trusted Firmware
repository provides the prebuilt DTB files. Hence, this tool is
needed only when the user wants to rebuild the DTS files.

Change-Id: I4a172ece60bf90437131c6b96e73a9f1e9b40117

Merge pull request #463 from jcastillo-arm/jc/tf-issues/216

De-feature PL011 UART driver to match generic UART spec

De-feature PL011 UART driver to match generic UART spec

The Server Base System Architecture document (ARM-DEN-0029)
specifies a generic UART device. The programmer's view of this
generic UART is a subset of the ARM PL011 UART. However, the
current PL011 driver in Trusted Firmware uses some features
that are outside the generic UART specification.

This patch modifies the PL011 driver to exclude features outside
the SBSA generic UART specification by setting the boolean build
option 'PL011_GENERIC_UART=1'. Default value is 0 (use full
PL011 features).

User guide updated.

Fixes ARM-software/tf-issues#216

Change-Id: I6e0eb86f9d69569bc3980fb57e70d6da5d91a737

Merge pull request #462 from soby-mathew/sm/runtime_console

Enable BL31 to configure a runtime console

Merge pull request #453 from yatharth-arm/yk/fwu-6

Firmware Update patch stack

FWU: Add support for `fwu_fip` target

Firmware update feature needs a new FIP called `fwu_fip.bin` that
includes Secure(SCP_BL2U, BL2U) and Normal world(NS_BL2U) images
along with the FWU_CERT certificate in order for NS_BL1U to load
the images and help the Firmware update process to complete.

This patch adds the capability to support the new target `fwu_fip`
which includes above mentioned FWU images in the make files.

The new target of `fwu_fip` and its dependencies are included for
compilation only when `TRUSTED_BOARD_BOOT` is defined.

Change-Id: Ie780e3aac6cbd0edfaff3f9af96a2332bd69edbc

FWU: Add FWU support to `fip_create` tool

Firmware Update (FWU) introduces a new set of images called
SCP_BL2U, BL2U and NS_BL2U, which can be packed in a FWU FIP file.

This patch introduces new UUIDs for the Firmware Update images
and extends the 'fip'create' tool so that these new images can be
packed in a FIP file.

Change-Id: I7c60211b4f3cc265411efb131e6d3c624768f522

FWU: Add FWU support to `cert_create` tool

Firmware Update requires an X509v3 certificate which contains
hashes for SCP_BL2U, BL2U and NS_BL2U images as extensions.

This patch extends the Chain of Trust definition in the
'cert_create' tool to include the Firmware Update certificate
and the required extensions (including command line options).
A new field in the extension structure will be used to indicate
that the extension is optional. In the case of an image hash
extension, this field will tell the tool that the hash should
be included in the certificate, but filled with zeros.

Change-Id: I1f77a66b018826b71745910771f38d9cf6050388

FWU: Add Firmware Update support in BL2U for ARM platforms

This patch adds support for Firmware update in BL2U for ARM
platforms such that TZC initialization is performed on all
ARM platforms and (optionally) transfer of SCP_BL2U image on
ARM CSS platforms.

BL2U specific functions are added to handle early_platform and
plat_arch setup. The MMU is configured to map in the BL2U
code/data area and other required memory.

Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f

FWU: Add Generic BL2U FWU image support in BL2

The Firmware Update (FWU) feature needs support for an optional
secure world image, BL2U, to allow additional secure world
initialization required by FWU, for example DDR initialization.

This patch adds generic framework support to create BL2U.

NOTE: A platform makefile must supply additional `BL2U_SOURCES`
      to build the bl2u target. A subsequent patch adds bl2u
      support for ARM platforms.

Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413

FWU: Add Firmware Update support in BL1 for ARM platforms

This patch adds Firmware Update support for ARM platforms.

New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
platform specific Firmware update code.

BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
authenticating NS_BL2U image(For both FVP and JUNO platform).

Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555

FWU: Add Generic Firmware Update framework support in BL1

Firmware update(a.k.a FWU) feature is part of the TBB architecture.
BL1 is responsible for carrying out the FWU process if platform
specific code detects that it is needed.

This patch adds support for FWU feature support in BL1 which is
included by enabling `TRUSTED_BOARD_BOOT` compile time flag.

This patch adds bl1_fwu.c which contains all the core operations
of FWU, which are; SMC handler, image copy, authentication, execution
and resumption. It also adds bl1.h introducing #defines for all
BL1 SMCs.

Following platform porting functions are introduced:

int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size,
unsigned int flags);
This function can be used to add platform specific memory checks
for the provided base/size for the given security state.
The weak definition will invoke `assert()` and return -ENOMEM.

__dead2 void bl1_plat_fwu_done(void *cookie, void *reserved);
This function can be used to initiate platform specific procedure
to mark completion of the FWU process.
The weak definition waits forever calling `wfi()`.

plat_bl1_common.c contains weak definitions for above functions.

FWU process starts when platform detects it and return the image_id
other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in
`bl1_main()`.

NOTE: User MUST provide platform specific real definition for
bl1_plat_mem_check() in order to use it for Firmware update.

Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed

Add descriptor based image management support in BL1

As of now BL1 loads and execute BL2 based on hard coded information
provided in BL1. But due to addition of support for upcoming Firmware
Update feature, BL1 now require more flexible approach to load and
run different images using information provided by the platform.

This patch adds new mechanism to load and execute images based on
platform provided image id's. BL1 now queries the platform to fetch
the image id of the next image to be loaded and executed. In order
to achieve this, a new struct image_desc_t was added which holds the
information about images, such as: ep_info and image_info.

This patch introduces following platform porting functions:

unsigned int bl1_plat_get_next_image_id(void);
This is used to identify the next image to be loaded
and executed by BL1.

struct image_desc *bl1_plat_get_image_desc(unsigned int image_id);
This is used to retrieve the image_desc for given image_id.

void bl1_plat_set_ep_info(unsigned int image_id,
struct entry_point_info *ep_info);
This function allows platforms to update ep_info for given
image_id.

The plat_bl1_common.c file provides default weak implementations of
all above functions, the `bl1_plat_get_image_desc()` always return
BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return
BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns.
These functions gets compiled into all BL1 platforms by default.

Platform setup in BL1, using `bl1_platform_setup()`, is now done
_after_ the initialization of authentication module. This change
provides the opportunity to use authentication while doing the
platform setup in BL1.

In order to store secure/non-secure context, BL31 uses percpu_data[]
to store context pointer for each core. In case of BL1 only the
primary CPU will be active hence percpu_data[] is not required to
store the context pointer.

This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to
store the context and context pointers respectively. It also also
re-defines cm_get_context() and cm_set_context() for BL1 in
bl1/bl1_context_mgmt.c.

BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime
environment, to support resuming execution from a previously saved
context.

NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS
      NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE
      THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()`
      INSTEAD TO MAINTAIN EXISTING BEHAVIOUR.

Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881

Move context management code to common location

The upcoming Firmware Update feature needs transitioning across
Secure/Normal worlds to complete the FWU process and hence requires
context management code to perform this task.

Currently context management code is part of BL31 stage only.
This patch moves the code from (include)/bl31 to (include)/common.
Some function declarations/definitions and macros have also moved
to different files to help code sharing.

Change-Id: I3858b08aecdb76d390765ab2b099f457873f7b0c

SoC security setup for CSS platforms in BL1

This patch adds support for secure setup of the SoC on CSS
platforms in BL1.

This change is required to provide memory access to normal
world images that take part in upcoming Firmware Update feature.

Change-Id: Ib202fb6cb82622c1874b700637d82ea72575e6fe

Remove `RUN_IMAGE` usage as opcode passed to next EL.

The primary usage of `RUN_IMAGE` SMC function id, used by BL2 is to
make a request to BL1 to execute BL31. But BL2 also uses it as
opcode to check if it is allowed to execute which is not the
intended usage of `RUN_IMAGE` SMC.

This patch removes the usage of `RUN_IMAGE` as opcode passed to
next EL to check if it is allowed to execute.

Change-Id: I6aebe0415ade3f43401a4c8a323457f032673657

Add uppercase macro to build_macros.mk

This patch adds `uppercase` macro to prepare IMAGE_BLxx defines
used for conditional compilation and to prepare variables used
for defining BL source and linker file names.

This change is needed for upcoming BL images that can have names
which uses both letters and numbers.

Change-Id: I05ce9bcd0d221a54db92c0fe3ad28e9e0080ed2e

Specify BL31 runtime console for ARM Standard platforms

This patch overrides the default weak definition of
`bl31_plat_runtime_setup()` for ARM Standard platforms to
specify a BL31 runtime console. ARM Standard platforms are
now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
`PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
by `arm_bl31_plat_runtime_setup()` to initialize the runtime
console.

The system suspend resume helper `arm_system_pwr_domain_resume()`
is fixed to initialize the runtime console rather than the boot
console on resumption from system suspend.

Fixes ARM-software/tf-issues#220

Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975

Ensure BL31 does not print to boot console by default

It is not ideal for BL31 to continue to use boot console at
runtime which could be potentially uninitialized. This patch
introduces a new optional platform porting API
`bl31_plat_runtime_setup()` which allows the platform to perform
any BL31 runtime setup just prior to BL31 exit during cold boot.
The default weak implementation of this function will invoke
`console_uninit()` which will suppress any BL31 runtime logs.

On the ARM Standard platforms, there is an anomaly that
the boot console will be reinitialized on resumption from
system suspend in `arm_system_pwr_domain_resume()`. This
will be resolved in the following patch.

NOTE: The default weak definition of `bl31_plat_runtime_setup()`
disables the BL31 console. To print the BL31 runtime
messages, platforms must override this API and initialize a
runtime console.

Fixes ARM-software/tf-issues#328

Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a

Introduce console_uninit() API in ARM Trusted Firmware

Allowing console base address to be set to NULL conveniently
allows console driver to ignore further invocations to console_putc()
and console_getc(). This patch adds `console_uninit()` API to the
console driver which sets console base address as NULL. The BL images can
invoke this API to finish the use of console and ignore any further
invocations to print to the console.

Change-Id: I00a1762b3e0b7c55f2be2f9c4c9bee3967189dde

Merge pull request #461 from yatharth-arm/yk/nvidia_patch

Include psci.h from tegra platform header

Include psci.h from tegra platform header

The `plat/nvidia/tegra/include/tegra_private.h` file uses resources
from psci.h (for example, psci_power_state_t) but does not explicitly
include psci.h. This does not currently cause a problem since psci.h
is indirectly included via other headers. However, this may not be
the case in future.

This patch explicitly includes psci.h from tegra_private.h

Change-Id: Ia991147898dbd117c1d3496a95850995a5554c05

Merge pull request #460 from sandrine-bailleux/sb/init-vttbrel2-vmid

Initialize VTTBR_EL2 when bypassing EL2

Initialize VTTBR_EL2 when bypassing EL2

In the situation that EL1 is selected as the exception level for the
next image upon BL31 exit for a processor that supports EL2, the
context management code must configure all essential EL2 register
state to ensure correct execution of EL1.

VTTBR_EL2 should be part of this set of EL2 registers because:
 - The ARMv8-A architecture does not define a reset value for this
   register.
 - Cache maintenance operations depend on VTTBR_EL2.VMID even when
   non-secure EL1&0 stage 2 address translation are disabled.

This patch initializes the VTTBR_EL2 register to 0 when bypassing EL2
to address this issue. Note that this bug has not yet manifested
itself on FVP or Juno because VTTBR_EL2.VMID resets to 0 on the
Cortex-A53 and Cortex-A57.

Change-Id: I58ce2d16a71687126f437577a506d93cb5eecf33

Merge pull request #458 from soby-mathew/sm/rem_tzc_base_assert

Remove the assert for TZC base during initialization

Merge pull request #457 from soby-mathew/sm/fix_fpregs_restore

Fix issue in Floating point register restore

Merge pull request #456 from soby-mathew/sm/gicv3-tsp-plat-changes-v2

Modify TSP and ARM standard platforms for new GIC drivers v2

Merge pull request #455 from jcastillo-arm/jc/fvp_delay_timer

Fix SP804 delay timer on FVP

Fix issue in Floating point register restore

The `fpregs_context_restore()` function used to restore the floating point
regsiter context had a typo error wherein it was doing `str` instead of
`ldr` for a register. This issue remained undetected becuase none of the ARM
Standard development platforms save and restore the floating point register
context when a context switch is done. This patch corrects the issue.

Change-Id: Id178e0ba254a5e0a4a844f54b39d71dc34e0f6ea

TSP: Allow preemption of synchronous S-EL1 interrupt handling

Earlier the TSP only ever expected to be preempted during Standard SMC
processing. If a S-EL1 interrupt triggered while in the normal world, it
will routed to S-EL1 `synchronously` for handling. The `synchronous` S-EL1
interrupt handler `tsp_sel1_intr_entry` used to panic if this S-EL1 interrupt
was preempted by another higher priority pending interrupt which should be
handled in EL3 e.g. Group0 interrupt in GICv3.

With this patch, the `tsp_sel1_intr_entry` now expects `TSP_PREEMPTED` as the
return code from the `tsp_common_int_handler` in addition to 0 (interrupt
successfully handled) and in both cases it issues an SMC with id
`TSP_HANDLED_S_EL1_INTR`. The TSPD switches the context and returns back
to normal world. In case a higher priority EL3 interrupt was pending, the
execution will be routed to EL3 where interrupt will be handled. On return
back to normal world, the pending S-EL1 interrupt which was preempted will
get routed to S-EL1 to be handled `synchronously` via `tsp_sel1_intr_entry`.

Change-Id: I2087c7fedb37746fbd9200cdda9b6dba93e16201

Enable support for EL3 interrupt in IMF

This patch enables support for EL3 interrupts in the Interrupt Management
Framework (IMF) of ARM Trusted Firmware. Please note that although the
registration of the EL3 interrupt type is now supported, it has not been
tested on any of the ARM Standard platforms.

Change-Id: If4dcdc7584621522a2f3ea13ea9b1ad0a76bb8a1

Rework use of ARM GIC drivers on ARM platforms

Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
separate drivers instead of providing a single driver that can work on both
versions of the GIC architecture. These drivers correspond to the following
software use cases:

1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
   e.g. GIC-400

2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
   e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features

3. A deprecated GICv3 driver that operates in legacy mode. This driver can
   operate only in the GICv2 mode in the secure world. On a GICv3 system, this
   driver allows normal world to run in either GICv3 mode (asymmetric mode)
   or in the GICv2 mode. Both modes of operation are deprecated on GICv3
   systems.

ARM platforms implement both versions of the GIC architecture. This patch adds a
layer of abstraction to help ARM platform ports chose the right GIC driver and
corresponding platform support. This is as described below:

1. A set of ARM common functions have been introduced to initialise the GIC and
   the driver during cold and warm boot. These functions are prefixed as
   "plat_arm_gic_". Weak definitions of these functions have been provided for
   each type of driver.

2. Each platform includes the sources that implement the right functions
   directly into the its makefile. The FVP can be instantiated with different
   versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
   to specify which of the three drivers should be included in the build.

3. A list of secure interrupts has to be provided to initialise each of the
  three GIC drivers. For GIC v3.0 the interrupt ids have to be further
  categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
  types are merged and treated as Group 0 interrupts.

  The two lists of interrupts are exported from the platform_def.h. The lists
  are constructed by adding a list of board specific interrupt ids to a list of
  ids common to all ARM platforms and Compute sub-systems.

This patch also makes some fields of `arm_config` data structure in FVP redundant
and these unused fields are removed.

Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8

Prepare platforms to use refactored ARM GIC drivers

This patch adds platform helpers for the new GICv2 and GICv3 drivers in
plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
file in their build according to the GIC driver to be used. The existing
plat_gic.c is only meant for the legacy GIC driver.

In the case of ARM platforms, the major changes are as follows:

1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU
   interface register values has been modified to detect the type of CPU
   interface being used (System register or memory mappped interface) before
   using the right interface to print the registers.

2. The power management helper function that is called after a core is powered
   up has been further refactored. This is to highlight that the per-cpu
   distributor interface should be initialised only when the core was originally
   powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API
   was used.

3. In the case of CSS platforms, the system power domain restore helper
   `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish`
   handler as the system power domain is always expected to be initialized when
   the `on_finish` handler is invoked.

Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6

Merge pull request #454 from yatharth-arm/vk/deprecate-cci-400

Add CCI-400 specific driver to deprecated driver list

Add CCI-400 specific driver to deprecated driver list

Add compile time `__warn_deprecated` flag to public api's in CCI-400
specific driver so that user is aware of the driver being deprecated.
Similarly, it also adds an error message when `ERROR_DEPRECATED` is set
to prevent succesful compilation if CCI-400 specific driver is used.

Change-Id: Id7e61a560262abc01cbbd432ca85b9bf448a194d

Remove the assert for TZC base during initialization

When resuming from system suspend the TZC needs to be
re-initialized. Hence the assertion for TZC base address
to detect re-initialization is removed.

Change-Id: I53d64146f6c919e95526441bb997f7b309c68141

Merge pull request #452 from vwadekar/tegra-new-platform-apis-v2

Tegra new platform apis v2

Tegra: remove support for legacy platform APIs

This patch modifies the Tegra port to support the new platform
APIs so that we can disable the compat layer. This includes
modifications to the power management and platform topology code.

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

Enable use of FIQs and IRQs as TSP interrupts

On a GICv2 system, interrupts that should be handled in the secure world are
typically signalled as FIQs. On a GICv3 system, these interrupts are signalled
as IRQs instead. The mechanism for handling both types of interrupts is the same
in both cases. This patch enables the TSP to run on a GICv3 system by:

1. adding support for handling IRQs in the exception handling code.
2. removing use of "fiq" in the names of data structures, macros and functions.

The build option TSPD_ROUTE_IRQ_TO_EL3 is deprecated and is replaced with a
new build flag TSP_NS_INTR_ASYNC_PREEMPT. For compatibility reasons, if the
former build flag is defined, it will be used to define the value for the
new build flag. The documentation is also updated accordingly.

Change-Id: I1807d371f41c3656322dd259340a57649833065e

Unify interrupt return paths from TSP into the TSPD

The TSP is expected to pass control back to EL3 if it gets preempted due to
an interrupt while handling a Standard SMC in the following scenarios:

1. An FIQ preempts Standard SMC execution and that FIQ is not a TSP Secure
   timer interrupt or is preempted by a higher priority interrupt by the time
   the TSP acknowledges it. In this case, the TSP issues an SMC with the ID
   as `TSP_EL3_FIQ`. Currently this case is never expected to happen as only
   the TSP Secure Timer is expected to generate FIQ.

2. An IRQ preempts Standard SMC execution and in this case the TSP issues
   an SMC with the ID as `TSP_PREEMPTED`.

In both the cases, the TSPD hands control back to the normal world and returns
returns an error code to the normal world to indicate that the standard SMC it
had issued has been preempted but not completed.

This patch unifies the handling of these two cases in the TSPD and ensures that
the TSP only uses TSP_PREEMPTED instead of separate SMC IDs. Also instead of 2
separate error codes, SMC_PREEMPTED and TSP_EL3_FIQ, only SMC_PREEMPTED is
returned as error code back to the normal world.

Background information: On a GICv3 system, when the secure world has affinity
routing enabled, in 2. an FIQ will preempt TSP execution instead of an IRQ. The
FIQ could be a result of a Group 0 or a Group 1 NS interrupt. In both case, the
TSPD passes control back to the normal world upon receipt of the TSP_PREEMPTED
SMC. A Group 0 interrupt will immediately preempt execution to EL3 where it
will be handled. This allows for unified interrupt handling in TSP for both
GICv3 and GICv2 systems.

Change-Id: I9895344db74b188021e3f6a694701ad272fb40d4

Rename GICv3 interrupt group macros

This patch renames the GICv3 interrupt group macros from
INT_TYPE_G0, INT_TYPE_G1S and INT_TYPE_G1NS to INTR_GROUP0,
INTR_GROUP1S and INTR_GROUP1NS respectively.

Change-Id: I40c66f589ce6234fa42205adcd91f7d6ad8f33d4

Fix SP804 delay timer on FVP

This patch fixes several issues with the SP804 delay timer on FVP:

* By default, the SP804 dual timer on FVP runs at 32 KHz. In order
  to run the timer at 35 MHz (as specified in the FVP user manual)
  the Overwrite bit in the SP810 control register must be set.

* The CLKMULT and CLKDIV definitions are mixed up:

      delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)

  From the delay function:

      delta_us = (delta * ops->clk_mult) / ops->clk_div;

  Matching both expressions:

      1 / f(MHz) = ops->clk_mult / ops->clk_div

  And consequently:

      f(MHz) = ops->clk_div / ops->clk_mult

  Which, for a 35 MHz timer, translates to:

      ops->clk_div = 35
      ops->clk_mult = 1

* The comment in the delay timer header file has been corrected:
  The ratio of the multiplier and the divider is the clock period
  in microseconds, not the frequency.

Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1

Merge pull request #446 from vikramkanigiri/vk/tzc-400

Fix TZC-400 peripheral detection

Merge pull request #449 from jcastillo-arm/jc/tbb_oid

TBB: add ARM OIDs

Merge pull request #444 from jcastillo-arm/jc/tbb_wdog

Jc/tbb wdog

TBB: add Trusted Watchdog support on ARM platforms

This patch adds watchdog support on ARM platforms (FVP and Juno).
A secure instance of SP805 is used as Trusted Watchdog. It is
entirely managed in BL1, being enabled in the early platform setup
hook and disabled in the exit hook. By default, the watchdog is
enabled in every build (even when TBB is disabled).

A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
has been introduced to allow the user to disable the watchdog at
build time. This feature may be used for testing or debugging
purposes.

Specific error handlers for Juno and FVP are also provided in this
patch. These handlers will be called after an image load or
authentication error. On FVP, the Table of Contents (ToC) in the FIP
is erased. On Juno, the corresponding error code is stored in the
V2M Non-Volatile flags register. In both cases, the CPU spins until
a watchdog reset is generated after 256 seconds (as specified in
the TBBR document).

Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4

TBB: add ARM OIDs

This patch adds ARM specific OIDs which will be used to extract
the extension data from the certificates. These OIDs are arranged
as a subtree whose root node has been specifically allocated for
ARM Ltd.

    { iso(1) identified-organization(3) dod(6) internet(1)
      private(4) enterprise(1) 4128 }

Change-Id: Ice20b3c8a31ddefe9102f3bd42f7429986f3ac34

Merge pull request #443 from achingupta/sb/el3_payloads-cb_single_cpu

Add support to boot EL3 payloads and only a single CPU at cold reset

Merge pull request #445 from jcastillo-arm/jc/tf-issues/320

Add NULL pointer check before reading BL32 entry point information

Merge pull request #442 from soby-mathew/sm/remove_imf_read_intid

Remove the IMF_READ_INTERRUPT_ID build option

Fix TZC-400 peripheral detection

The TZC-400 driver implementation incorrectly uses the component
ID registers to detect the TZC-400 peripheral. As all ARM
peripherals share the same component ID, it doesn't allow to
uniquely identify the TZC-400 peripheral. This patch fixes the
TZC-400 driver by relying on the `part_number_0` and
`part_number_1` fields in the `PID` registers instead.
The `tzc_read_component_id` function has been replaced by
`tzc_read_peripheral_id`, which reads the 'part_number' values
and compares them with the TZC-400 peripheral ID.

Also, it adds a debug assertion to detect when the TZC driver
initialisation function is called multiple times.

Change-Id: I35949f6501a51c0a794144cd1c3a6db62440dce6

Add a simple ARM SP805 watchdog driver

Based on SP805 Programmer's model (ARM DDI 0270B). This driver
provides three public APIs:

    void sp805_start(uintptr_t base, unsigned long ticks);
    void sp805_stop(uintptr_t base);
    void sp805_refresh(uintptr_t base, unsigned long ticks);

Upon start, the watchdog starts counting down from the number of
ticks specified. When the count reaches 0 an interrupt is triggered.
The watchdog restarts counting down from the number of ticks
specified. If the count reaches 0 again, the system is reset. A
mechanism to handle the interrupt has not been implemented. Instead,
the API to refresh the watchdog should be used instead to prevent a
system reset.

Change-Id: I799d53f8d1213b10b341a4a67fde6486e89a3dab

Add basic NOR flash driver for ARM platforms

FVP and Juno platforms include a NOR flash memory to store and
load the FIP, the kernel or a ramdisk. This NOR flash is arranged
as 2 x 16 bit flash devices and can be programmed using CFI
standard commands.

This patch provides a basic API to write single 32 bit words of
data into the NOR flash. Functions to lock/unlock blocks against
erase or write operations are also provided.

Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2

User Guide: Remove reference to porting guide

The implications of the 'PROGRAMMABLE_RESET_ADDRESS' build option on
the platform porting layer are simple enough to be described in the
User Guide directly. This patch removes the reference to the Porting
Guide.

Change-Id: I7f753b18abd20effc4fd30836609e1fd51d9221d

Introduce COLD_BOOT_SINGLE_CPU build option

This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
which allows platforms that only release a single CPU out of reset to
slightly optimise their cold boot code, both in terms of code size
and performance.

COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform
may release several CPUs out of reset. In this case, the cold reset
code needs to coordinate all CPUs via the usual primary/secondary
CPU distinction.

If a platform guarantees that only a single CPU will ever be released
out of reset, there is no need to arbitrate execution ; the notion of
primary and secondary CPUs itself no longer exists. Such platforms
may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the
primary/secondary CPU identification in the cold reset code.

All ARM standard platforms can release several CPUs out of reset
so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like
Juno, bringing up more than one CPU at reset should only be attempted
when booting an EL3 payload, as it is not fully supported in the
normal boot flow.

For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform
APIs become optional:
  - plat_secondary_cold_boot_setup();
  - plat_is_my_cpu_primary().
The Porting Guide has been updated to reflect that.

User Guide updated as well.

Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b

Document the EL3 payload support

 - Document the new build option EL3_PAYLOAD_BASE

 - Document the EL3 payload boot flow

 - Document the FVP model parameters to boot an EL3 payload

Change-Id: Ie6535914a9a68626e4401659bee4fcfd53d4bd37

FVP: Do not power off secondary CPUs when booting an EL3 payload

Normally, in the FVP port, secondary CPUs are immediately powered
down if they are powered on at reset. However, when booting an EL3
payload, we need to keep them powered on as the requirement is for
all CPUs to enter the EL3 payload image. This patch puts them in a
holding pen instead of powering them off.

Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c

CSS: Put secondary CPUs in a pen when booting an EL3 payload

By default, only the primary CPU is powered on by SCP on CSS
platforms. Secondary CPUs are then powered on later using PSCI
calls.

However, it is possible to power on more than one CPU at boot time
using platform specific settings. In this case, several CPUs will
enter the Trusted Firmware and execute the cold boot path code.
This is currently not supported and secondary CPUs will panic.

This patch preserves this behaviour in the normal boot flow.
However, when booting an EL3 payload, secondary CPUs are now held in
a pen until their mailbox is populated, at which point they jump to
this address. Note that, since all CPUs share the same mailbox, they
will all be released from their holding pen at the same time and the
EL3 payload is responsible to arbitrate execution between CPUs if
required.

Change-Id: I83737e0c9f15ca5e73afbed2e9c761bc580735b9

CSS: Enable booting of EL3 payloads

This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.

Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.

The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.

The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.

The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.

This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.

Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077

Pass the entry point info to bl1_plat_prepare_exit()

This patch modifies the prototype of the bl1_plat_prepare_exit()
platform API to pass the address of the entry point info structure
received from BL2. The structure contains information that can be
useful, depending on the kind of clean up or bookkeeping operations
to perform.

The weak implementation of this function ignores this argument to
preserve platform backwards compatibility.

NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE
FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API.

Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb

Introduce SPIN_ON_BL1_EXIT build flag

This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which
puts an infinite loop in BL1. It is intended to help debugging
the post-BL2 phase of the Trusted Firmware by stopping execution
in BL1 just before handing over to BL31. At this point, the
developer may take control of the target using a debugger.

This feature is disabled by default and can be enabled by
rebuilding BL1 with SPIN_ON_BL1_EXIT=1.

User Guide updated accordingly.

Change-Id: I6b6779d5949c9e5571dd371255520ef1ac39685c

Remove the IMF_READ_INTERRUPT_ID build option

The IMF_READ_INTERRUPT_ID build option enables a feature where the interrupt
ID of the highest priority pending interrupt is passed as a parameter to the
interrupt handler registered for that type of interrupt. This additional read
of highest pending interrupt id from GIC is problematic as it is possible that
the original interrupt may get deasserted and another interrupt of different
type maybe become the highest pending interrupt. Hence it is safer to prevent
such behaviour by removing the IMF_READ_INTERRUPT_ID build option.

The `id` parameter of the interrupt handler `interrupt_type_handler_t` is
now made a reserved parameter with this patch. It will always contain
INTR_ID_UNAVAILABLE.

Fixes ARM-software/tf-issues#307

Change-Id: I2173aae1dd37edad7ba6bdfb1a99868635fa34de

Merge pull request #439 from soby-mathew/sm/new-gic-driver

Introduce new GICv3 and GICv2 drivers

Deprecate the GIC Legacy driver.

This patch deprecates the legacy ARM GIC driver and related header files
(arm_gic.h, gic_v2.h, gic_v3.h). For GICv2 systems, platform ports should
use the GICv2 driver in include/drivers/arm/gicv2.h and for GICv3 systems,
platform ports should use the GICv3 driver in include/drivers/arm/gicv3.h

NOTE: The ARM Legacy GIC drivers have been deprecated with this patch.
Platform ports are encouraged to migrate to the new GIC drivers.

Change-Id: Ic0460ef0427b54a6aac476279a7f29b81943e942

Add ARM GICv2 driver

This patch adds a driver for ARM GICv2 systems, example GIC-400. Unlike
the existing GIC driver in `include/drivers/arm/arm_gic.h`, this driver
is optimised for GICv2 and does not support GICv3 systems in GICv2
compatibility mode. The driver interface has been implemented in
`drivers/arm/gic/v2/gicv2_main.c`. The corresponding header is in
`include/drivers/arm/gicv2.h`. Helper functions are implemented in
`drivers/arm/gic/v2/gicv2_helpers.c` and are accessible through the
`drivers/arm/gic/v2/gicv2_private.h` header.

Change-Id: I09fffa4e621fb99ba3c01204839894816cd89a2a

Add ARM GICv3 driver without support for legacy operation

This patch adds a driver for ARM GICv3 systems that need to run software
stacks where affinity routing is enabled across all privileged exception
levels for both security states. This driver is a partial implementation
of the ARM Generic Interrupt Controller Architecture Specification, GIC
architecture version 3.0 and version 4.0 (ARM IHI 0069A). The driver does
not cater for legacy support of interrupts and asymmetric configurations.

The existing GIC driver has been preserved unchanged. The common code for
GICv2 and GICv3 systems has been refactored into a new file,
`drivers/arm/gic/common/gic_common.c`. The corresponding header is in
`include/drivers/arm/gic_common.h`.

The driver interface is implemented in `drivers/arm/gic/v3/gicv3_main.c`.
The corresponding header is in `include/drivers/arm/gicv3.h`. Helper
functions are implemented in `drivers/arm/gic/v3/arm_gicv3_helpers.c`
and are accessible through the `drivers/arm/gic/v3/gicv3_private.h`
header.

Change-Id: I8c3c834a1d049d05b776b4dcb76b18ccb927444a

Merge pull request #438 from soby-mathew/sm/error_deprecate

Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED

Tegra: flowctrl: rename tegra_fc_cpu_idle() to tegra_fc_cpu_powerdn()

This patch renames the tegra_fc_cpu_idle() function to a more appropriate
tegra_fc_cpu_powerdn() to better reflect its usage.

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED

This patch changes the build time behaviour when using deprecated API within
Trusted Firmware. Previously the use of deprecated APIs would only trigger a
build warning (which was always treated as a build error), when
WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always
trigger a build time warning. Whether this warning is treated as error or not
is determined by the build flag ERROR_DEPRECATED which is disabled by default.
When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or
inclusion of deprecated headers will result in a build error.

Also the deprecated context management helpers in context_mgmt.c are now
conditionally compiled depending on the value of ERROR_DEPRECATED flag
so that the APIs themselves do not result in a build error when the
ERROR_DEPRECATED flag is set.

NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to
using ERROR_DEPRECATED, otherwise deprecated API usage will no longer
trigger a build error.

Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a

Merge pull request #435 from sandrine-bailleux/sb/juno-r2

Changes to platform reset handler for Juno r2

Merge pull request #429 from vikramkanigiri/vk/fix_sctlr_res1

Add missing RES1 bit in SCTLR_EL1

Merge pull request #430 from jcastillo-arm/jc/tf-issues/333

Fix build error when `BL32` is not defined

Juno R2: Configure the correct L2 RAM latency values

The default reset values for the L2 Data & Tag RAM latencies on the
Cortex-A72 on Juno R2 are not suitable. This patch modifies
the Juno platform reset handler to configure the right settings
on Juno R2.

Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8