PSCI: Fix the return code for invalid entrypoint

As per PSCI1.0 specification, the error code to be returned when an invalid
non secure entrypoint address is specified by the PSCI client for CPU_SUSPEND,
CPU_ON or SYSTEM_SUSPEND must be PSCI_E_INVALID_ADDRESS. The current PSCI
implementation returned PSCI_E_INVAL_PARAMS. This patch rectifies this error
and also implements a common helper function to validate the entrypoint
information to be used across these PSCI API implementations.

Change-Id: I52d697d236c8bf0cd3297da4008c8e8c2399b170

PSCI: Migrate SPDs and TSP to the new platform and framework API

The new PSCI frameworks mandates that the platform APIs and the various
frameworks in Trusted Firmware migrate away from MPIDR based core
identification to one based on core index. Deprecated versions of the old
APIs are still present to provide compatibility but their implementations
are not optimal. This patch migrates the various SPDs exisiting within
Trusted Firmware tree and TSP to the new APIs.

Change-Id: Ifc37e7071c5769b5ded21d0b6a071c8c4cab7836

PSCI: Pool platform_mem_init() in common ARM platforms code

Now that the FVP mailbox is no longer zeroed, the function
platform_mem_init() does nothing both on FVP and on Juno. Therefore,
this patch pools it as the default implementation on ARM platforms.

Change-Id: I007220f4531f15e8b602c3368a1129a5e3a38d91

PSCI: Use a single mailbox for warm reset for FVP and Juno

Since there is a unique warm reset entry point, the FVP and Juno
port can use a single mailbox instead of maintaining one per core.
The mailbox gets programmed only once when plat_setup_psci_ops()
is invoked during PSCI initialization. This means mailbox is not
zeroed out during wakeup.

Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432

PSCI: Demonstrate support for composite power states

This patch adds support to the Juno and FVP ports for composite power states
with both the original and extended state-id power-state formats. Both the
platform ports use the recommended state-id encoding as specified in
Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
ARM_RECOM_STATE_ID_ENC is used to include this support.

By default, to maintain backwards compatibility, the original power state
parameter format is used and the state-id field is expected to be zero.

Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10

PSCI: Migrate ARM reference platforms to new platform API

This patch migrates ARM reference platforms, Juno and FVP, to the new platform
API mandated by the new PSCI power domain topology and composite power state
frameworks. The platform specific makefiles now exports the build flag
ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.

Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29

PSCI: Migrate TF to the new platform API and CM helpers

This patch migrates the rest of Trusted Firmware excluding Secure Payload and
the dispatchers to the new platform and context management API. The per-cpu
data framework APIs which took MPIDRs as their arguments are deleted and only
the ones which take core index as parameter are retained.

Change-Id: I839d05ad995df34d2163a1cfed6baa768a5a595d

PSCI: Add deprecated API for SPD when compatibility is disabled

This patch defines deprecated platform APIs to enable Trusted
Firmware components like Secure Payload and their dispatchers(SPD)
to continue to build and run when platform compatibility is disabled.
This decouples the migration of platform ports to the new platform API
from SPD and enables them to be migrated independently. The deprecated
platform APIs defined in this patch are : platform_get_core_pos(),
platform_get_stack() and platform_set_stack().

The patch also deprecates MPIDR based context management helpers like
cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context().
A mechanism to deprecate APIs and identify callers of these APIs during
build is introduced, which is controlled by the build flag WARN_DEPRECATED.
If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be
flagged either as a link error for assembly files or compile time warning
for C files during build.

Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613

PSCI: Switch to the new PSCI frameworks

This commit does the switch to the new PSCI framework implementation replacing
the existing files in PSCI folder with the ones in PSCI1.0 folder. The
corresponding makefiles are modified as required for the new implementation.
The platform.h header file is also is switched to the new one
as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults
to 1 to enable compatibility layer which let the existing platform ports to
continue to build and run with minimal changes.

The default weak implementation of platform_get_core_pos() is now removed from
platform_helpers.S and is provided by the compatibility layer.

Note: The Secure Payloads and their dispatchers still use the old platform
and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build
flag will remain enabled in subsequent patch. The compatibility for SPDs using
the older APIs on platforms migrated to the new APIs will be added in the
following patch.

Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719

PSCI: Implement platform compatibility layer

The new PSCI topology framework and PSCI extended State framework introduces
a breaking change in the platform port APIs. To ease the migration of the
platform ports to the new porting interface, a compatibility layer is
introduced which essentially defines the new platform API in terms of the
old API. The old PSCI helpers to retrieve the power-state, its associated
fields and the highest coordinated physical OFF affinity level of a core
are also implemented for compatibility. This allows the existing
platform ports to work with the new PSCI framework without significant
rework. This layer will be enabled by default once the switch to the new
PSCI framework is done and is controlled by the build flag ENABLE_PLAT_COMPAT.

Change-Id: I4b17cac3a4f3375910a36dba6b03d8f1700d07e3

PSCI: Unify warm reset entry points

There used to be 2 warm reset entry points:

 - the "on finisher", for when the core has been turned on using a
   PSCI CPU_ON call;

 - the "suspend finisher", entered upon resumption from a previous
   PSCI CPU_SUSPEND call.

The appropriate warm reset entry point used to be programmed into the
mailboxes by the power management hooks.

However, it is not required to provide this information to the PSCI
entry point code, as it can figure it out by itself. By querying affinity
info state, a core is able to determine on which execution path it is.
If the state is ON_PENDING then it means it's been turned on else
it is resuming from suspend.

This patch unifies the 2 warm reset entry points into a single one:
psci_entrypoint(). The patch also implements the necessary logic
to distinguish between the 2 types of warm resets in the power up
finisher.

The plat_setup_psci_ops() API now takes the
secure entry point as an additional parameter to enable the platforms
to configure their mailbox. The platform hooks `pwr_domain_on`
and `pwr_domain_suspend` no longer take secure entry point as
a parameter.

Change-Id: I7d1c93787b54213aefdbc046b8cd66a555dfbfd9

PSCI: Add framework to handle composite power states

The state-id field in the power-state parameter of a CPU_SUSPEND call can be
used to describe composite power states specific to a platform. The current PSCI
implementation does not interpret the state-id field. It relies on the target
power level and the state type fields in the power-state parameter to perform
state coordination and power management operations. The framework introduced
in this patch allows the PSCI implementation to intepret generic global states
like RUN, RETENTION or OFF from the State-ID to make global state coordination
decisions and reduce the complexity of platform ports. It adds support to
involve the platform in state coordination which facilitates the use of
composite power states and improves the support for entering standby states
at multiple power domains.

The patch also includes support for extended state-id format for the power
state parameter as specified by PSCIv1.0.

The PSCI implementation now defines a generic representation of the power-state
parameter. It depends on the platform port to convert the power-state parameter
(possibly encoding a composite power state) passed in a CPU_SUSPEND call to this
representation via the `validate_power_state()` plat_psci_ops handler. It is an
array where each index corresponds to a power level. Each entry contains the
local power state the power domain at that power level could enter.

The meaning of the local power state values is platform defined, and may vary
between levels in a single platform. The PSCI implementation constrains the
values only so that it can classify the state as RUN, RETENTION or OFF as
required by the specification:
   * zero means RUN
   * all OFF state values at all levels must be higher than all RETENTION
     state values at all levels
   * the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values
     to the framework

The platform also must define the macros PLAT_MAX_RET_STATE and
PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power
domains have been requested to enter a retention or power down state. The PSCI
implementation does not interpret the local power states defined by the
platform. The only constraint is that the PLAT_MAX_RET_STATE <
PLAT_MAX_OFF_STATE.

For a power domain tree, the generic implementation maintains an array of local
power states. These are the states requested for each power domain by all the
cores contained within the domain. During a request to place multiple power
domains in a low power state, the platform is passed an array of requested
power-states for each power domain through the plat_get_target_pwr_state()
API. It coordinates amongst these states to determine a target local power
state for the power domain. A default weak implementation of this API is
provided in the platform layer which returns the minimum of the requested
power-states back to the PSCI state coordination.

Finally, the plat_psci_ops power management handlers are passed the target
local power states for each affected power domain using the generic
representation described above. The platform executes operations specific to
these target states.

The platform power management handler for placing a power domain in a standby
state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for
placing a core power domain into a standby or retention state should now be
used to only place the core power domain in a standby or retention state.

The extended state-id power state format can be enabled by setting the
build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default.

Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c

PSCI: Introduce new platform interface to describe topology

This patch removes the assumption in the current PSCI implementation that MPIDR
based affinity levels map directly to levels in a power domain tree. This
enables PSCI generic code to support complex power domain topologies as
envisaged by PSCIv1.0 specification. The platform interface for querying
the power domain topology has been changed such that:

1. The generic PSCI code does not generate MPIDRs and use them to query the
   platform about the number of power domains at a particular power level. The
   platform now provides a description of the power domain tree on the SoC
   through a data structure. The existing platform APIs to provide the same
   information have been removed.

2. The linear indices returned by plat_core_pos_by_mpidr() and
   plat_my_core_pos() are used to retrieve core power domain nodes from the
   power domain tree. Power domains above the core level are accessed using a
   'parent' field in the tree node descriptors.

The platform describes the power domain tree in an array of 'unsigned
char's. The first entry in the array specifies the number of power domains at
the highest power level implemented in the system. Each susbsequent entry
corresponds to a power domain and contains the number of power domains that are
its direct children. This array is exported to the generic PSCI implementation
via the new `plat_get_power_domain_tree_desc()` platform API.

The PSCI generic code uses this array to populate its internal power domain tree
using the Breadth First Search like algorithm. The tree is split into two
arrays:

1. An array that contains all the core power domain nodes

2. An array that contains all the other power domain nodes

A separate array for core nodes allows certain core specific optimisations to
be implemented e.g. remove the bakery lock, re-use per-cpu data framework for
storing some information.

Entries in the core power domain array are allocated such that the
array index of the domain is equal to the linear index returned by
plat_core_pos_by_mpidr() and plat_my_core_pos() for the MPIDR
corresponding to that domain. This relationship is key to be able to use
an MPIDR to find the corresponding core power domain node, traverse to higher
power domain nodes and index into arrays that contain core specific
information.

An introductory document has been added to briefly describe the new interface.

Change-Id: I4b444719e8e927ba391cae48a23558308447da13

PSCI: Introduce new platform and CM helper APIs

This patch introduces new platform APIs and context management helper APIs
to support the new topology framework based on linear core position. This
framework will be introduced in the follwoing patch and it removes the
assumption that the MPIDR based affinity levels map directly to levels
in a power domain tree. The new platforms APIs and context management
helpers based on core position are as described below:

* plat_my_core_pos() and plat_core_pos_by_mpidr()

These 2 new mandatory platform APIs are meant to replace the existing
'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the
linear index of the calling core and 'plat_core_pos_by_mpidr()' returns
the linear index of a core specified by its MPIDR. The latter API will also
validate the MPIDR passed as an argument and will return an error code (-1)
if an invalid MPIDR is passed as the argument. This enables the caller to
safely convert an MPIDR of another core to its linear index without querying
the PSCI topology tree e.g. during a call to PSCI CPU_ON.

Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always
platform specific, it is no longer possible to maintain a default implementation
of this API. Also it might not be possible for a platform port to verify an
MPIDR before the C runtime has been setup or the topology has been initialized.
This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to
topology setup. As a result, the generic Trusted Firmware code does not call
this API before the topology setup has been done.

The 'plat_my_core_pos' API should be able to run without a C runtime.
Since this API needs to return a core position which is equal to the one
returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR,
this too cannot have default implementation and is a mandatory API for
platform ports. These APIs will be implemented by the ARM reference platform
ports later in the patch stack.

* plat_get_my_stack() and plat_set_my_stack()

These APIs are the stack management APIs which set/return stack addresses
appropriate for the calling core. These replace the 'platform_get_stack()' and
'platform_set_stack()' APIs. A default weak MP version and a global UP version
of these APIs are provided for the platforms.

* Context management helpers based on linear core position

A set of new context management(CM) helpers viz cm_get_context_by_index(),
cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index()
are defined which are meant to replace the old helpers which took MPIDR
as argument. The old CM helpers are implemented based on the new helpers to
allow for code consolidation and will be deprecated once the switch to the new
framework is done.

Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69

PSCI: Remove references to affinity based power management

As per Section 4.2.2. in the PSCI specification, the term "affinity"
is used in the context of describing the hierarchical arrangement
of cores. This often, but not always, maps directly to the processor
power domain topology of the system. The current PSCI implementation
assumes that this is always the case i.e. MPIDR based levels of
affinity always map to levels in a power domain topology tree.

This patch is the first in a series of patches which remove this
assumption. It removes all occurences of the terms "affinity
instances and levels" when used to describe the power domain
topology. Only the terminology is changed in this patch. Subsequent
patches will implement functional changes to remove the above
mentioned assumption.

Change-Id: Iee162f051b228828310610c5a320ff9d31009b4e

PSCI: Invoke PM hooks only for the highest level

This patch optimizes the invocation of the platform power management hooks for
ON, OFF and SUSPEND such that they are called only for the highest affinity
level which will be powered off/on. Earlier, the hooks were being invoked for
all the intermediate levels as well.

This patch requires that the platforms migrate to the new semantics of the PM
hooks.  It also removes the `state` parameter from the pm hooks as the `afflvl`
parameter now indicates the highest affinity level for which power management
operations are required.

Change-Id: I57c87931d8a2723aeade14acc710e5b78ac41732

PSCI: Create new directory to implement new frameworks

This patch creates a copy of the existing PSCI files and related psci.h and
platform.h header files in a new `PSCI1.0` directory. The changes for the
new PSCI power domain topology and extended state-ID frameworks will be
added incrementally to these files. This incremental approach will
aid in review and in understanding the changes better. Once all the
changes have been introduced, these files will replace the existing PSCI
files.

Change-Id: Ibb8a52e265daa4204e34829ed050bddd7e3316ff

Merge pull request #337 from vwadekar/tegra-misc-fixes-v3

Tegra misc fixes v3

Tegra: Introduce config for enabling NS access to L2/CPUECTRL regs

A new config, ENABLE_NS_L2_CPUECTRL_RW_ACCESS, allows Tegra platforms to
enable read/write access to the L2 and CPUECTRL registers. T210 is the
only platform that needs to enable this config for now.

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

Tegra210: lock PMC registers holding CPU vector addresses

This patch locks access to the PMC registers which hold the CPU reset
vector addresses. The PMC registers are used by the warmboot code and
must be locked during boot/resume to avoid booting into custom firmware
installed by unknown parties e.g. hackers.

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

Tegra: PMC: lock SCRATCH22 register

The PMC Scratch22 register contains the CPU reset vector to
be used by the warmboot code to power up the CPU while resuming
from  system suspend. This patch locks this PMC register to avoid
any further writes.

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

Tegra: PMC: check if a CPU is already online

This patch checks if the target CPU is already online before
proceeding with it's power ON sequence.

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

Tegra210: deassert CPU reset signals during power on

This patch de-asserts the CPU reset signals for each CPU as
part of it's power on sequence. This is needed to get rid of
the wait in BPMP firmware during SC7 exit.

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

Tegra: Fix the delay loop used during SC7 exit

This patch fixes the delay loop used to wake up the BPMP during SC7 exit.
The earlier loop would fail just when the timer was about to wrap-around
(e.g. when TEGRA_TMRUS_BASE is 0xfffffffe, the target value becomes 0,
which would cause the loop to exit before it's expiry).

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

Tegra: introduce delay timer support

This patch introduces the backend required for implementing the delay
timer API. Tegra has an on-chip free flowing us timer which can be
used as the delay timer.

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

Merge pull request #336 from danh-arm/sb/move-user-guide-to-linaro-release

Update user guide to use Linaro releases

Merge pull request #335 from jcastillo-arm/jc/sh_write

Fix bug in semihosting write function

Merge pull request #332 from jcastillo-arm/jc/tf-issues/214

Use uintptr_t as base address type in ARM driver APIs

Tegra: Exclude coherent memory region from memory map

This patch sets the 'USE_COHERENT_MEM' flag to '0', so that the
coherent memory region will not be included in the memory map.

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

Fix bug in semihosting write function

The return value from the SYS_WRITE semihosting operation is 0 if
the call is successful or the number of bytes not written, if there
is an error. The implementation of the write function in the
semihosting driver treats the return value as the number of bytes
written, which is wrong. This patch fixes it.

Change-Id: Id39dac3d17b5eac557408b8995abe90924c85b85

Update user guide to use Linaro releases

Linaro produce monthly software releases for the Juno and AEMv8-FVP
platforms. These provide an integrated set of software components
that have been tested together on these platforms.

From now on, it is recommend that Trusted Firmware developers use the
Linaro releases (currently 15.06) as a baseline for the dependent
software components: normal world firmware, Linux kernel and device
tree, file system as well as any additional micro-controller firmware
required by the platform.

This patch updates the user guide to document this new process. It
changes the instructions to get the source code of the full software
stack (including Trusted Firmware) and updates the dependency build
instructions to make use of the build scripts that the Linaro releases
provide.

Change-Id: Ia8bd043f4b74f1e1b10ef0d12cc8a56ed3c92b6e

Use uintptr_t as base address type in ARM driver APIs

This patch changes the type of the base address parameter in the
ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The
uintptr_t type allows coverage of the whole memory space and to
perform arithmetic operations on the addresses. ARM platform code
has also been updated to use uintptr_t as GIC base address in the
configuration.

Fixes ARM-software/tf-issues#214

Change-Id: I1b87daedadcc8b63e8f113477979675e07d788f1

Merge pull request #329 from vwadekar/tegra-system-suspend-v3

Implement get_sys_suspend_power_state() handler for Tegra

Implement get_sys_suspend_power_state() handler for Tegra

This patch implements the get_sys_suspend_power_state() handler required by
the PSCI SYSTEM_SUSPEND API. The intent of this handler is to return the
appropriate State-ID field which can be utilized in `affinst_suspend()` to
suspend to system affinity level.

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

Merge pull request #324 from soby-mathew/sm/sys_suspend

PSCI: Add SYSTEM_SUSPEND API support

Merge pull request #326 from jcastillo-arm/jc/tbb_ecdsa

TBB: build 'cert_create' with ECDSA only if OpenSSL supports it

TBB: build 'cert_create' with ECDSA only if OpenSSL supports it

Some Linux distributions include an OpenSSL library which has been
built without ECDSA support. Trying to build the certificate
generation tool on those distributions will result in a build error.

This patch fixes that issue by including ECDSA support only if
OpenSSL has been built with ECDSA. In that case, the OpenSSL
configuration file does not define the OPENSSL_NO_EC macro. The tool
will build successfully, although the resulting binary will not
support ECDSA keys.

Change-Id: I4627d1abd19eef7ad3251997d8218599187eb902

Merge pull request #315 from jcastillo-arm/jc/tbb_tmp9

Authentication Framework

TBB: add authentication framework documentation

This patch updates the user guide, adding instructions to build the
Trusted Firmware with Trusted Board Support using the new framework.

It also provides documentation about the framework itself, including
a detailed section about the TBBR implementation using the framework.

Change-Id: I0849fce9c5294cd4f52981e7a8423007ac348ec6

TBB: delete deprecated plat_match_rotpk()

The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.

Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b

TBB: delete deprecated PolarSSL authentication module

After updating the main authentication module to use the transport
and crypto modules and the CoT description, the PolarSSL
authentication module is no longer required. This patch deletes it.

Change-Id: I8ba1e13fc1cc7b2fa9df14ff59eb798f0460b878

TBB: switch to the new authentication framework

This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto module and the image parser module to
authenticate the images in the Chain of Trust.

A new function 'load_auth_image()' has been implemented. When TBB
is enabled, this function will call the authentication module to
authenticate parent images following the CoT up to the root of
trust to finally load and authenticate the requested image.

The platform is responsible for picking up the right makefiles to
build the corresponding cryptographic and image parser libraries.
ARM platforms use the mbedTLS based libraries.

The platform may also specify what key algorithm should be used
to sign the certificates. This is done by declaring the 'KEY_ALG'
variable in the platform makefile. FVP and Juno use ECDSA keys.

On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
each to accommodate the ECDSA code.

REMOVED BUILD OPTIONS:

  * 'AUTH_MOD'

Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867

TBB: add ECDSA support to the certificate generation tool

This patch extends the 'cert_create' tool to support ECDSA keys
to sign the certificates. The '--key-alg' command line option
can be used to specify the key algorithm when invoking the tool.
Available options are:

    * 'rsa': create RSA-2048 keys (default option)
    * 'ecdsa': create ECDSA-SECP256R1 keys

The TF Makefile has been updated to allow the platform to specify
the key algorithm by declaring the 'KEY_ALG' variable in the
platform makefile.

The behaviour regarding key management has changed. After applying
this patch, the tool will try first to open the keys from disk. If
one key does not exist or no key is specified, and the command line
option to create keys has been specified, new keys will be created.
Otherwise an error will be generated and the tool will exit. This
way, the user may specify certain keys while the tool will create
the remaining ones. This feature is useful for testing purposes
and CI infrastructures.

The OpenSSL directory may be specified using the build option
'OPENSSL_DIR' when building the certificate generation tool.
Default is '/usr'.

Change-Id: I98bcc2bfab28dd7179f17f1177ea7a65698df4e7

TBB: add TBBR Chain of Trust

This patch adds a CoT based on the Trusted Board Boot Requirements
document*. The CoT consists of an array of authentication image
descriptors indexed by the image identifiers.

A new header file with TBBR image identifiers has been added.
Platforms that use the TBBR (i.e. ARM platforms) may reuse these
definitions as part of their platform porting.

PLATFORM PORT - IMPORTANT:

Default image IDs have been removed from the platform common
definitions file (common_def.h). As a consequence, platforms that
used those common definitons must now either include the IDs
provided by the TBBR header file or define their own IDs.

*The NVCounter authentication method has not been implemented yet.

Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5

TBB: add mbedTLS authentication related libraries

This patch adds the following mbedTLS based libraries:

* Cryptographic library

It is used by the crypto module to verify a digital signature
and a hash. This library relies on mbedTLS to perform the
cryptographic operations. mbedTLS sources must be obtained
separately.

Two key algorithms are currently supported:

    * RSA-2048
    * ECDSA-SECP256R1

The platform is responsible for picking up the required
algorithm by defining the 'MBEDTLS_KEY_ALG' variable in the
platform makefile. Available options are:

    * 'rsa' (for RSA-2048) (default option)
    * 'ecdsa' (for ECDSA-SECP256R1)

Hash algorithm currently supported is SHA-256.

* Image parser library

Used by the image parser module to extract the authentication
parameters stored in X509v3 certificates.

Change-Id: I597c4be3d29287f2f18b82846973afc142ee0bf0

TBB: add authentication framework

This patch adds the authentication framework that will be used as
the base to implement Trusted Board Boot in the Trusted Firmware.
The framework comprises the following modules:

- Image Parser Module (IPM)

    This module is responsible for interpreting images, check
    their integrity and extract authentication information from
    them during Trusted Board Boot.

    The module currently supports three types of images i.e.
    raw binaries, X509v3 certificates and any type specific to
    a platform. An image parser library must be registered for
    each image type (the only exception is the raw image parser,
    which is included in the main module by default).

    Each parser library (if used) must export a structure in a
    specific linker section which contains function pointers to:

        1. Initialize the library
        2. Check the integrity of the image type supported by
           the library
        3. Extract authentication information from the image

- Cryptographic Module (CM)

    This module is responsible for verifying digital signatures
    and hashes. It relies on an external cryptographic library
    to perform the cryptographic operations.

    To register a cryptographic library, the library must use the
    REGISTER_CRYPTO_LIB macro, passing function pointers to:

        1. Initialize the library
        2. Verify a digital signature
        3. Verify a hash

    Failing to register a cryptographic library will generate
    a build time error.

- Authentication Module (AM)

    This module provides methods to authenticate an image, like
    hash comparison or digital signatures. It uses the image parser
    module to extract authentication parameters, the crypto module
    to perform cryptographic operations and the Chain of Trust to
    authenticate the images.

    The Chain of Trust (CoT) is a data structure that defines the
    dependencies between images and the authentication methods
    that must be followed to authenticate an image.

The Chain of Trust, when added, must provide a header file named
cot_def.h with the following definitions:

- COT_MAX_VERIFIED_PARAMS

    Integer value indicating the maximum number of authentication
    parameters an image can present. This value will be used by the
    authentication module to allocate the memory required to load
    the parameters in the image descriptor.

Change-Id: Ied11bd5cd410e1df8767a1df23bb720ce7e58178

TBB: add platform API to read the ROTPK information

This patch extends the platform port by adding an API that returns
either the Root of Trust public key (ROTPK) or its hash. This is
usually stored in ROM or eFUSE memory. The ROTPK returned must be
encoded in DER format according to the following ASN.1 structure:

    SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm           AlgorithmIdentifier,
        subjectPublicKey    BIT STRING
    }

In case the platform returns a hash of the key:

    DigestInfo  ::= SEQUENCE {
        digestAlgorithm     AlgorithmIdentifier,
        keyDigest           OCTET STRING
    }

An implementation for ARM development platforms is provided in this
patch. When TBB is enabled, the ROTPK hash location must be specified
using the build option 'ARM_ROTPK_LOCATION'. Available options are:

    - 'regs' : return the ROTPK hash stored in the Trusted
      root-key storage registers.

    - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
      BL2 binaries. This hash has been obtained from the development
      RSA public key located in 'plat/arm/board/common/rotpk'.

On FVP, the number of MMU tables has been increased to map and
access the ROTPK registers.

A new file 'board_common.mk' has been added to improve code sharing
in the ARM develelopment platforms.

Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf

Use numbers to identify images instead of names

The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in the platform function plat_get_image_source(). For
a given image name, it returns the handle to the image file which
involves comparing images names. In addition, if the image is
packaged in a FIP, a name comparison is required to find the UUID
for the image. This method is not optimal.

This patch changes the interface between the generic and platform
code with regard to identifying images. The platform port must now
allocate a unique number (ID) for every image. The generic code will
use the image ID instead of the name to access its attributes.

As a result, the plat_get_image_source() function now takes an image
ID as an input parameter. The organisation of data structures within
the IO framework has been rationalised to use an image ID as an index
into an array which contains attributes of the image such as UUID and
name. This prevents the name comparisons.

A new type 'io_uuid_spec_t' has been introduced in the IO framework
to specify images identified by UUID (i.e. when the image is contained
in a FIP file). There is no longer need to maintain a look-up table
[iname_name --> uuid] in the io_fip driver code.

Because image names are no longer mandatory in the platform port, the
debug messages in the generic code will show the image identifier
instead of the file name. The platforms that support semihosting to
load images (i.e. FVP) must provide the file names as definitions
private to the platform.

The ARM platform ports and documentation have been updated accordingly.
All ARM platforms reuse the image IDs defined in the platform common
code. These IDs will be used to access other attributes of an image in
subsequent patches.

IMPORTANT: applying this patch breaks compatibility for platforms that
use TF BL1 or BL2 images or the image loading code. The platform port
must be updated to match the new interface.

Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5

TBB: replace assert() with runtime checks in PolarSSL module

Using assert() to check the length of keys and hashes included in
a certificate is not a safe approach because assert() only applies
to debug builds. A malformed certificate could exploit security
flaws in release binaries due to buffer overflows.

This patch replaces assert() with runtime checkings in the PolarSSL
authentication module, so malformed certificates can not cause a
memory overflow.

Change-Id: I42ba912020595752c806cbd242fe3c74077d993b

TBB: use ASN.1 type DigestInfo to represent hashes

The cert_create tool calculates the hash of each BL image and includes
it as an ASN.1 OCTET STRING in the corresponding certificate extension.
Without additional information, the firmware running on the platform
has to know in advance the algorithm used to generate the hash.

This patch modifies the cert_create tool so the certificate extensions
that include an image hash are generated according to the following
ASN.1 structure:

    DigestInfo ::= SEQUENCE {
        digestAlgorithm  AlgorithmIdentifier,
        digest           OCTET STRING
    }

    AlgorithmIdentifier ::=  SEQUENCE  {
        algorithm        OBJECT IDENTIFIER,
        parameters       ANY DEFINED BY algorithm OPTIONAL
    }

The PolarSSL module has been updated to extract the image hash
from the certificate extension according to this structure.

Change-Id: I6d83430f12a8a0eea8447bec7c936e903f644c85

TBB: add build option to save private keys

This patch adds a boolean build option 'SAVE_KEYS' to indicate the
certificate generation tool that it must save the private keys used
to establish the chain of trust. This option depends on 'CREATE_KEYS'
to be enabled. Default is '0' (do not save).

Because the same filenames are used as outputs to save the keys,
they are no longer a dependency to the cert_tool. This dependency
has been removed from the Makefile.

Documentation updated accordingly.

Change-Id: I67ab1c2b1f8a25793f0de95e8620ce7596a6bc3b

Merge pull request #325 from sandrine-bailleux/sb/fix-rw-data-relocation

Bug fix: Build time condition to relocate RW data

Bug fix: Build time condition to relocate RW data

This patch fixes the build time condition deciding whether the
read-write data should be relocated from ROM to RAM. It was incorrectly
using __DATA_ROM_START__, which is a linker symbol and not a compiler
build flag. As a result, the relocation code was always compiled out.

This bug has been introduced by the following patch:
"Rationalize reset handling code"

Change-Id: I1c8d49de32f791551ab4ac832bd45101d6934045

Merge pull request #321 from vwadekar/tegra-gic-implementation-v1

Add missing features to the Tegra GIC driver

Merge pull request #310 from sandrine-bailleux/sb/tf-issue-304-phase1

Enhance BL3-1 entrypoint handling to support non-TF boot firmware - Phase 1

PSCI: Add SYSTEM_SUSPEND API support

This patch adds support for SYSTEM_SUSPEND API as mentioned in the PSCI 1.0
specification. This API, on being invoked on the last running core on a
supported platform, will put the system into a low power mode with memory
retention.

The psci_afflvl_suspend() internal API has been reused as most of the actions
to suspend a system are the same as invoking the PSCI CPU_SUSPEND API with the
target affinity level as 'system'. This API needs the 'power state' parameter
for the target low power state. This parameter is not passed by the caller of
the SYSTEM_SUSPEND API. Hence, the platform needs to implement the
get_sys_suspend_power_state() platform function to provide this information.
Also, the platform also needs to add support for suspending the system to the
existing 'plat_pm_ops' functions: affinst_suspend() and
affinst_suspend_finish().

Change-Id: Ib6bf10809cb4e9b92f463755608889aedd83cef5

Add missing features to the Tegra GIC driver

In order to handle secure/non-secure interrupts, overload the plat_ic_*
functions and copy GIC helper functions from arm_gic.c. Use arm_gic.c
as the reference to add Tegra's GIC helper functions.

Now that Tegra has its own GIC implementation, we have no use for
plat_gic.c and arm_gic.c files.

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

Merge pull request #322 from athoelke/at/fix-bl1-assertions

Fix incorrect assertions in bl1_main()

Merge pull request #323 from athoelke/at/fix-aff-inst-overflow

Fix integer extension in mpidr_set_aff_inst()

Fix incorrect assertions in bl1_main()

The validation of the caching enable state in bl1_main() was
incorrect resulting in the state not being checked. Using the right
operator fixes this.

Change-Id: I2a99478f420281a1dcdf365d3d4fd8394cd21b51

Fix integer extension in mpidr_set_aff_inst()

mpidr_set_aff_inst() is left shifting an int constant and an
unsigned char value to construct an MPIDR. For affinity level 3 a
shift of 32 would result in shifting out of the 32-bit type and
have no effect on the MPIDR.

These values need to be extended to unsigned long before shifting
to ensure correct results for affinity level 3.

Change-Id: I1ef40afea535f14cfd820c347a065a228e8f4536

Merge pull request #320 from danh-arm/rh/timer-api-v10

Add delay timer API v10

FVP: Add SP804 delay timer

Add SP804 delay timer support to the FVP BSP.

This commit simply provides the 3 constants needed by the SP804
delay timer driver and calls sp804_timer_init() in
bl2_platform_setup(). The BSP does not currently use the delay
timer functions.

Note that the FVP SP804 is a normal world accessible peripheral
and should not be used by the secure world after transition
to the normal world.

Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39
Co-authored-by: Dan Handley <dan.handley@arm.com>

Add SP804 delay timer driver

Add a delay timer driver for the ARM SP804 dual timer.

This driver only uses the first timer, called timer 1 in the
SP804 Technical Reference Manual (ARM DDI 0271D).

To use this driver, the BSP must provide three constants:

*   The base address of the SP804 dual timer
*   The clock multiplier
*   The clock divider

The BSP is responsible for calling sp804_timer_init(). The SP804
driver instantiates a constant timer_ops_t and calls the generic
timer_init().

Change-Id: I49ba0a52bdf6072f403d1d0a20e305151d4bc086
Co-authored-by: Dan Handley <dan.handley@arm.com>

Merge pull request #319 from vwadekar/tegra-video-mem-aperture-v3

Reserve a Video Memory aperture in DRAM memory

Add a simple delay timer driver API

The API is simple. The BSP or specific timer driver creates an
instance of timer_ops_t, fills in the timer specific data, then calls
timer_init(). The timer specific data includes a function pointer
to return the timer value and a clock multiplier/divider. The ratio
of the multiplier and the divider is the clock frequency in MHz.

After that, mdelay() or udelay() can be called to delay execution for
the specified time (milliseconds or microseconds, respectively).

Change-Id: Icf8a295e1d25874f789bf28b7412156329dc975c
Co-authored-by: Dan Handley <dan.handley@arm.com>

Merge pull request #317 from vwadekar/run-bl32-on-tegra-v3

Run bl32 on tegra v3

Reserve a Video Memory aperture in DRAM memory

This patch adds support to reserve a memory carveout region in the
DRAM on Tegra SoCs. The memory controller provides specific registers
to specify the aperture's base and size. This aperture can also be
changed dynamically in order to re-size the memory available for
DRM video playback. In case of the new aperture not overlapping
the previous one, the previous aperture has to be cleared before
setting up the new one. This means we do not "leak" any video data
to the NS world.

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

Move dispatcher documents to the docs/spd folder

This patch moves the optee-dispatcher.md and tlk-dispatcher.md to
docs/spd.

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

Boot Trusted OS' on Tegra SoCs

This patch adds support to run a Trusted OS during boot time. The
previous stage bootloader passes the entry point information in
the 'bl32_ep_info' structure, which is passed over to the SPD.

The build system expects the dispatcher to be passed as an input
parameter using the 'SPD=<dispatcher>' option. The Tegra docs have
also been updated with this information.

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

Merge pull request #314 from sandrine-bailleux/sb/css-data-structs

Clarify some CSS data structures

Merge pull request #312 from jcastillo-arm/jc/tf-issues/308

Fix build option 'ARM_TSP_RAM_LOCATION' in user guide

CSS: Remove the constants MHU_SECURE_BASE/SIZE

For CSS based platforms, the constants MHU_SECURE_BASE and
MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes.
As such, they were misnamed because the mailboxes are completely
unrelated to the MHU hardware.

This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines.
The address of the Trusted Mailboxes is now relative to the base of
the Trusted SRAM.

This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE,
which is the address of the first memory region used for communication
between AP and SCP. This is used by the BOM and SCPI protocols.

Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f

CSS: Clarify what the SCP boot config is

Add a comment explaining what the SCP boot configuration information
is on CSS based platforms like Juno. Also express its address
relatively to the base of the Trusted SRAM rather than hard-coding it.

Change-Id: I82cf708a284c8b8212933074ea8c37bdf48b403b

Fix build option 'ARM_TSP_RAM_LOCATION' in user guide

The 'ARM_TSP_RAM_LOCATION_ID' option specified in the user guide
corresponds to the internal definition not visible to the final
user. The proper build option is 'ARM_TSP_RAM_LOCATION'. This
patch fixes it.

Fixes ARM-software/tf-issues#308

Change-Id: Ica8cb72c0c5e8b3503f60b5357d16698e869b1bd

Merge pull request #309 from soby-mathew/sm/fix_fvp_get_entry

FVP: Correct the PSYSR_WK bit width in platform_get_entrypoint

Introduce PROGRAMMABLE_RESET_ADDRESS build option

This patch introduces a new platform build option, called
PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
a programmable or fixed reset vector address.

If the reset vector address is fixed then the code relies on the
platform_get_entrypoint() mailbox mechanism to figure out where
it is supposed to jump. On the other hand, if it is programmable
then it is assumed that the platform code will program directly
the right address into the RVBAR register (instead of using the
mailbox redirection) so the mailbox is ignored in this case.

Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308

Rationalize reset handling code

The attempt to run the CPU reset code as soon as possible after reset
results in highly complex conditional code relating to the
RESET_TO_BL31 option.

This patch relaxes this requirement a little. In the BL1, BL3-1 and
PSCI entrypoints code, the sequence of operations is now as follows:
 1) Detect whether it is a cold or warm boot;
 2) For cold boot, detect whether it is the primary or a secondary
    CPU. This is needed to handle multiple CPUs entering cold reset
    simultaneously;
 3) Run the CPU init code.

This patch also abstracts the EL3 registers initialisation done by
the BL1, BL3-1 and PSCI entrypoints into common code.

This improves code re-use and consolidates the code flows for
different types of systems.

NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
OTHERWISE, SECONDARY CPUS WILL PANIC.

Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546

Remove FIRST_RESET_HANDLER_CALL build option

This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required between the first and subsequent invocations
of the reset handling code, this should be detected at runtime.

On Juno, the platform reset handler is now always compiled in.
This means it is now executed twice on the cold boot path, first in
BL1 then in BL3-1, and it has the same behavior in both cases. It is
also executed twice on the warm boot path, first in BL1 then in the
PSCI entrypoint code.

Also update the documentation to reflect this change.

NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.

Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2

FVP: Correct the PSYSR_WK bit width in platform_get_entrypoint

This patch fixes the incorrect bit width used to extract the wakeup
reason from PSYSR in platform_get_entrypoint() function. This defect
did not have any observed regression.

Change-Id: I42652dbffc99f5bf50cc86a5878f28d730720d9a

Merge pull request #305 from achingupta/ag/tf-issues#306

Ag/tf issues#306

Merge pull request #307 from soby-mathew/sm/css_bit_width_fix

CSS: Extract primary cpu id using the correct bit width

Merge pull request #308 from vwadekar/tegra-soc-support-v4

Tegra soc support v4

Always enable CCI coherency in BL3-1

On ARM standard platforms, snoop and DVM requests used to be enabled
for the primary CPU's cluster only in the first EL3 bootloader.
In other words, if the platform reset into BL1 then CCI coherency
would be enabled by BL1 only, and not by BL3-1 again.

However, this doesn't cater for platforms that use BL3-1 along with
a non-TF ROM bootloader that doesn't enable snoop and DVM requests.
In this case, CCI coherency is never enabled.

This patch modifies the function bl31_early_platform_setup() on
ARM standard platforms so that it always enables snoop and DVM
requests regardless of whether earlier bootloader stages have
already done it. There is no harm in executing this code twice.

ARM Trusted Firmware Design document updated accordingly.

Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c

Support for NVIDIA's Tegra T210 SoCs

T210 is the latest chip in the Tegra family of SoCs from NVIDIA. It is an
ARM v8 dual-cluster (A57/A53) SoC, with any one of the clusters being active
at a given point in time.

This patch adds support to boot the Trusted Firmware on T210 SoCs. The patch
also adds support to boot secondary CPUs, enter/exit core power states for
all CPUs in the slow/fast clusters. The support to switch between clusters
is still not available in this patch and would be available later.

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

Driver for 16550 UART interface

This patch adds driver for the 16550 UART interface. The driver is exposed
as a console, which platforms can use to dump their boot/crash logs.

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

CSS: Extract primary cpu id using the correct bit width

This patch fixes the incorrect bit width used to extract the primary
cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in
platform_is_primary_cpu().

Change-Id: I14abb361685f31164ecce0755fc1a145903b27aa

Merge pull request #303 from danh-arm/dh/fix-fvp-setup-topology

Fix return type of FVP plat_arm_topology_setup

Fix reporting of interrupt ID in ARM GIC driver

The ARM GIC driver treats the entire contents of the GICC_HPPIR as the interrupt
ID instead of just bits[9:0]. This could result in an SGI being treated as a
Group 1 interrupt on a GICv2 system.

This patch introduces a mask to retrieve only the ID from a read of GICC_HPPIR,
GICC_IAR and similar registers. The value read from these registers is masked
with this constant prior to use as an interrupt ID.

Fixes ARM-software/tf-issues#306

Change-Id: Ie3885157de33b71df9781a41f6ef015a30c4608d

Fix return type of FVP plat_arm_topology_setup

Fix the return type of the FVP `plat_arm_topology_setup` function
to be `void` instead of `int` to match the declaration in
`plat_arm.h`.

This does not result in any change in behavior.

Change-Id: I62edfa7652b83bd26cffb7d167153959b38e37e7

Merge pull request #301 from soby-mathew/sm/cpu_on_pend_state_fix

PSCI: Set ON_PENDING state early during CPU_ON

Fix handling of spurious interrupts in BL3_1

There are couple of issues with how the interrupt routing framework in BL3_1
handles spurious interrupts.

1. In the macro 'handle_interrupt_exception', if a spurious interrupt is
   detected by plat_ic_get_pending_interrupt_type(), then execution jumps to
   'interrupt_exit_\label'. This macro uses the el3_exit() function to return to
   the original exception level. el3_exit() attempts to restore the SPSR_EL3 and
   ELR_EL3 registers with values from the current CPU context. Since these
   registers were not saved in this code path, it programs stale values into
   these registers. This leads to unpredictable behaviour after the execution of
   the ERET instruction.

2. When an interrupt is routed to EL3, it could be de-asserted before the
   GICC_HPPIR is read in plat_ic_get_pending_interrupt_type(). There could be
   another interrupt pending at the same time e.g. a non-secure interrupt. Its
   type will be returned instead of the original interrupt. This would result in
   a call to get_interrupt_type_handler(). The firmware will panic if the
   handler for this type of interrupt has not been registered.

This patch fixes the first problem by saving SPSR_EL3 and ELR_EL3 early in the
'handle_interrupt_exception' macro, instead of only doing so once the validity
of the interrupt has been determined.

The second problem is fixed by returning execution back to the lower exception
level through the 'interrupt_exit_\label' label instead of treating it as an
error condition. The 'interrupt_error_\label' label has been removed since it is
no longer used.

Fixes ARM-software/tf-issues#305

Change-Id: I81c729a206d461084db501bb81b44dff435021e8

PSCI: Set ON_PENDING state early during CPU_ON

In the debug build of the function get_power_on_target_afflvl(), there is a
check to ensure that the CPU is emerging from a SUSPEND or ON_PENDING state.
The state is checked without acquiring the lock for the CPU node. The state
could be updated to ON_PENDING in psci_afflvl_on() after the target CPU has
been powered up. This results in a race condition which could cause the
check for the ON_PENDING state in get_power_on_target_afflvl() to fail.
This patch resolves this race condition by setting the state of the target
CPU to ON_PENDING before the platform port attempts to power it on. The
target CPU is thus guaranteed to read the correct the state. In case
the power on operation fails, the state of the CPU is restored to OFF.

Fixes ARM-software/tf-issues#302

Change-Id: I3f2306a78c58d47b1a0fb7e33ab04f917a2d5044

Merge pull request #297 from sandrine-bailleux/sb/move-up-deps

Move up dependency versions

Merge pull request #296 from danh-arm/sb/scpi-min-changes

Move to the new ARM SCP Messaging Interfaces v2

Merge pull request #295 from danh-arm/dh/plat-port-reorg

ARM platform port reorganization

FVP: update device tree idle state entries

Device tree idle state bindings changed in kernel v3.18. This patch
updates the FVP DT files to use PSCI suspend as idle state.

The patch also updates the 'compatible' property in the PSCI node
and the 'entry-method' property in the idle-states node in the FVP
Foundation GICv2-legacy device tree.

Change-Id: Ie921d497c579f425c03d482f9d7b90e166106e2f

Move up dependency versions in user guide

Move up the version numbers in the user guide of:

 * DS-5 (to v5.21)
 * EDK2 (to v3.0)
 * Linux Kernel (to 1.6-Juno)
 * Linaro file-system (to 15.03)
 * Juno SCP binary (to v1.7.0 within board recovery image 0.11.3).

Change-Id: Ieb09e633acc2b33823ddf35f77f44e7da60b99ba

Detect SCP version incompatibility

There has been a breaking change in the communication protocols used
between the AP cores and the SCP on CSS based platforms like Juno.
This means both the AP Trusted Firmware and SCP firmware must be
updated at the same time.

In case the user forgets to update the SCP ROM firmware, this patch
detects when it still uses the previous version of the communication
protocol. It will then output a comprehensive error message that helps
trouble-shoot the issue.

Change-Id: I7baf8f05ec0b7d8df25e0ee53df61fe7be0207c2

Move to the new ARM SCP Messaging Interfaces

The communication protocol used between the AP cores and the SCP
in CSS-based platforms like Juno has undergone a number of changes.
This patch makes the required modifications to the SCP Boot Protocol,
SCPI Protocol and MHU driver code in shared CSS platform code so that
the AP cores are still able to communicate with the SCP.

This patch focuses on the mandatory changes to make it work. The
design of this code needs to be improved but this will come in
a subsequent patch.

The main changes are:

 - MHU communication protocol

   - The command ID and payload size are no longer written into the
     MHU registers directly. Instead, they are stored in the payload
     area. The MHU registers are now used only as a doorbell to kick
     off messages. Same goes for any command result, the AP has to
     pick it up from the payload area.

 - SCP Boot Protocol

   - The BL3-0 image is now expected to embed a checksum. This
     checksum must be passed to the SCP, which uses it to check the
     integrity of the image it received.

   - The BL3-0 image used to be transferred a block (4KB)
     at a time. The SCP now supports receiving up to 128KB at a
     time, which is more than the size of the BL3-0 image.
     Therefore, the image is now sent in one go.

   - The command IDs have changed.

 - SCPI Protocol

   - The size of the SCPI payload has been reduced down from 512
     bytes to 256 bytes. This changes the base address of the
     AP-to-SCP payload area.

   - For commands that have a response, the response is the same SCPI
     header that was sent, except for the size and the status, which
     both must be updated appropriately. Success/Failure of a command
     is determined by looking at the updated status code.

   - Some command IDs have changed.

NOTE: THIS PATCH BREAKS COMPATIBILITY WITH FORMER VERSIONS OF THE SCP
FIRMWARE AND THUS REQUIRES AN UPDATE OF THIS BINARY. THE LATEST SCP
BINARY CAN BE OBTAINED FROM THE ARM CONNECTED COMMUNITY WEBSITE.

Change-Id: Ia5f6b95fe32401ee04a3805035748e8ef6718da7