GitLab

This patch adds an option to the ARM common platforms to load BL31 in the
TZC secured DRAM instead of the default secure SRAM.

To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
If TSP is present, then setting this option also sets the TSP location
to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.

To use this feature, BL2 platform code must map in the DRAM used by
BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
Currently, only the FVP BL2 platform code maps in this DRAM.

Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67

Added a new platform porting function plat_panic_handler, to allow
platforms to handle unexpected error situations. It must be
implemented in assembly as it may be called before the C environment
is initialized. A default implementation is provided, which simply
spins.

Corrected all dead loops in generic code to call this function
instead. This includes the dead loop that occurs at the end of the
call to panic().

All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
been removed.

Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134

This patch fixes inconsistencies in bl1_tbbr_image_descs[]
and miscellaneous fixes in Firmware Update code.

Following are the changes:
* As part of the original FWU changes, a `copied_size`
  field was added to `image_info_t`. This was a subtle binary
  compatibility break because it changed the size of the
  `bl31_params_t` struct, which could cause problems if
  somebody used different versions of BL2 or BL31, one with
  the old `image_info_t` and one with the new version.
  This patch put the `copied_size` within the `image_desc_t`.
* EXECUTABLE flag is now stored in `ep_info.h.attr` in place
  of `image_info.h.attr`, associating it to an entrypoint.
* The `image_info.image_base` is only relevant for secure
  images that are copied from non-secure memory into secure
  memory. This patch removes initializing `image_base` for
  non secure images in the bl1_tbbr_image_descs[].
* A new macro `SET_STATIC_PARAM_HEAD` is added for populating
  bl1_tbbr_image_descs[].ep_info/image_info.h members statically.
  The version, image_type and image attributes are now
  populated using this new macro.
* Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct
  usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c.
* Refactoring of code/macros related to SECURE and EXECUTABLE flags.

NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t`
      OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr`
      OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE
      BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY.

Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d

`board_arm_def.h` contains multiple definitions of
`PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
memory usage depending upon the chosen build configuration. To ease
maintenance of these constants, this patch replaces their multiple
definitions with a single set of definitions that will work on all ARM
platforms.

Platforms can override the defaults with optimal values by enabling the
`ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
the Juno ADP port.

Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
future ARM platforms.

Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0

The common topology description helper funtions and macros for
ARM Standard platforms assumed a dual cluster system. This is not
flexible enough to scale to multi cluster platforms. This patch does
the following changes for more flexibility in defining topology:

1. The `plat_get_power_domain_tree_desc()` definition is moved from
   `arm_topology.c` to platform specific files, that is `fvp_topology.c`
   and `juno_topology.c`. Similarly the common definition of the porting
   macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
   specific `platform_def.h` header.

2. The ARM common layer porting macros which were dual cluster specific
   are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
   which must be defined by each ARM standard platform.

3. A new mandatory ARM common layer porting API
   `plat_arm_get_cluster_core_count()` is introduced to enable the common
   implementation of `arm_check_mpidr()` to validate MPIDR.

4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
   introduced which allows the user to specify the cluster count to be
   used to build the topology tree within Trusted Firmare. This enables
   Trusted Firmware to be built for multi cluster FVP models.

Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b

The shared memory region on ARM platforms contains the mailboxes and,
on Juno, the payload area for communication with the SCP. This shared
memory may be configured as normal memory or device memory at build
time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
When set as normal memory, the platform port performs the corresponding
cache maintenance operations. From a functional point of view, this is
the equivalent of setting the shared memory as device memory, so there
is no need to maintain both options.

This patch removes the option to specify the shared memory as normal
memory on ARM platforms. Shared memory is always treated as device
memory. Cache maintenance operations are no longer needed and have
been replaced by data memory barriers to guarantee that payload and
MHU are accessed in the right order.

Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f

ARM Trusted Firmware supports 2 different interconnect peripheral
drivers: CCI and CCN. ARM platforms are implemented using either of the
interconnect peripherals.

This patch adds a layer of abstraction to help ARM platform ports to
choose the right interconnect driver and corresponding platform support.
This is as described below:

1. A set of ARM common functions have been implemented to initialise an
interconnect and for entering/exiting a cluster from coherency. These
functions are prefixed as "plat_arm_interconnect_". Weak definitions of
these functions have been provided for each type of driver.

2.`plat_print_interconnect_regs` macro used for printing CCI registers is
moved from a common arm_macros.S to cci_macros.S.

3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure
is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.

Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c

Current code mandates loading of SCP_BL2/SCP_BL2U images for all
CSS platforms. On future ARM CSS platforms, the Application
Processor (AP) might not need to load these images. So, these
items can be removed from the FIP on those platforms.

BL2 tries to load  SCP_BL2/SCP_BL2U images if their base
addresses are defined causing boot error if the images are not
found in FIP.

This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set
to `1` does:
1. Adds SCP_BL2, SCP_BL2U images to FIP.
2. Defines the base addresses of these images so that AP loads
   them.

And vice-versa if it is set to `0`. The default value is set to
`1`.

Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a

Prior to this patch, it was assumed that on all ARM platforms the bare
minimal security setup required is to program TrustZone protection. This
would always be done by programming the TZC-400 which was assumed to be
present in all ARM platforms. The weak definition of
platform_arm_security_setup() in plat/arm/common/arm_security.c
reflected these assumptions.

In reality, each ARM platform either decides at runtime whether
TrustZone protection needs to be programmed (e.g. FVPs) or performs
some security setup in addition to programming TrustZone protection
(e.g. NIC setup on Juno). As a result, the weak definition of
plat_arm_security_setup() is always overridden.

When a platform needs to program TrustZone protection and implements the
TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is
also possible to program TrustZone protection through other peripherals
that include a TrustZone controller e.g. DMC-500. The programmer's
interface is slightly different across these various peripherals.

In order to satisfy the above requirements, this patch makes the
following changes to the way security setup is done on ARM platforms.

1. arm_security.c retains the definition of arm_tzc_setup() and has been
   renamed to arm_tzc400.c. This is to reflect the reliance on the
   TZC-400 peripheral to perform TrustZone programming. The new file is
   not automatically included in all platform ports through
   arm_common.mk. Each platform must include it explicitly in a platform
   specific makefile if needed.

   This approach enables introduction of similar library code to program
   TrustZone protection using a different peripheral. This code would be
   used by the subset of ARM platforms that implement this peripheral.

2. Due to #1 above, existing platforms which implements the TZC-400 have been
   updated to include the necessary files for both BL2, BL2U and BL31
   images.

Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735

Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
cater for future ARM platforms this is made platform specific.
Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
platform specific.

Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8

Functions to configure the MMU in S-EL1 and EL3 on ARM platforms
expect each platform to export its memory map in the `plat_arm_mmap`
data structure. This approach does not scale well in case the memory
map cannot be determined until runtime. To cater for this possibility,
this patch introduces the plat_arm_get_mmap() API. It returns a
reference to the `plat_arm_mmap` by default but can be overridden
by a platform if required.

Change-Id: Idae6ad8fdf40cdddcd8b992abc188455fa047c74

Each ARM Compute Subsystem based platform implements a System Security
Control (SSC) Registers Unit. The SSC_VERSION register inside it carries
information to identify the platform. This enables ARM Trusted Firmware
to compile in support for multiple ARM platforms and choose one at
runtime. This patch adds macros to enable access to this register.
Each platform is expected to export its PART_NUMBER separately.

Additionally, it also adds juno part number.

Change-Id: I2b1d5f5b65a9c7b76c6f64480cc7cf0aef019422

This patch moves the definition of some macros used only on
ARM platforms from common headers to platform specific headers.
It also forces all ARM standard platforms to have distinct
definitions (even if they are usually the same).
 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
     moved from `css_def.h` to `platform_def.h`.
 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
    to platform specific header `platform_def.h` on Juno and
    renamed as `PLAT_ARM_MHU_BASE`.
 3. To cater for different sizes of BL images, new macros like
    `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
    ARM platforms need to define them for each image.

Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f

Replaced a long dash in a comment by the ASCII character '-'. Support
for multibyte character in the source character set is not enforced by
the C99 standard. To maximize compatibility with C processing tools
(e.g. compilers or static code analysis tools), they should be removed.

Change-Id: Ie318e380d3b44755109f042a76ebfd2229f42ae3

The PL011 TRM (ARM DDI 0183G) specifies that the UART must be
disabled before any of the control registers are programmed. The
PL011 driver included in TF does not disable the UART, so the
initialization in BL2 and BL31 is violating this requirement
(and potentially in BL1 if the UART is enabled after reset).

This patch modifies the initialization function in the PL011
console driver to disable the UART before programming the
control registers.

Register clobber list and documentation updated.

Fixes ARM-software/tf-issues#300

Change-Id: I839b2d681d48b03f821ac53663a6a78e8b30a1a1

Currently, Trusted Firmware on ARM platforms unlocks access to the
timer frame registers that will be used by the Non-Secure world. This
unlock operation should be done by the Non-Secure software itself,
instead of relying on secure firmware settings.

This patch adds a new ARM specific build option 'ARM_CONFIG_CNTACR'
to unlock access to the timer frame by setting the corresponding
bits in the CNTACR<N> register. The frame id <N> is defined by
'PLAT_ARM_NSTIMER_FRAME_ID'. Default value is true (unlock timer
access).

Documentation updated accordingly.

Fixes ARM-software/tf-issues#170

Change-Id: Id9d606efd781e43bc581868cd2e5f9c8905bdbf6

Migrate all direct usage of __attribute__ to usage of their
corresponding macros from cdefs.h.
e.g.:
 - __attribute__((unused)) -> __unused
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>

This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP.
This allows the same TF binaries to run on a Cortex-A72 based FVP
without recompiling them.

Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47

This patch adds support for ARM Cortex-A35 processor in the CPU
specific framework, as described in the Cortex-A35 TRM (r0p0).

Change-Id: Ief930a0bdf6cd82f6cb1c3b106f591a71c883464

The fip_create tool specifies images in the command line using the
ARM TF naming convention (--bl2, --bl31, etc), while the cert_create
tool uses the TBBR convention (--tb-fw, --soc-fw, etc). This double
convention is confusing and should be aligned.

This patch updates the fip_create command line options to follow the
TBBR naming convention. Usage examples in the User Guide have been
also updated.

NOTE: users that build the FIP by calling the fip_create tool directly
from the command line must update the command line options in their
scripts. Users that build the FIP by invoking the main ARM TF Makefile
should not notice any difference.

Change-Id: I84d602630a2585e558d927b50dfde4dd2112496f

Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b

fvp_pwr_domain_on() used to program the CPUs mailbox. This changed
with commit 804040d1 but the comment documenting this code still
refers to the mailbox programming. This patch removes this out-dated
information.

Change-Id: Ibfe2a426bdda6e71f20c83a99cb223ceca9c559c

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

This patch removes the dash character from the image name, to
follow the image terminology in the Trusted Firmware Wiki page:

    https://github.com/ARM-software/arm-trusted-firmware/wiki

Changes apply to output messages, comments and documentation.

non-ARM platform files have been left unmodified.

Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76

This patch replaces all references to the SCP Firmware (BL0, BL30,
BL3-0, bl30) with the image terminology detailed in the TF wiki
(https://github.com/ARM-software/arm-trusted-firmware/wiki):

    BL0          -->  SCP_BL1
    BL30, BL3-0  -->  SCP_BL2
    bl30         -->  scp_bl2

This change affects code, documentation, build system, tools and
platform ports that load SCP firmware. ARM plaforms have been
updated to the new porting API.

IMPORTANT: build option to specify the SCP FW image has changed:

    BL30 --> SCP_BL2

IMPORTANT: This patch breaks compatibility for platforms that use BL2
to load SCP firmware. Affected platforms must be updated as follows:

    BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
    BL30_BASE --> SCP_BL2_BASE
    bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
    bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()

Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58

This patch applies the TBBR naming convention to the certificates
and the corresponding extensions defined by the CoT:

    * Certificate UUID names
    * Certificate identifier names
    * OID names

Changes apply to:

    * Generic code (variables and defines)
    * The default certificate identifiers provided in the generic
      code
    * Build system
    * ARM platforms port
    * cert_create tool internal definitions
    * fip_create and cert_create tools command line options
    * Documentation

IMPORTANT: this change breaks the compatibility with platforms
that use TBBR. The platform will need to adapt the identifiers
and OIDs to the TBBR naming convention introduced by this patch:

Certificate UUIDs:

    UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT
    UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT
    UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT
    UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT
    UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT
    UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT
    UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT
    UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT
    UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT

Certificate identifiers:

    BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID
    BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID
    BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID
    BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID
    BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID
    BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID
    BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID
    BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID
    BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID

OIDs:

    TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID
    NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID
    BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID
    TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID
    NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID
    BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID
    BL30_HASH_OID --> SCP_FW_HASH_OID
    BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID
    BL31_HASH_OID --> SOC_AP_FW_HASH_OID
    BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID
    BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID
    BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID
    BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID
    BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID
    SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID
    NS_BL2U_HASH_OID --> FWU_HASH_OID

Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079

Firmware update feature needs a new FIP called `fwu_fip.bin` that
includes Secure(SCP_BL2U, BL2U) and Normal world(NS_BL2U) images
along with the FWU_CERT certificate in order for NS_BL1U to load
the images and help the Firmware update process to complete.

This patch adds the capability to support the new target `fwu_fip`
which includes above mentioned FWU images in the make files.

The new target of `fwu_fip` and its dependencies are included for
compilation only when `TRUSTED_BOARD_BOOT` is defined.

Change-Id: Ie780e3aac6cbd0edfaff3f9af96a2332bd69edbc

This patch adds support for Firmware update in BL2U for ARM
platforms such that TZC initialization is performed on all
ARM platforms and (optionally) transfer of SCP_BL2U image on
ARM CSS platforms.

BL2U specific functions are added to handle early_platform and
plat_arch setup. The MMU is configured to map in the BL2U
code/data area and other required memory.

Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f

This patch adds Firmware Update support for ARM platforms.

New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
platform specific Firmware update code.

BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
authenticating NS_BL2U image(For both FVP and JUNO platform).

Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555

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

This patch adds support for secure setup of the SoC on CSS
platforms in BL1.

This change is required to provide memory access to normal
world images that take part in upcoming Firmware Update feature.

Change-Id: Ib202fb6cb82622c1874b700637d82ea72575e6fe

This patch overrides the default weak definition of
`bl31_plat_runtime_setup()` for ARM Standard platforms to
specify a BL31 runtime console. ARM Standard platforms are
now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
`PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
by `arm_bl31_plat_runtime_setup()` to initialize the runtime
console.

The system suspend resume helper `arm_system_pwr_domain_resume()`
is fixed to initialize the runtime console rather than the boot
console on resumption from system suspend.

Fixes ARM-software/tf-issues#220

Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975

Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
separate drivers instead of providing a single driver that can work on both
versions of the GIC architecture. These drivers correspond to the following
software use cases:

1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
   e.g. GIC-400

2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
   e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features

3. A deprecated GICv3 driver that operates in legacy mode. This driver can
   operate only in the GICv2 mode in the secure world. On a GICv3 system, this
   driver allows normal world to run in either GICv3 mode (asymmetric mode)
   or in the GICv2 mode. Both modes of operation are deprecated on GICv3
   systems.

ARM platforms implement both versions of the GIC architecture. This patch adds a
layer of abstraction to help ARM platform ports chose the right GIC driver and
corresponding platform support. This is as described below:

1. A set of ARM common functions have been introduced to initialise the GIC and
   the driver during cold and warm boot. These functions are prefixed as
   "plat_arm_gic_". Weak definitions of these functions have been provided for
   each type of driver.

2. Each platform includes the sources that implement the right functions
   directly into the its makefile. The FVP can be instantiated with different
   versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
   to specify which of the three drivers should be included in the build.

3. A list of secure interrupts has to be provided to initialise each of the
  three GIC drivers. For GIC v3.0 the interrupt ids have to be further
  categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
  types are merged and treated as Group 0 interrupts.

  The two lists of interrupts are exported from the platform_def.h. The lists
  are constructed by adding a list of board specific interrupt ids to a list of
  ids common to all ARM platforms and Compute sub-systems.

This patch also makes some fields of `arm_config` data structure in FVP redundant
and these unused fields are removed.

Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8

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

This patch fixes several issues with the SP804 delay timer on FVP:

* By default, the SP804 dual timer on FVP runs at 32 KHz. In order
  to run the timer at 35 MHz (as specified in the FVP user manual)
  the Overwrite bit in the SP810 control register must be set.

* The CLKMULT and CLKDIV definitions are mixed up:

      delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)

  From the delay function:

      delta_us = (delta * ops->clk_mult) / ops->clk_div;

  Matching both expressions:

      1 / f(MHz) = ops->clk_mult / ops->clk_div

  And consequently:

      f(MHz) = ops->clk_div / ops->clk_mult

  Which, for a 35 MHz timer, translates to:

      ops->clk_div = 35
      ops->clk_mult = 1

* The comment in the delay timer header file has been corrected:
  The ratio of the multiplier and the divider is the clock period
  in microseconds, not the frequency.

Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1

This patch adds watchdog support on ARM platforms (FVP and Juno).
A secure instance of SP805 is used as Trusted Watchdog. It is
entirely managed in BL1, being enabled in the early platform setup
hook and disabled in the exit hook. By default, the watchdog is
enabled in every build (even when TBB is disabled).

A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
has been introduced to allow the user to disable the watchdog at
build time. This feature may be used for testing or debugging
purposes.

Specific error handlers for Juno and FVP are also provided in this
patch. These handlers will be called after an image load or
authentication error. On FVP, the Table of Contents (ToC) in the FIP
is erased. On Juno, the corresponding error code is stored in the
V2M Non-Volatile flags register. In both cases, the CPU spins until
a watchdog reset is generated after 256 seconds (as specified in
the TBBR document).

Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4

FVP and Juno platforms include a NOR flash memory to store and
load the FIP, the kernel or a ramdisk. This NOR flash is arranged
as 2 x 16 bit flash devices and can be programmed using CFI
standard commands.

This patch provides a basic API to write single 32 bit words of
data into the NOR flash. Functions to lock/unlock blocks against
erase or write operations are also provided.

Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2

Normally, in the FVP port, secondary CPUs are immediately powered
down if they are powered on at reset. However, when booting an EL3
payload, we need to keep them powered on as the requirement is for
all CPUs to enter the EL3 payload image. This patch puts them in a
holding pen instead of powering them off.

Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c

By default, only the primary CPU is powered on by SCP on CSS
platforms. Secondary CPUs are then powered on later using PSCI
calls.

However, it is possible to power on more than one CPU at boot time
using platform specific settings. In this case, several CPUs will
enter the Trusted Firmware and execute the cold boot path code.
This is currently not supported and secondary CPUs will panic.

This patch preserves this behaviour in the normal boot flow.
However, when booting an EL3 payload, secondary CPUs are now held in
a pen until their mailbox is populated, at which point they jump to
this address. Note that, since all CPUs share the same mailbox, they
will all be released from their holding pen at the same time and the
EL3 payload is responsible to arbitrate execution between CPUs if
required.

Change-Id: I83737e0c9f15ca5e73afbed2e9c761bc580735b9

This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.

Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.

The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.

The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.

The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.

This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.

Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077