Merge commit 'for-v0.4/05.20^' into for-v0.4 ...

Conflicts:
	plat/fvp/bl32_plat_setup.c
	plat/fvp/platform.mk
	services/spd/tspd/tspd_main.c

Change-Id: Ib4bad39a8a476a6b1796298f95dfb97c8b100975

Merge pull request #90 from jcastillo-arm:jc/tf-issues/149 ...

Conflicts:
	plat/fvp/bl2_plat_setup.c
	plat/fvp/platform.h

Change-Id: I5bcc5180a2b4f944d07969b2e17e0f92cca72c89

fvp: Move TSP from Secure DRAM to Secure SRAM ...

The TSP used to execute from secure DRAM on the FVPs because there was
not enough space in Trusted SRAM to fit it in. Thanks to recent RAM
usage enhancements being implemented, we have made enough savings for
the TSP to execute in SRAM.

However, there is no contiguous free chunk of SRAM big enough to hold
the TSP. Therefore, the different bootloader images need to be moved
around to reduce memory fragmentation. This patch keeps the overall
memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and
BL3-1 in between) but moves the base addresses of all the bootloader
images in such a way that:
 - memory fragmentation is reduced enough to fit BL3-2 in;
 - new base addresses are suitable for release builds as well as debug
   ones;
 - each image has a few extra kilobytes for future growth.
   BL3-1 and BL3-2 are the images which received the biggest slice
   of the cake since they will most probably grow the most.

A few useful numbers for reference (valid at the time of this patch):
        |-----------------------|-------------------------------
        |  image size (debug)   |  extra space for the future
--------|-----------------------|-------------------------------
BL1 R/W |         20 KB         |            4 KB
BL2     |         44 KB         |            4 KB
BL3-1   |        108 KB         |           12 KB
BL3-2   |         56 KB         |            8 KB
--------|-----------------------|-------------------------------
Total   |        228 KB         |           28 KB       = 256 KB
--------|-----------------------|-------------------------------

Although on FVPs the TSP now executes from Trusted SRAM by default,
this patch keeps the option to execute it from Trusted DRAM. This is
controlled by the build configuration 'TSP_RAM_LOCATION'.

Fixes ARM-Software/tf-issues#81

Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94

TSP: Let the platform decide which secure memory to use ...

The TSP's linker script used to assume that the TSP would
execute from secure DRAM. Although it is currently the case
on FVPs, platforms are free to use any secure memory they wish.

This patch introduces the flexibility to load the TSP into any
secure memory. The platform code gets to specify the extents of
this memory in the platform header file, as well as the BL3-2 image
limit address. The latter definition allows to check in a generic way
that the BL3-2 image fits in its bounds.

Change-Id: I9450f2d8b32d74bd00b6ce57a0a1542716ab449c

fixup! 4749bdc ...

Modify the BL3-1 read/write memory extent to cover all of the SRAM

Change-Id: I1143feaff0313f7d0b88948997b81d6f3aeddc29

Add support for BL3-1 as a reset vector ...

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

Rework memory information passing to BL3-x images ...

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

Populate BL31 input parameters as per new spec ...

This patch 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

Rework handover interface between BL stages ...

This patch reworks the handover interface from: BL1 to BL2 and
BL2 to BL3-1. It removes the raise_el(), change_el() and
run_image() functions as they catered for code paths that were
never exercised. BL1 calls drop_el() to jump into BL2 instead of
doing the same by calling run_image(). Similarly, BL2 issues the
SMC to transfer execution to BL3-1 through BL1 directly. Only x0
and x1 are used to pass arguments to BL31. These arguments and
parameters for running BL3-1 are passed through a reference to a
'el_change_info_t' structure. They were being passed value in
general purpose registers earlier.

Change-Id: Id4fd019a19a9595de063766d4a66295a2c9307e1

Reserve some DDR DRAM for secure use on FVP platforms ...

TZC-400 is configured to set the last 16MB of DRAM1 as secure memory and
the rest of DRAM as non-secure. Non-secure software must not attempt to
access the 16MB secure area.

Device tree files (sources and binaries) have been updated to match this
configuration, removing that memory from the Linux physical memory map.
UEFI earliest commit matching this change updated in documentation.

Replaced magic numbers with #define for memory region definition in the
platform security initialization function.

Fixes ARM-software/tf-issues#149

Change-Id: Ia5d070244aae6c5288ea0e6c8e89d92859522bfe

Add support for synchronous FIQ handling in TSP ...

This patch adds support in the TSP for handling S-EL1 interrupts
handed over by the TSPD. It includes GIC support in its platform port,
updates various statistics related to FIQ handling, exports an entry
point that the TSPD can use to hand over interrupts and defines the
handover protocol w.r.t what context is the TSP expected to preserve
and the state in which the entry point is invoked by the TSPD.

Change-Id: I93b22e5a8133400e4da366f5fc862f871038df39

Introduce platform api to access an ARM GIC ...

This patch introduces a set of functions which allow generic firmware
code e.g. the interrupt management framework to access the platform
interrupt controller. APIs for finding the type and id of the highest
pending interrupt, acknowledging and EOIing an interrupt and finding
the security state of an interrupt have been added. It is assumed that
the platform interrupt controller implements the v2.0 of the ARM GIC
architecture specification. Support for v3.0 of the specification for
managing interrupts in EL3 and the platform port will be added in the
future.

Change-Id: Ib3a01c2cf3e3ab27806930f1be79db2b29f91bcf

Introduce interrupt registration framework in BL3-1 ...

This patch introduces a framework for registering interrupts routed to
EL3. The interrupt routing model is governed by the SCR_EL3.IRQ and
FIQ bits and the security state an interrupt is generated in. The
framework recognizes three type of interrupts depending upon which
exception level and security state they should be handled in
i.e. Secure EL1 interrupts, Non-secure interrupts and EL3
interrupts. It provides an API and macros that allow a runtime service
to register an handler for a type of interrupt and specify the routing
model. The framework validates the routing model and uses the context
management framework to ensure that it is applied to the SCR_EL3 prior
to entry into the target security state. It saves the handler in
internal data structures. An API is provided to retrieve the handler
when an interrupt of a particular type is asserted. Registration is
expected to be done once by the primary CPU. The same handler and
routing model is used for all CPUs.

Support for EL3 interrupts will be added to the framework in the
future. A makefile flag has been added to allow the FVP port choose
between ARM GIC v2 and v3 support in EL3. The latter version is
currently unsupported.

A framework for handling interrupts in BL3-1 will be introduced in
subsequent patches. The default routing model in the absence of any
handlers expects no interrupts to be routed to EL3.

Change-Id: Idf7c023b34fcd4800a5980f2bef85e4b5c29e649

Rework BL3-1 unhandled exception handling and reporting ...

This patch implements the register reporting when unhandled exceptions are
taken in BL3-1. Unhandled exceptions will result in a dump of registers
to the console, before halting execution by that CPU. The Crash Stack,
previously called the Exception Stack, is used for this activity.
This stack is used to preserve the CPU context and runtime stack
contents for debugging and analysis.

This also introduces the per_cpu_ptr_cache, referenced by tpidr_el3,
to provide easy access to some of BL3-1 per-cpu data structures.
Initially, this is used to provide a pointer to the Crash stack.

panic() now prints the the error file and line number in Debug mode
and prints the PC value in release mode.

The Exception Stack is renamed to Crash Stack with this patch.
The original intention of exception stack is no longer valid
since we intend to support several valid exceptions like IRQ
and FIQ in the trusted firmware context. This stack is now
utilized for dumping and reporting the system state when a
crash happens and hence the rename.

Fixes ARM-software/tf-issues#79 Improve reporting of unhandled exception

Change-Id: I260791dc05536b78547412d147193cdccae7811a

Merge pull request #69 from sandrine-bailleux:sb/split-mmu-fcts-per-el

Fixes for TZC configuration on FVP ...

The TZC configuration on FVP was incorrectly allowing both secure
and non-secure accesses to the DRAM, which can cause aliasing
problems for software. It was also not enabling virtio access on
some models.

This patch fixes both of those issues. The patch also enabless
non-secure access to the DDR RAM for all devices with defined IDs.

The third region of DDR RAM has been removed from the configuration
as this is not used in any of the FVP models.

Fixes ARM-software/tf-issues#150
Fixes ARM-software/tf-issues#151

Change-Id: I60ad5daaf55e14f178affb8afd95d17e7537abd7

fvp: Provide per-EL MMU setup functions ...

Instead of having a single version of the MMU setup functions for all
bootloader images that can execute either in EL3 or in EL1, provide
separate functions for EL1 and EL3. Each bootloader image can then
call the appropriate version of these functions. The aim is to reduce
the amount of code compiled in each BL image by embedding only what's
needed (e.g. BL1 to embed only EL3 variants).

Change-Id: Ib86831d5450cf778ae78c9c1f7553fe91274c2fa

Introduce IS_IN_ELX() macros ...

The goal of these macros is to improve code readability by providing
a concise way to check whether we are running in the expected
exception level.

Change-Id: If9aebadfb6299a5196e9a582b442f0971d9909b1

Merge pull request #65 from vikramkanigiri/vk/console_init ...

Ensure a console is initialized before it is used

Ensure a console is initialized before it is used ...

This patch moves console_init() to bl32_early_platform_setup(). It
also ensures that console_init() is called in each
blX_early_platform_setup() function before the console is used
e.g. through a printf call in an assert() statement.

Fixes ARM-software/TF-issues#127

Change-Id: I5b1f17e0152bab674d807d2a95ff3689c5d4794e

Merge pull request #61 from athoelke/use-mrs-msr-from-assembler-v2 ...

Use MRS/MSR instructions in assembler code v2

Merge pull request #60 from athoelke/disable-mmu-v2 ...

Replace disable_mmu with assembler version v2

Merge pull request #59 from athoelke/review-barriers-v2 ...

Correct usage of data and instruction barriers v2

Remove unused 'PL011_BASE' macro ...

'PL011_BASE' macro is no longer used because the right UART base
address is now directly given to the 'console_init()' function.
This patch removes it.

Change-Id: I94759c99602df4876291a56f9f6a75de337a65ec

Access system registers directly in assembler ...

Instead of using the system register helper functions to read
or write system registers, assembler coded functions should
use MRS/MSR instructions. This results in faster and more
compact code.

This change replaces all usage of the helper functions with
direct register accesses.

Change-Id: I791d5f11f257010bb3e6a72c6c5ab8779f1982b3

Replace disable_mmu with assembler version ...

disable_mmu() cannot work as a C function as there is no control
over data accesses generated by the compiler between disabling and
cleaning the data cache. This results in reading stale data from
main memory.

As assembler version is provided for EL3, and a variant that also
disables the instruction cache which is now used by the BL1
exception handling function.

Fixes ARM-software/tf-issues#147

Change-Id: I0cf394d2579a125a23c2f2989c2e92ace6ddb1a6

Correct usage of data and instruction barriers ...

The current code does not always use data and instruction
barriers as required by the architecture and frequently uses
barriers excessively due to their inclusion in all of the
write_*() helper functions.

Barriers should be used explicitly in assembler or C code
when modifying processor state that requires the barriers in
order to enable review of correctness of the code.

This patch removes the barriers from the helper functions and
introduces them as necessary elsewhere in the code.

PORTING NOTE: check any port of Trusted Firmware for use of
system register helper functions for reliance on the previous
barrier behaviour and add explicit barriers as necessary.

Fixes ARM-software/tf-issues#92

Change-Id: Ie63e187404ff10e0bdcb39292dd9066cb84c53bf

Remove variables from .data section ...

Update code base to remove variables from the .data section,
mainly by using const static data where possible and adding
the const specifier as required. Most changes are to the IO
subsystem, including the framework APIs. The FVP power
management code is also affected.

Delay initialization of the global static variable,
next_image_type in bl31_main.c, until it is realy needed.
Doing this moves the variable from the .data to the .bss
section.

Also review the IO interface for inconsistencies, using
uintptr_t where possible instead of void *. Remove the
io_handle and io_dev_handle typedefs, which were
unnecessary, replacing instances with uintptr_t.

Fixes ARM-software/tf-issues#107.

Change-Id: I085a62197c82410b566e4698e5590063563ed304

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

Always use named structs in header files ...

Add tag names to all unnamed structs in header files. This
allows forward declaration of structs, which is necessary to
reduce header file nesting (to be implemented in a subsequent
commit).

Also change the typedef names across the codebase to use the _t
suffix to be more conformant with the Linux coding style. The
coding style actually prefers us not to use typedefs at all but
this is considered a step too far for Trusted Firmware.

Also change the IO framework structs defintions to use typedef'd
structs to be consistent with the rest of the codebase.

Change-Id: I722b2c86fc0d92e4da3b15e5cab20373dd26786f