FWU: Pass client cookie to FWU_SMC_UPDATE_DONE ...

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

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

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

Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2

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

Enable BL31 to configure a runtime console

FWU: Add Generic Firmware Update framework support in BL1 ...

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

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

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

Following platform porting functions are introduced:

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

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

plat_bl1_common.c contains weak definitions for above functions.

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

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

Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed

Add descriptor based image management support in BL1 ...

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

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

This patch introduces following platform porting functions:

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

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

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

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

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

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

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

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

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

Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881

Ensure BL31 does not print to boot console by default ...

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

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

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

Fixes ARM-software/tf-issues#328

Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a

Prepare platforms to use refactored ARM GIC drivers ...

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

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

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

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

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

Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6

Pass the entry point info to bl1_plat_prepare_exit() ...

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

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

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

Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb

Add optional platform error handler API ...

This patch adds an optional API to the platform port:

    void plat_error_handler(int err) __dead2;

The platform error handler is called when there is a specific error
condition after which Trusted Firmware cannot continue. While panic()
simply prints the crash report (if enabled) and spins, the platform
error handler can be used to hand control over to the platform port
so it can perform specific bookeeping or post-error actions (for
example, reset the system). This function must not return.

The parameter indicates the type of error using standard codes from
errno.h. Possible errors reported by the generic code are:

    -EAUTH  : a certificate or image could not be authenticated
              (when Trusted Board Boot is enabled)
    -ENOENT : the requested image or certificate could not be found
              or an IO error was detected
    -ENOMEM : resources exhausted. Trusted Firmware does not use
              dynamic memory, so this error is usually an indication
              of an incorrect array size

A default weak implementation of this function has been provided.
It simply implements an infinite loop.

Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3

Add optional bl1_plat_prepare_exit() API ...

This patch adds an optional API to the platform port:

    void bl1_plat_prepare_exit(void);

This function is called prior to exiting BL1 in response to the
RUN_IMAGE_SMC request raised by BL2. It should be used to perform
platform specific clean up or bookkeeping operations before
transferring control to the next image.

A weak empty definition of this function has been provided to
preserve platform backwards compatibility.

Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1

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: 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 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

Add support to indicate size and end of assembly functions ...

In order for the symbol table in the ELF file to contain the size of
functions written in assembly, it is necessary to report it to the
assembler using the .size directive.

To fulfil the above requirements, this patch introduces an 'endfunc'
macro which contains the .endfunc and .size directives. It also adds
a .func directive to the 'func' assembler macro.

The .func/.endfunc have been used so the assembler can fail if
endfunc is omitted.

Fixes ARM-Software/tf-issues#295

Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
Signed-off-by: Kévin Petit <kevin.petit@arm.com>

Add CPU specific power management operations ...

This patch adds CPU core and cluster power down sequences to the CPU specific
operations framework introduced in a earlier patch. Cortex-A53, Cortex-A57 and
generic AEM sequences have been added. The latter is suitable for the
Foundation and Base AEM FVPs. A pointer to each CPU's operations structure is
saved in the per-cpu data so that it can be easily accessed during power down
seqeunces.

An optional platform API has been introduced to allow a platform to disable the
Accelerator Coherency Port (ACP) during a cluster power down sequence. The weak
definition of this function (plat_disable_acp()) does not take any action. It
should be overriden with a strong definition if the ACP is present on a
platform.

Change-Id: I8d09bd40d2f528a28d2d3f19b77101178778685d

Add platform API for reset handling ...

This patch adds an optional platform API (plat_reset_handler) which allows the
platform to perform any actions immediately after a cold or warm reset
e.g. implement errata workarounds. The function is called with MMU and caches
turned off. This API is weakly defined and does nothing by default but can be
overriden by a platform with a strong definition.

Change-Id: Ib0acdccbd24bc756528a8bd647df21e8d59707ff

Call platform_is_primary_cpu() only from reset handler ...

The purpose of platform_is_primary_cpu() is to determine after reset
(BL1 or BL3-1 with reset handler) if the current CPU must follow the
cold boot path (primary CPU), or wait in a safe state (secondary CPU)
until the primary CPU has finished the system initialization.

This patch removes redundant calls to platform_is_primary_cpu() in
subsequent bootloader entrypoints since the reset handler already
guarantees that code is executed exclusively on the primary CPU.

Additionally, this patch removes the weak definition of
platform_is_primary_cpu(), so the implementation of this function
becomes mandatory. Removing the weak symbol avoids other
bootloaders accidentally picking up an invalid definition in case the
porting layer makes the real function available only to BL1.

The define PRIMARY_CPU is no longer mandatory in the platform porting
because platform_is_primary_cpu() hides the implementation details
(for instance, there may be platforms that report the primary CPU in
a system register). The primary CPU definition in FVP has been moved
to fvp_def.h.

The porting guide has been updated accordingly.

Fixes ARM-software/tf-issues#219

Change-Id: If675a1de8e8d25122b7fef147cb238d939f90b5e

Merge pull request #172 from soby-mathew/sm/asm_assert ...

Introduce asm assert and optimize crash reporting

Introduce crash console APIs for crash reporting ...

This patch introduces platform APIs to initialise and
print a character on a designated crash console.
For the FVP platform, PL011_UART0 is the designated
crash console. The platform porting guide is also updated
to document the new APIs.

Change-Id: I5e97d8762082e0c88c8c9bbb479353eac8f11a66

Remove the concept of coherent stacks ...

This patch removes the allocation of memory for coherent stacks, associated
accessor function and some dead code which called the accessor function. It also
updates the porting guide to remove the concept and the motivation behind using
stacks allocated in coherent memory.

Fixes ARM-software/tf-issues#198

Change-Id: I00ff9a04f693a03df3627ba39727e3497263fc38

Make enablement of the MMU more flexible ...

This patch adds a 'flags' parameter to each exception level specific function
responsible for enabling the MMU. At present only a single flag which indicates
whether the data cache should also be enabled is implemented. Subsequent patches
will use this flag when enabling the MMU in the warm boot paths.

Change-Id: I0eafae1e678c9ecc604e680851093f1680e9cefa

Refactor fvp gic code to be a generic driver ...

Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM
GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform
specific inputs in the arm_gic_setup() function so that the driver
has no explicit dependency on platform code.

Provide weak implementations of the platform interrupt controller
API in a new file, plat/common/plat_gic.c. These simply call through
to the ARM GIC driver.

Move the only remaining FVP GIC function, fvp_gic_init() to
plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c

Fixes ARM-software/tf-issues#182

Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21

Remove all checkpatch errors from codebase ...

Exclude stdlib files because they do not follow kernel code style.

Fixes ARM-software/tf-issues#73

Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab

Add enable mmu platform porting interfaces ...

Previously, the enable_mmu_elX() functions were implicitly part of
the platform porting layer since they were included by generic
code. These functions have been placed behind 2 new platform
functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu().
These are weakly defined so that they can be optionally overridden
by platform ports.

Also, the enable_mmu_elX() functions have been moved to
lib/aarch64/xlat_tables.c for optional re-use by platform ports.
These functions are tightly coupled with the translation table
initialization code.

Fixes ARM-software/tf-issues#152

Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c

Split platform.h into separate headers ...

Previously, platform.h contained many declarations and definitions
used for different purposes. This file has been split so that:

* Platform definitions used by common code that must be defined
  by the platform are now in platform_def.h. The exact include
  path is exported through $PLAT_INCLUDES in the platform makefile.

* Platform definitions specific to the FVP platform are now in
  /plat/fvp/fvp_def.h.

* Platform API declarations specific to the FVP platform are now
  in /plat/fvp/fvp_private.h.

* The remaining platform API declarations that must be ported by
  each platform are still in platform.h but this file has been
  moved to /include/plat/common since this can be shared by all
  platforms.

Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a

Reduce deep nesting of header files ...

Reduce the number of header files included from other header
files as much as possible without splitting the files. Use forward
declarations where possible. This allows removal of some unnecessary
"#ifndef __ASSEMBLY__" statements.

Also, review the .c and .S files for which header files really need
including and reorder the #include statements alphabetically.

Fixes ARM-software/tf-issues#31

Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e

Allocate single stacks for BL1 and BL2 ...

The BL images share common stack management code which provides
one coherent and one cacheable stack for every CPU. BL1 and BL2
just execute on the primary CPU during boot and do not require
the additional CPU stacks. This patch provides separate stack
support code for UP and MP images, substantially reducing the
RAM usage for BL1 and BL2 for the FVP platform.

This patch also provides macros for declaring stacks and
calculating stack base addresses to improve consistency where
this has to be done in the firmware.

The stack allocation source files are now included via
platform.mk rather than the common BLx makefiles. This allows
each platform to select the appropriate MP/UP stack support
for each BL image.

Each platform makefile must be updated when including this
commit.

Fixes ARM-software/tf-issues#76

Change-Id: Ia251f61b8148ffa73eae3f3711f57b1ffebfa632

Place assembler functions in separate sections ...

This extends the --gc-sections behaviour to the many assembler
support functions in the firmware images by placing each function
into its own code section. This is achieved by creating a 'func'
macro used to declare each function label.

Fixes ARM-software/tf-issues#80

Change-Id: I301937b630add292d2dec6d2561a7fcfa6fec690

Increase coherent stack sizes ...

This patch increases coherent stack size for both debug and release
builds in order to accommodate stack-heavy printf() and extended EL3
functionality

Change-Id: I30ef30530a01517a97e63d703873374828c09f20