Define frequency of system counter in platform code ...

BL3-1 architecture setup code programs the system counter frequency
into the CNTFRQ_EL0 register. This frequency is defined by the
platform, though. This patch introduces a new platform hook that
the architecture setup code can call to retrieve this information.
In the ARM FVP port, this returns the first entry of the frequency
modes table from the memory mapped generic timer.

All system counter setup code has been removed from BL1 as some
platforms may not have initialized the system counters at this stage.
The platform specific settings done exclusively in BL1 have been moved
to BL3-1. In the ARM FVP port, this consists in enabling and
initializing the System level generic timer. Also, the frequency change
request in the counter control register has been set to 0 to make it
explicit it's using the base frequency. The CNTCR_FCREQ() macro has been
fixed in this context to give an entry number rather than a bitmask.

In future, when support for firmware update is implemented, there
is a case where BL1 platform specific code will need to program
the counter frequency. This should be implemented at that time.

This patch also updates the relevant documentation.

bl_common: add image_size() ...

Fixes ARM-software/tf-issues#42

Some callers of load_image() may need to get the size of the image
before/after loading it.

Change-Id: I8dc067b69fc711433651a560ba5a8c3519445857
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>

Generate build time and date message at link time. ...

So it updates each time a bootloader changes, not just when bl*_main.c
files are recompiled.

Fixes ARM-software/tf-issues#33

Change-Id: Ie8e1a7bd7e1913d2e96ac268606284f76af8c5ab
Signed-off-by: Jon Medhurst <tixy@linaro.org>

Add generic functions for setting up aarch64 MMU translation tables ...

Change-Id: I5b8d040ebc6672e40e4f13925e2fd5bc124103f4
Signed-off-by: Jon Medhurst <tixy@linaro.org>

Fix assert in bakery_lock_release() ...

bakery_lock_release() expects an mpidr as the first argument however
bakery_lock_release() is calling it with the 'entry' argument it has
calculated. Rather than fixing this to pass the mpidr value it would be
much more efficient to just replace the call with

   assert(bakery->owner == entry)

As this leaves no remaining users of bakery_lock_held(), we might as
well delete it.

Fixes ARM-software/tf-issues#27

Signed-off-by: Jon Medhurst <tixy@linaro.org>

Implement late binding for runtime hooks ...

At present SPD power management hooks and BL3-2 entry are implemented
using weak references. This would have the handlers bound and registered
with the core framework at build time, but leaves them dangling if a
service fails to initialize at runtime.

This patch replaces implementation by requiring runtime handlers to
register power management and deferred initialization hooks with the
core framework at runtime. The runtime services are to register the
hooks only as the last step, after having all states successfully
initialized.

Change-Id: Ibe788a2a381ef39aec1d4af5ba02376e67269782

Fix semihosting with latest toolchain ...

Fixes issues #10:

https://github.com/ARM-software/tf-issues/issues/10

This patch changes all/most variables of type int to be size_t or long
to fix the sizing and alignment problems found when building with the
newer toolchains such as Linaro GCC 13.12 or later.

Change-Id: Idc9d48eb2ff9b8c5bbd5b227e6907263d1ea188b
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>

Add power management support in the SPD ...

This patch implements a set of handlers in the SPD which are called by
the PSCI runtime service upon receiving a power management
operation. These handlers in turn pass control to the Secure Payload
image if required before returning control to PSCI. This ensures that
the Secure Payload has complete visibility of all power transitions in
the system and can prepare accordingly.

Change-Id: I2d1dba5629b7cf2d53999d39fe807dfcf3f62fe2

Add Test Secure Payload (BL3-2) image ...

This patch adds a simple TSP as the BL3-2 image. The secure payload
executes in S-EL1. It paves the way for the addition of the TSP
dispatcher runtime service to BL3-1. The TSP and the dispatcher service
will serve as an example of the runtime firmware's ability to toggle
execution between the non-secure and secure states in response to SMC
request from the non-secure state.  The TSP will be replaced by a
Trusted OS in a real system.

The TSP also exports a set of handlers which should be called in
response to a PSCI power management event e.g a cpu being suspended or
turned off. For now it runs out of Secure DRAM on the ARM FVP port and
will be moved to Secure SRAM later. The default translation table setup
code assumes that the caller is executing out of secure SRAM. Hence the
TSP exports its own translation table setup function.

The TSP only services Fast SMCs, is non-reentrant and non-interruptible.
It does arithmetic operations on two sets of four operands, one set
supplied by the non-secure client, and the other supplied by the TSP
dispatcher in EL3. It returns the result according to the Secure Monitor
Calling convention standard.

This TSP has two functional entry points:

- An initial, one-time entry point through which the TSP is initialized
  and prepares for receiving further requests from secure
  monitor/dispatcher

- A fast SMC service entry point through which the TSP dispatcher
  requests secure services on behalf of the non-secure client

Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931
Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Factor out translation table setup in ARM FVP port ...

This patch factors out the ARM FVP specific code to create MMU
translation tables so that it is possible for a boot loader stage to
create a different set of tables instead of using the default ones.
The default translation tables are created with the assumption that
the calling boot loader stage executes out of secure SRAM. This might
not be true for the BL3_2 stage in the future.

A boot loader stage can define the `fill_xlation_tables()` function as
per its requirements. It returns a reference to the level 1
translation table which is used by the common platform code to setup
the TTBR_EL3.

This patch is a temporary solution before a larger rework of
translation table creation logic is introduced.

Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6

Add support for BL3-2 in BL3-1 ...

This patch adds the following support to the BL3-1 stage:

1. BL3-1 allows runtime services to specify and determine the security
   state of the next image after BL3-1. This has been done by adding
   the `bl31_set_next_image_type()` & `bl31_get_next_image_type()`
   apis. The default security state is non-secure. The platform api
   `bl31_get_next_image_info()` has been modified to let the platform
   decide which is the next image in the desired security state.

2. BL3-1 exports the `bl31_prepare_next_image_entry()` function to
   program entry into the target security state. It uses the apis
   introduced in 1. to do so.

3. BL3-1 reads the information populated by BL2 about the BL3-2 image
   into its internal data structures.

4. BL3-1 introduces a weakly defined reference `bl32_init()` to allow
   initialisation of a BL3-2 image. A runtime service like the Secure
   payload dispatcher will define this function if present.

Change-Id: Icc46dcdb9e475ce6575dd3f9a5dc7a48a83d21d1

Rework BL2 to BL3-1 hand over interface ...

This patch reworks BL2 to BL3-1 hand over interface by introducing a
composite structure (bl31_args) that holds the superset of information
that needs to be passed from BL2 to BL3-1.

  - The extents of secure memory available to BL3-1
  - The extents of memory available to BL3-2 (not yet implemented) and
    BL3-3
  - Information to execute BL3-2 (not yet implemented) and BL3-3 images

This patch also introduces a new platform API (bl2_get_bl31_args_ptr)
that needs to be implemented by the platform code to export reference to
bl31_args structure which has been allocated in platform-defined memory.

The platform will initialize the extents of memory available to BL3-3
during early platform setup in bl31_args structure. This obviates the
need for bl2_get_ns_mem_layout platform API.

BL2 calls the bl2_get_bl31_args_ptr function to get a reference to
bl31_args structure. It uses the 'bl33_meminfo' field of this structure
to load the BL3-3 image. It sets the entry point information for the
BL3-3 image in the 'bl33_image_info' field of this structure. The
reference to this structure is passed to the BL3-1 image.

Also fixes issue ARM-software/tf-issues#25

Change-Id: Ic36426196dd5ebf89e60ff42643bed01b3500517

Add exception vector guards ...

This patch adds guards so that an exception vector exceeding 32
instructions will generate a compile-time error. This keeps the
exception handlers in check from spilling over.

Change-Id: I7aa56dd0071a333664e2814c656d3896032046fe

Add support for handling runtime service requests ...

This patch uses the reworked exception handling support to handle
runtime service requests through SMCs following the SMC calling
convention. This is a giant commit since all the changes are
inter-related. It does the following:

1. Replace the old exception handling mechanism with the new one
2. Enforce that SP_EL0 is used C runtime stacks.
3. Ensures that the cold and warm boot paths use the 'cpu_context'
   structure to program an ERET into the next lower EL.
4. Ensures that SP_EL3 always points to the next 'cpu_context'
   structure prior to an ERET into the next lower EL
5. Introduces a PSCI SMC handler which completes the use of PSCI as a
   runtime service

Change-Id: I661797f834c0803d2c674d20f504df1b04c2b852
Co-authored-by: Achin Gupta <achin.gupta@arm.com>

Introduce new exception handling framework ...

This patch introduces the reworked exception handling logic which lays
the foundation for accessing runtime services in later patches. The
type of an exception has a greater say in the way it is
handled. SP_EL3 is used as the stack pointer for:

1. Determining the type of exception and handling the unexpected ones
   on the exception stack

2. Saving and restoring the essential general purpose and system
   register state after exception entry and prior to exception exit.

SP_EL0 is used as the stack pointer for handling runtime service
requests e.g. SMCs. A new structure for preserving general purpose
register state has been added to the 'cpu_context' structure. All
assembler ensures that it does not use callee saved registers
(x19-x29). The C runtime preserves them across functions calls. Hence
EL3 code does not have to save and restore them explicitly.

Since the exception handling framework has undergone substantial change,
the changes have been kept in separate files to aid readability. These
files will replace the existing ones in subsequent patches.

Change-Id: Ice418686592990ff7a4260771e8d6676e6c8c5ef

Add runtime services framework ...

This patch introduces the framework to enable registration and
initialisation of runtime services. PSCI is registered and initialised
as a runtime service. Handling of runtime service requests will be
implemented in subsequent patches.

Change-Id: Id21e7ddc5a33d42b7d6e455b41155fc5441a9547

psci: Use context library for preserving EL3 state ...

This patch uses the context library to save and restore EL3 state on
the 'cpu_context' data structures allocated by PSCI for managing
non-secure state context on each cpu.

Change-Id: I19c1f26578204a7cd9e0a6c582ced0d97ee4cf80

Add context management library ...

This patch adds support for a cpu context management library. This
library will be used to:

1. Share pointers to secure and non-secure state cpu contexts between
   runtime services e.g. PSCI and Secure Payload Dispatcher services
2. Set SP_EL3 to a context structure which will be used for
   programming an ERET into a lower EL
3. Provide wrapper functions to save and restore EL3 & EL1
   state. These functions will in turn use the helper functions in
   context.S

Change-Id: I655eeef83dcd2a0c6f2eb2ac23efab866ac83ca0

Add helper library for cpu context management ...

This patch introduces functions for saving and restoring shared system
registers between secure and non-secure EL1 exception levels, VFP
registers and essential EL3 system register and other state. It also
defines the 'cpu_context' data structure which will used for saving and
restoring execution context for a given security state. These functions
will allow runtime services like PSCI and Secure payload dispatcher to
implement logic for switching between the secure and non-secure states.

The save and restore functions follow AArch64 PCS and only use
caller-saved temporary registers.

Change-Id: I8ee3aaa061d3caaedb28ae2c5becb9a206b6fd74

Setup VBAR_EL3 incrementally ...

This patch ensures that VBAR_EL3 points to the simple stack-less
'early_exceptions' when the C runtime stack is not correctly setup to
use the more complex 'runtime_exceptions'. It is initialised to
'runtime_exceptions' once this is done.

This patch also moves all exception vectors into a '.vectors' section
and modifies linker scripts to place all such sections together. This
will minimize space wastage from alignment restrictions.

Change-Id: I8c3e596ea3412c8bd582af9e8d622bb1cb2e049d

Add Firmware Image Package (FIP) driver ...

The Firmware Image Package (FIP) driver allows for data to be loaded
from a FIP on platform storage. The FVP supports loading bootloader
images from a FIP located in NOR FLASH.

The implemented FVP policy states that bootloader images will be
loaded from a FIP in NOR FLASH if available and fall back to loading
individual images from semi-hosting.

NOTE:
- BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured
  to run from the BL33_BASE address. This is currently set to
  DRAM_BASE+128MB for the FVP.

Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0

Add Firmware Image Package creation tool ...

This tool can be used to create a Firmware Image Packages (FIP). These
FIPs store a combined set of firmware images with a Table of Contents
(ToC) that can be loaded by the firmware from platform storage.

- Add uuid.h from FreeBSD.
- Use symbolic links to shared headers otherwise unwanted headers and
  definitions are pulled in.
- A FIP is created as part of the default FVP build.
- A BL3-3 image(e.g. UEFI) must be provided.

Change-Id: Ib73feee181df2dba68bf6abec115a83cfa5e26cb

Implement load_image in terms of IO abstraction ...

The modified implementation uses the IO abstraction rather than
making direct semi-hosting calls.  The semi-hosting driver is now
registered for the FVP platform during initialisation of each boot
stage where it is used.  Additionally, the FVP platform includes a
straightforward implementation of 'plat_get_image_source' which
provides a generic means for the 'load_image' function to determine
how to access the image data.

Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6

Add IO abstraction framework ...

This is intended primarily for use as a storage abstraction.
It allows operations such as image-loading to be implemented
in a platform-independent fashion.  Each platform registers
a set of IO drivers during initialisation.  The platform must
also provide a function that will return a device and a specifier
that can be used to access specified content.

Clients of the API will primarily use device and entity handles.
The term "entity" is deliberately vague, to allow for different
representations of content accessed using different types of
specifier, but will often be interpreted as a "file" where the
specifier will normally be its path.

This commit builds, but is intended to be paired with a sample
implementation of "load_image" using a semi-hosting driver on FVP.

Change-Id: Id3b52f1c0eb9ce76b44b99fc6b6460803668cc86

psci: fix affinity level upgrade issue ...

The psci implementation does not track target affinity level requests
specified during cpu_suspend calls correctly as per the following
example.

1. cpu0.cluster0 calls cpu_suspend with the target affinity level as 0
2. Only the cpu0.cluster0 is powered down while cluster0 remains
   powered up
3. cpu1.cluster0 calls cpu_off to power itself down to highest
   possible affinity level
4. cluster0 will be powered off even though cpu0.cluster0 does not
   allow cluster shutdown

This patch introduces reference counts at affinity levels > 0 to track
the number of cpus which want an affinity instance at level X to
remain powered up. This instance can be turned off only if its
reference count is 0. Cpus still undergo the normal state transitions
(ON, OFF, ON_PENDING, SUSPEND) but the higher levels can only be
either ON or OFF depending upon their reference count.

The above issue is thus fixed as follows:

1. cluster0's reference count is incremented by two when cpu0 and cpu1
   are initially powered on.

2. cpu0.cluster0 calls cpu_suspend with the target affinity level as
   0. This does not affect the cluster0 reference count.

3. Only the cpu0.cluster0 is powered down while cluster0 remains
   powered up as it has a non-zero reference count.

4. cpu1.cluster0 call cpu_off to power itself down to highest possible
   affinity level. This decrements the cluster0 reference count.

5. cluster0 is still not powered off since its reference count will at
   least be 1 due to the restriction placed by cpu0.

Change-Id: I433dfe82b946f5f6985b1602c2de87800504f7a9

psci: replace secure context with suspend context ...

The secure context saved and restored across a cpu_suspend operation
can be more than just the state of the secure system registers e.g. we
also need to save the affinity level till which the cpu is being
powered down. This patch creates a suspend_context data structure
which includes the system register context. This will allow other bits
to be saved and restored as well in subsequent patches.

Change-Id: I1c1f7d25497388b54b7d6ee4fab77e8c6a9992c4

Probe for GICv3 re-distributors on core bring-up ...

The GICv3 distributor can have more ports than CPUs are available in
the system. Probe all re-distributors and use the matching affinity
levels as specified by each core and re-distributor to decide which
re-distributor to use with which CPU core.

If a core cannot be matched with a re-distributor, the core panics and
is placed in an endless loop.

Change-Id: Ie393cfe07c7449a2383959e3c968664882e18afc

Do not trap access to floating point registers ...

Traps when accessing architectural features are disabled by clearing bits
in CPTR_EL3 during early boot, including accesses to floating point
registers. The value of this register was previously undetermined, causing
unwanted traps to EL3. Future EL3 code (for example, context save/restore
code) may use floating point registers, although they are not used by current
code.

Also, the '-mgeneral-regs-only' flag is enabled in the GCC settings to
prevent generation of code that uses floating point registers.

Change-Id: I9a03675f6387bbbee81a6f2c9ccf81150db03747

Update year in copyright text to 2014 ...

Change-Id: Ic7fb61aabae1d515b9e6baf3dd003807ff42da60

Move GIC setup to a separate file ...

GIC setup code which used to be in bl31_plat_setup.c is now in fvp_gic.c
to simplify future changes to other bootloader stages.  This patch moves
code from bl31_plat_setup.c to fvp_gic.c, simplifies the include file
list for bl31_plat_setup.c, moves GIC declarations from the bl31.h header
file into the platform.h, and reworks files according to coding style
guide.

Change-Id: I48d82a4ba33e7114dcc88f9ca98767a06cf8f417