GitLab

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

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

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

Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a

This patch introduces a new function called 'print_entry_point_info'
that prints an entry_point_t structure for debugging purposes.
As such, it can be used to display the entry point address, SPSR and
arguments passed from a firmware image to the next one.

This function is now called in the following images transitions:
 - BL1 to BL2
 - BL1 to BL31
 - BL31 to the next image (typically BL32 or BL33)

The following changes have been introduced:

 - Fix the output format of the SPSR value : SPSR is a 32-bit value,
   not a 64-bit one.

 - Print all arguments values.
   The entry_point_info_t structure allows to pass up to 8 arguments.
   In most cases, only the first 2 arguments were printed.
   print_entry_point_info() now prints all of them as 'VERBOSE'
   traces.

Change-Id: Ieb384bffaa7849e6cb95a01a47c0b7fc2308653a

This patch replaces custom definitions used as return values for
the load_auth_image() function with standard error codes defined
in errno.h. The custom definitions have been removed.

It also replaces the usage of IO framework error custom definitions,
which have been deprecated. Standard errno definitions are used
instead.

Change-Id: I1228477346d3876151c05b470d9669c37fd231be

On the ARMv8 architecture, cache maintenance operations by set/way on the last
level of integrated cache do not affect the system cache. This means that such a
flush or clean operation could result in the data being pushed out to the system
cache rather than main memory. Another CPU could access this data before it
enables its data cache or MMU. Such accesses could be serviced from the main
memory instead of the system cache. If the data in the sysem cache has not yet
been flushed or evicted to main memory then there could be a loss of
coherency. The only mechanism to guarantee that the main memory will be updated
is to use cache maintenance operations to the PoC by MVA(See section D3.4.11
(System level caches) of ARMv8-A Reference Manual (Issue A.g/ARM DDI0487A.G).

This patch removes the reliance of Trusted Firmware on the flush by set/way
operation to ensure visibility of data in the main memory. Cache maintenance
operations by MVA are now used instead. The following are the broad category of
changes:

1. The RW areas of BL2/BL31/BL32 are invalidated by MVA before the C runtime is
   initialised. This ensures that any stale cache lines at any level of cache
   are removed.

2. Updates to global data in runtime firmware (BL31) by the primary CPU are made
   visible to secondary CPUs using a cache clean operation by MVA.

3. Cache maintenance by set/way operations are only used prior to power down.

NOTE: NON-UPSTREAM TRUSTED FIRMWARE CODE SHOULD MAKE EQUIVALENT CHANGES IN
ORDER TO FUNCTION CORRECTLY ON PLATFORMS WITH SUPPORT FOR SYSTEM CACHES.

Fixes ARM-software/tf-issues#205

Change-Id: I64f1b398de0432813a0e0881d70f8337681f6e9a

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

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

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

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

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

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

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

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

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

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

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

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

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

Add extern declarations of linker symbols to bl_common.h. These are
used by platform ports to determine the memory layout of BL images.
Adding the declarations to this file facilitates removal of these
declarations from the platform porting source files in subsequent
patches.

Also remove the linker symbol declarations from common TSP source
code.

Change-Id: I8ed0426bc815317c4536b588e4e78bc15b4fe91c

Some assembly files containing macros are included like header files
into other assembly files. This will cause assembler errors if they
are included multiple times.

Add header guards to assembly macro files to avoid assembler errors.

Change-Id: Ia632e767ed7df7bf507b294982b8d730a6f8fe69

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>

This patch defines the ARRAY_SIZE macro for calculating number of elements
in an array and uses it where appropriate.

Change-Id: I72746a9229f0b259323972b498b9a3999731bc9b

This patch modifies the declarations of the functions printf() et al.
and adds the right GCC attribute to request the compiler to check
the type of the arguments passed to these functions against the given
format string. This will ensure that the compiler outputs warning
messages like the following whenever it detects an inconsistency:

 file.c:42: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’

It also fixes the type mismatch inconsistencies that it revealed
across the code base.

NOTE: THIS PATCH MAY FORCE PLATFORM PORTS OR SP/SPDS THAT USE THE
PRINTF FAMILY OF FUNCTIONS TO FIX ANY TYPE MISMATCH INCONSISTENCIES.

Change-Id: If36bb54ec7d6dd2cb4791d89b02a24ac13fd2df6

This patch provides an API to access the authentication module that
will be used to verify the authenticity of the images loaded into
memory as part of the Trusted Board Boot process.

To include the authentication module as part of the build, set the
boolean build option TRUSTED_BOARD_BOOT. One single authentication
module must be registered at build time by setting the build option
AUTH_MOD=<mod_name>. All authentication modules will be located in
'common/auth/<mod_name>' and must present the <mod_name>.mk file that
will be included by the build system to compile the module sources.

To create an authentication module, an instance of auth_mod_t called
'auth_mod' must be declared in the module sources. The initialization
and verification functions provided by the module will be exported
through the function pointers specified when declaring this instance.

If an authentication module includes third party sources that do not
adhere to the C99 standard, the -pedantic option may be removed from
the build options by setting the flag DISABLE_PEDANTIC in the module
file <mod_name>.mk.

Change-Id: I080bb04bd421029bcdf22ec2c63807afbf061dcd

This patch extends the FIP tool to include the certificates
generated by the 'cert_create' tool.

If GENERATE_COT build option is enabled, the Makefile adds the
certificates as dependencies to create the FIP file. Thus, make
target 'fip' will also build the certificates as part of the
Trusted Firmware build process.

Change-Id: I5eee500da7f7be6cfb6e3df0423599739d260074

This patch adds support to call the reset_handler() function in BL3-1 in the
cold and warm boot paths when another Boot ROM reset_handler() has already run.

This means the BL1 and BL3-1 versions of the CPU and platform specific reset
handlers may execute different code to each other. This enables a developer to
perform additional actions or undo actions already performed during the first
call of the reset handlers e.g. apply additional errata workarounds.

Typically, the reset handler will be first called from the BL1 Boot ROM. Any
additional functionality can be added to the reset handler when it is called
from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used
to identify whether this is the first version of the reset handler code to be
executed or an overridden version of the code.

The Cortex-A57 errata workarounds are applied only if they have not already been
applied.

Fixes ARM-software/tf-issue#275

Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053

This patch provides a workaround for the ASM_ASSERT label issue
and also reworks the use of labels in assembly macros.
If the caller of the ASM_ASSERT macro happened to use the
label '1' to jump past the ASM_ASSERT macro, it would not have
worked since the ASM_ASSERT macro internally used the same label.
Hence, as a workaround, this patch makes the label a high
number in the expectation that the caller will never use it.

Also updated the other assembly macros using numerical labels to
named lables.

Change-Id: Iec892359db84f2391ad2a83a92141c4d7049776a

Create new LOG_LEVEL build option, which controls the amount of
console output compiled into the build. This should be one of the
following:

    0  (LOG_LEVEL_NONE)
    10 (LOG_LEVEL_NOTICE)
    20 (LOG_LEVEL_ERROR)
    30 (LOG_LEVEL_WARNING)
    40 (LOG_LEVEL_INFO)
    50 (LOG_LEVEL_VERBOSE)

All log output up to and including the log level is compiled into the
build. The default value is 40 in debug builds and 20 in release
builds.

Complement the existing INFO, WARN and ERROR console output macros
with NOTICE and VERBOSE macros, which are conditionally compiled in
depending on the value of LOG_LEVEL.

Fixes ARM-software/tf-issues#232

Change-Id: I951e2f333e7b90fc4b1060741d9a6db699d5aa72

Assert a valid security state using the macro sec_state_is_valid().
Replace assert() with panic() in those cases that might arise
because of runtime errors and not programming errors.
Replace panic() with assert() in those cases that might arise
because of programming errors.

Fixes ARM-software/tf-issues#96

Change-Id: I51e9ef0439fd5ff5e0edfef49050b69804bf14d5

This patch reworks the crash reporting mechanism to further
optimise the stack and code size. The reporting makes use
of assembly console functions to avoid calling C Runtime
to report the CPU state. The crash buffer requirement is
reduced to 64 bytes with this implementation. The crash
buffer is now part of per-cpu data which makes retrieving
the crash buffer trivial.

Also now panic() will use crash reporting if
invoked from BL3-1.

Fixes ARM-software/tf-issues#199

Change-Id: I79d27a4524583d723483165dc40801f45e627da5

The patch implements a macro ASM_ASSERT() which can
be invoked from assembly code. When assertion happens,
file name and line number of the check is written
to the crash console.

Fixes ARM-software/tf-issues#95

Change-Id: I6f905a068e1c0fa4f746d723f18df60daaa00a86

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

Print out Trusted Firmware version at runtime at each BL stage.
Message consists of TF version as defined statically in the Makefile
(e.g. v0.4), build mode (debug|release) and a customizable build
string:

  1. By defining BUILD_STRING in command line when building TF
  2. Default string is git commit ID
  3. Empty if git meta-data is not available

Fixes ARM-software/tf-issues#203

Change-Id: I5c5ba438f66ab68810427d76b49c5b9177a957d6

This patch implements a "tf_printf" which supports only the commonly
used format specifiers in Trusted Firmware, which uses a lot less
stack space than the stdlib printf function.

Fixes ARM-software/tf-issues#116

Change-Id: I7dfa1944f4c1e634b3e2d571f49afe02d109a351

This concept is no longer required since we now support loading of
images at fixed addresses only.

The image loader now automatically detects the position of the image
inside the current memory layout and updates the layout such that
memory fragmentation is minimised.

The 'attr' field of the meminfo data structure, which used to hold
the bottom/top loading information, has been removed. Also the 'next'
field has been removed as it wasn't used anywhere.

The 'init_bl2_mem_layout()' function has been moved out of common
code and put in BL1-specific code. It has also been renamed into
'bl1_init_bl2_mem_layout'.

Fixes ARM-software/tf-issues#109

Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d

Consolidate all BL3-1 CPU context initialization for cold boot, PSCI
and SPDs into two functions:
*  The first uses entry_point_info to initialize the relevant
   cpu_context for first entry into a lower exception level on a CPU
*  The second populates the EL1 and EL2 system registers as needed
   from the cpu_context to ensure correct entry into the lower EL

This patch alters the way that BL3-1 determines which exception level
is used when first entering EL1 or EL2 during cold boot - this is now
fully determined by the SPSR value in the entry_point_info for BL3-3,
as set up by the platform code in BL2 (or otherwise provided to BL3-1).

In the situation that EL1 (or svc mode) is selected for a processor
that supports EL2, the context management code will now configure all
essential EL2 register state to ensure correct execution of EL1. This
allows the platform code to run non-secure EL1 payloads directly
without requiring a small EL2 stub or OS loader.

Change-Id: If9fbb2417e82d2226e47568203d5a369f39d3b0f

Some platform porting functions were in BL specific header files.
These have been moved to platform.h so that all porting functions
are in the same place. The functions are now grouped by BL.
Obsolete BL headers files have been removed.

Also, the weak declaration of the init_bl2_mem_layout() function
has been moved out the header file and into the source file
(bl_common.c) using the more succinct #pragma syntax. This
mitigates the risk of 2 weak definitions being created and the
wrong one being picked up by the compiler.

Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83

Function declarations implicitly have external linkage so do not
need the extern keyword.

Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32

This change adds optional reset vector support to BL3-1
which means BL3-1 entry point can detect cold/warm boot,
initialise primary cpu, set up cci and mail box.

When using BL3-1 as a reset vector it is assumed that
the BL3-1 platform code can determine the location of
the BL3-2 images, or load them as there are no parameters
that can be passed to BL3-1 at reset.

It also fixes the incorrect initialisation of mailbox
registers on the FVP platform

This feature can be enabled by building the code with
make variable RESET_TO_BL31 set as 1

Fixes ARM-software/TF-issues#133
Fixes ARM-software/TF-issues#20

Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570

The issues addressed in this patch are:

1. Remove meminfo_t from the common interfaces in BL3-x,
expecting that platform code will find a suitable mechanism
to determine the memory extents in these images and provide
it to the BL3-x images.

2. Remove meminfo_t and bl31_plat_params_t from all FVP BL3-x
code as the images use link-time information to determine
memory extents.

meminfo_t is still used by common interface in BL1/BL2 for
loading images

Change-Id: I4e825ebf6f515b59d84dc2bdddf6edbf15e2d60f

This patch is based on spec published at
https://github.com/ARM-software/tf-issues/issues/133

It rearranges the bl31_args struct into
bl31_params and bl31_plat_params which provide the
information needed for Trusted firmware and platform
specific data via x0 and x1

On the FVP platform BL3-1 params and BL3-1 plat params
and its constituents are stored at the start of TZDRAM.

The information about memory availability and size for
BL3-1, BL3-2 and BL3-3 is moved into platform specific data.

Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9