Re-factor definition of TZC-400 base address

This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
support different TrustZone Controller base addresses across ARM platforms.

Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd

Merge pull request #383 from vikramkanigiri/vk/tf-issues-314-v1

Ensure BL2 security state is secure

Ensure BL2 security state is secure

BL2 loads secure runtime code(BL3-1, BL3-2) and hence it has to
run in secure world otherwise BL3-1/BL3-2 have to execute from
non-secure memory. Hence, This patch removes the change_security_state()
call in bl1_run_bl2() and replaces it with an assert to confirm
the BL2 as secure.

Fixes ARM-software/tf-issues#314

Change-Id: I611b83f5c4090e58a76a2e950b0d797b46df3c29

Merge pull request #382 from vikramkanigiri/vk/tf-issues-312

Configure all secure interrupts on ARM platforms

Merge pull request #381 from vikramkanigiri/hl/gic_v3

Remove EL2/EL1 GICv3 register updates

Configure all secure interrupts on ARM platforms

ARM TF configures all interrupts as non-secure except those which
are present in irq_sec_array. This patch updates the irq_sec_array
with the missing secure interrupts for ARM platforms.

It also updates the documentation to be inline with the latest
implementation.

Fixes ARM-software/tf-issues#312

Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc

Remove EL2/EL1 GICv3 register updates

From Linux 3.17 onwards, the mainline kernel has support for GICv3
systems and if EL3 exists, it only needs to initialise ICC_SRE_EL3.SRE
and ICC_SRE_EL3.Enable to 1. Hence, this patch removes the redundant
updates of ICC_SRE_EL2 and ICC_PMR_EL1.

NOTE: For partner software's which enter kernel in EL1,
ICC_SRE_EL2.Enable and ICC_SRE_EL2.SRE bit needs to be set to 1
in EL2 before jumping to linux.

Change-Id: I09ed47869351b08a3b034735f532bc677eaa6917

Merge pull request #375 from vwadekar/clear-videomem-region-v2

Tegra: fix logic to clear videomem regions

Tegra: fix logic to clear videomem regions

The previous logic in the memctrl driver was not catering to cases
where the new memory region lied inside the older region. This patch
fixes the if/elseif/elseif logic in the driver to take care of this
case.

Reported by: Vikram Kanigiri <vikram.kanigiri@arm.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

Merge pull request #371 from vwadekar/retention-entry-v3

Retention entry v3

Tegra210: wait for 512 timer ticks before retention entry

This patch programs the CPUECTLR_EL1 and L2ECTLR_EL1 registers,
so that the core waits for 512 generic timer CNTVALUEB ticks before
entering retention state, after executing a WFI instruction.

This functionality is configurable and can be enabled for platforms
by setting the newly defined 'ENABLE_L2_DYNAMIC_RETENTION' and
'ENABLE_CPU_DYNAMIC_RETENTION' flag.

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

Add macros for retention control in Cortex-A53/A57

This patch adds macros suitable for programming the Advanced
SIMD/Floating-point (only Cortex-A53), CPU and L2 dynamic
retention control policy in the CPUECTLR_EL1 and L2ECTLR
registers.

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

Merge pull request #368 from jcastillo-arm/jc/genfw/1126

TBB: abort boot if BL3-2 cannot be authenticated

Merge pull request #367 from soby-mathew/sm/mig_guide_fix

docs: Fixes to platform-migration-guide.md

TBB: abort boot if BL3-2 cannot be authenticated

BL3-2 image (Secure Payload) is optional. If the image cannot be
loaded a warning message is printed and the boot process continues.
According to the TBBR document, this behaviour should not apply in
case of an authentication error, where the boot process should be
aborted.

This patch modifies the load_auth_image() function to distinguish
between a load error and an authentication error. The caller uses
the return value to abort the boot process or continue.

In case of authentication error, the memory region used to store
the image is wiped clean.

Change-Id: I534391d526d514b2a85981c3dda00de67e0e7992

docs: Fixes to platform-migration-guide.md

This patch corrects some typos in the platform migration guide. More
importantly, the commit ID of the patch that implements migration of ARM
Reference platforms to the new platform API has been corrected.

Change-Id: Ib0109ea42c3d2bad2c6856ab725862652da7f3c8

Merge pull request #365 from mtk09422/plat_topology

mt8173: Fix cluster 0 core count

Merge pull request #364 from mtk09422/spm_suspend

mt8173: update spm wake_src setting

Merge pull request #362 from jcastillo-arm/jc/inline

Fix build error with optimizations disabled (-O0)

mt8173: Fix cluster 0 core count

Use constant macro defined in platform_def.h to replace hardcoded value.
This patch fix following assert in new psci-1.0 framework.

ASSERT: populate_power_domain_tree <183> : j == PLATFORM_CORE_COUNT

Change-Id: I9b7eda525479464a8c3805b6fe14ffb10debaf72
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>

mt8173: update spm wake_src setting

1. SEJ should not be one of the wake up sources

BUG=chrome-os-partner:38426
TEST=powerd_dbus_suspend

Change-Id: If8f3f19a885e66d7c10b472c2e3182a5affa4773
Signed-off-by: kenny liang <kenny.liang@mediatek.com>

Merge pull request #361 from achingupta/for_sm/psci_proto_v5

For sm/psci proto v5

PSCI: Rework generic code to conform to coding guidelines

This patch reworks the PSCI generic implementation to conform to ARM
Trusted Firmware coding guidelines as described here:
https://github.com/ARM-software/arm-trusted-firmware/wiki

This patch also reviews the use of signed data types within PSCI
Generic code and replaces them with their unsigned counterparts wherever
they are not appropriate. The PSCI_INVALID_DATA macro which was defined
to -1 is now replaced with PSCI_INVALID_PWR_LVL macro which is defined
to PLAT_MAX_PWR_LVL + 1.

Change-Id: Iaea422d0e46fc314e0b173c2b4c16e0d56b2515a

PSCI: Add documentation and fix plat_is_my_cpu_primary()

This patch adds the necessary documentation updates to porting_guide.md
for the changes in the platform interface mandated as a result of the new
PSCI Topology and power state management frameworks. It also adds a
new document `platform-migration-guide.md` to aid the migration of existing
platform ports to the new API.

The patch fixes the implementation and callers of
plat_is_my_cpu_primary() to use w0 as the return parameter as implied by
the function signature rather than x0 which was used previously.

Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b

PSCI: Validate non secure entrypoint on ARM platforms

This patch implements the platform power managment handler to verify
non secure entrypoint for ARM platforms. The handler ensures that the
entry point specified by the normal world during CPU_SUSPEND, CPU_ON
or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
DRAM.

Change-Id: I4795452df99f67a24682b22f0e0967175c1de429

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

Merge pull request #360 from vwadekar/tegra-platform-def-v2

Tegra: fix PLATFORM_{MAX_AFFLVL|CORE_COUNT|NUM_AFFS} macros

Merge pull request #357 from vwadekar/tegra-bl31-memmap-fix

Tegra: memmap the actual memory available for BL31

Tegra: fix PLATFORM_{CORE_COUNT|NUM_AFFS} macros

This patch fixes the following macros for Tegra SoCs.

* PLATFORM_CORE_COUNT: PLATFORM_CLUSTER_COUNT * PLATFORM_MAX_CPUS_PER_CLUSTER
* PLATFORM_NUM_AFFS: PLATFORM_CORE_COUNT + PLATFORM_CLUSTER_COUNT + 1

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

Merge pull request #356 from mtk09422/mt8173-support-v3

Mt8173 support v3

Tegra: memmap the actual memory available for BL31

On Tegra SoCs, the TZDRAM contains the BL31 and BL32 images. This patch
uses only the actual memory available for BL31 instead of mapping the
entire TZDRAM.

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

Initial platform port for MediaTek mt8173

- Boot up 4 cores.
- Add a generic UART driver.
- Add generic CPU helper functions
- Supoort suspend
- Add system_off & system_reset implementation
- Add crash console reporting implementation
- Add get_sys_suspend_power_state() for PSCI 1.0 SYSTEM_SUSPEND
- Add Mediatek SIP runtime service
- Add delay timer platform implementation

Change-Id: I44138249f115ee10b9cbd26fdbc2dd3af04d825f
Signed-off-by: CC Ma <cc.ma@mediatek.com>
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>

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

cortex_a53: Add A53 errata #826319, #836870

- Apply a53 errata #826319 to revision <= r0p2
- Apply a53 errata #836870 to revision <= r0p3
- Update docs/cpu-specific-build-macros.md for newly added errata build flags

Change-Id: I44918e36b47dca1fa29695b68700ff9bf888865e
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>

Add mmio utility functions

- Add mmio 16 bits read/write functions.
- Add clear/set/clear-and-set utility functions.

Change-Id: I00fdbdf24af537424f8666b1cadaa5f77a2a46ed
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>

Fix build error with optimizations disabled (-O0)

If Trusted Firmware is built with optimizations disabled (-O0), the
linker throws the following error:

    undefined reference to 'xxx'

Where 'xxx' is a raw inline function defined in a header file. The
reason is that, with optimizations disabled, GCC may decide to skip
the inlining. If that is the case, an external definition to the
compilation unit must be provided. Because no external definition
is present, the linker throws the error.

This patch fixes the problem by declaring the following inline
functions static, so the internal definition is used:

    inline void soc_css_security_setup(void)
    inline const arm_config_t *get_arm_config(void)

Change-Id: Id650d6be1b1396bdb48af1ac8a4c7900d212e95f

Merge pull request #351 from davwan01/davwan01/docs-update

Some minor fixes to interrupt-framework-design.md

Merge pull request #349 from jcastillo-arm/jc/tbb_cert_opt

TBB: rework cert_create tool to follow a data driven approach

Merge pull request #348 from vwadekar/bootargs-tzdram-base-v2

Bootargs tzdram base v2

Some minor fixes to interrupt-framework-design.md

This patch fixes a pair of typos. The security state had been described
as non-secure where it should have been secure.

Change-Id: Ib3f424708a6b8e2084e5447f8507ea4e9c99ee79

docs: fix the command to compile BL31 on Tegra

This patch fixes the command line used to compile BL31 on
Tegra platforms.

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

Tegra132: set TZDRAM_BASE to 0xF5C00000

The TZDRAM base on the reference platform has been bumped up due to
some BL2 memory cleanup. Platforms can also use a different TZDRAM
base by setting TZDRAM_BASE=<value> in the build command line.

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

Tegra: retrieve BL32's bootargs from bl32_ep_info

This patch removes the bootargs pointer from the platform params
structure. Instead the bootargs are passed by the BL2 in the
bl32_ep_info struct which is a part of the EL3 params struct.

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

Merge pull request #344 from vwadekar/tegra-mselect-restore-v2

Tegra210: enable WRAP to INCR burst type conversions

Tegra210: enable WRAP to INCR burst type conversions

The Memory Select Switch Controller routes any CPU transactions to
the appropriate slave depending on the transaction address. During
system suspend, it loses all config settings and hence the CPU has
to restore them during resume.

This patch restores the controller's settings for enabling WRAP to
INCR burst type conversions on the master ports, for any incoming
requests from the AXI slave ports.

Tested by performing multiple system suspend cycles.

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

Merge pull request #342 from vwadekar/tlkd-delete-need-bl32-v1

tlkd: delete 'NEED_BL32' build variable

tlkd: delete 'NEED_BL32' build variable

Remove the 'NEED_BL32' flag from the makefile. TLK compiles using a
completely different build system and is present on the device as a
binary blob. The NEED_BL32 flag does not influence the TLK load/boot
sequence at all. Moreover, it expects that TLK binary be present on
the host before we can compile BL31 support for Tegra.

This patch removes the flag from the makefile and thus decouples both
the build systems.

Tested by booting TLK without the NEED_BL32 flag.

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

Merge pull request #341 from vwadekar/tegra-denver-plat-support-v3

Tegra denver plat support v3

Tegra: modify 'BUILD_PLAT' to point to soc specific build dirs

This patch modifies the 'BUILD_PLAT' makefile variable to point to the soc
specific build directory in order to allow each Tegra soc to have its own
build directory. This way we can keep the build outputs separate and can
keep multiple soc specific builds alive at the same time.

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

Tegra: Support for Tegra's T132 platforms

This patch implements support for T132 (Denver CPU) based Tegra
platforms.

The following features have been added:

* SiP calls to switch T132 CPU's AARCH mode
* Complete PSCI support, including 'System Suspend'
* Platform specific MMIO settings
* Locking of CPU vector registers

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

Add "Project Denver" CPU support

Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is
fully ARMv8 architecture compatible.  Each of the two Denver cores
implements a 7-way superscalar microarchitecture (up to 7 concurrent
micro-ops can be executed per clock), and includes a 128KB 4-way L1
instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2
cache, which services both cores.

Denver implements an innovative process called Dynamic Code Optimization,
which optimizes frequently used software routines at runtime into dense,
highly tuned microcode-equivalent routines. These are stored in a
dedicated, 128MB main-memory-based optimization cache. After being read
into the instruction cache, the optimized micro-ops are executed,
re-fetched and executed from the instruction cache as long as needed and
capacity allows.

Effectively, this reduces the need to re-optimize the software routines.
Instead of using hardware to extract the instruction-level parallelism
(ILP) inherent in the code, Denver extracts the ILP once via software
techniques, and then executes those routines repeatedly, thus amortizing
the cost of ILP extraction over the many execution instances.

Denver also features new low latency power-state transitions, in addition
to extensive power-gating and dynamic voltage and clock scaling based on
workloads.

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

Tegra: implement per-SoC validate_power_state() handler

The validate_power_state() handler checks the power_state for a valid afflvl
and state id. Although the afflvl check is common, the state ids are implementation
defined.

This patch moves the handler to the tegra/soc folder to allow each SoC to validate
the power_state for supported parameters.

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

Tegra: T210: include CPU files from SoC's platform.mk

This patch moves the inclusion of CPU code (A53, A57) to T210's
makefile. This way we can reduce code size for Tegra platforms by
including only the required CPU files.

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

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

TBB: rework cert_create tool to follow a data driven approach

This patch reworks the certificate generation tool to follow a data
driven approach. The user may specify at build time the certificates,
keys and extensions defined in the CoT, register them using the
appropiate macros and the tool will take care of creating the
certificates corresponding to the CoT specified.

Change-Id: I29950b39343c3e1b71718fce0e77dcf2a9a0be2f

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