GitLab

The ARM CoreLink DMC-500 Dynamic Memory Controller provides the
programmable address region control of a TrustZone Address Space
Controller. The access permissions can be defined for eight
separate address regions plus a background or default region.
This patch adds a DMC-500 driver to define address regions and
program their access permissions as per ARM 100131_0000_02_en
(r0p0) document.

Change-Id: I9d33120f9480d742bcf7937e4b876f9d40c727e6

TrustZone protection can be programmed by both memory and TrustZone
address space controllers like DMC-500 and TZC-400. These peripherals
share a similar programmer's view.

Furthermore, it is possible to have multiple instances of each type of
peripheral in a system resulting in multiple programmer's views.
For example, on the TZC-400 each of the 4 filter units can be enabled
or disabled for each region. There is a single set of registers to
program the region attributes. On the DMC-500, each filter unit has its
own programmer's view resulting in multiple sets of registers to program
the region attributes. The layout of the registers is almost the same
across all these variations.

Hence the existing driver in `tzc400\tzc400.c` is refactored into the
new driver in `tzc\tzc400.c`. The previous driver file is still maintained
for compatibility and it is now deprecated.

Change-Id: Ieabd0528e244582875bc7e65029a00517671216d

This patch adds support for non-volatile counter authentication to
the Authentication Module. This method consists of matching the
counter values provided in the certificates with the ones stored
in the platform. If the value from the certificate is lower than
the platform, the boot process is aborted. This mechanism protects
the system against rollback.

The TBBR CoT has been updated to include this method as part of the
authentication process. Two counters are used: one for the trusted
world images and another for the non trusted world images.

** NEW PLATFORM APIs (mandatory when TBB is enabled) **

int plat_get_nv_ctr(void *cookie, unsigned int *nv_ctr);

    This API returns the non-volatile counter value stored
    in the platform. The cookie in the first argument may be
    used to select the counter in case the platform provides
    more than one (i.e. TBSA compliant platforms must provide
    trusted and non-trusted counters). This cookie is specified
    in the CoT.

int plat_set_nv_ctr(void *cookie, unsigned int nv_ctr);

    This API sets a new counter value. The cookie may be
    used to select the counter to be updated.

An implementation of these new APIs for ARM platforms is also
provided. The values are obtained from the Trusted Non-Volatile
Counters peripheral. The cookie is used to pass the extension OID.
This OID may be interpreted by the platform to know which counter
must return. On Juno, The trusted and non-trusted counter values
have been tied to 31 and 223, respectively, and cannot be modified.

** IMPORTANT **

THIS PATCH BREAKS THE BUILD WHEN TRUSTED_BOARD_BOOT IS ENABLED. THE
NEW PLATFORM APIs INTRODUCED IN THIS PATCH MUST BE IMPLEMENTED IN
ORDER TO SUCCESSFULLY BUILD TF.

Change-Id: Ic943b76b25f2a37f490eaaab6d87b4a8b3cbc89a

Hence memmap device can be used to load an image without being wrapped in a
FIP.

Fixes arm-software/tf-issues#371
Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>

The PL011 initialization function disables the UART, flushes the FIFO
and waits for the current character to be transmitted before applying
the configuration and enabling the UART. This waiting might result in
a deadlock if the FIFO is disabled while another CPU is printing a
message since the flush of FIFO will never finish.

This patch fixes the problem by removing the flush operation and the
loop for last character completion from the initialization function.
The UART is disabled, configured and enabled again.

Change-Id: I1ca0b6bd9f352c12856f10f174a9f6eaca3ab4ea

This patch adds support for the `%p` format specifier in tf_printf()
following the example of the printf implementation of the stdlib used
in the trusted firmware.

Fixes ARM-software/tf-issues#292

Change-Id: I0b3230c783f735d3e039be25a9405f00023420da

Add PL061 GPIO driver that is depend on gpio framework.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

Define the gpio ops in gpio driver.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

This patch moves the private GIC common accessors from `gic_common.h` to
a new private header file `gic_common_private.h`. This patch also adds
additional comments to GIC register accessors to highlight the fact
that some of them access register values that correspond to multiple
interrupt IDs. The convention used is that the `set`, `get` and `clr`
accessors access and modify the values corresponding to a single interrupt
ID whereas the `read` and `write` GIC register accessors access the raw
GIC registers and it could correspond to multiple interrupt IDs depending
on the register accessed.

Change-Id: I2643ecb2533f01e3d3219fcedfb5f80c120622f9

The code to set the interrupt priority for secure interrupts in the
new GICv2 and GICv3 drivers is incorrect. The setup code to configure
interrupt priorities of secure interrupts, one interrupt at a time, used
gicd_write_ipriorityr()/gicr_write_ipriority() function affecting
4 interrupts at a time. This bug did not manifest itself because all the
secure interrupts were configured to the highest secure priority(0) during
cold boot and the adjacent non secure interrupt priority would be configured
later by the normal world. This patch introduces new accessors,
gicd_set_ipriorityr() and gicr_set_ipriorityr(), for configuring priority
one interrupt at a time and fixes the the setup code to use the new
accessors.

Fixes ARM-software/tf-issues#344

Change-Id: I470fd74d2b7fce7058b55d83f604be05a27e1341

GICD_IPRIORITYR and GICD_ITARGETSR specifically support byte addressing
so that individual interrupt priorities can be atomically updated by
issuing a single byte write. The previous implementation of
gicd_set_ipriority() and gicd_set_itargetsr() used 32-bit register
accesses, modifying values for 4 interrupts at a time, using a
read-modify-write approach. This potentially may cause concurrent changes
by other CPUs to the adjacent interrupts to be corrupted. This patch fixes
the issue by modifying these accessors to use byte addressing.

Fixes ARM-software/tf-issues#343

Change-Id: Iec28b5f5074045b00dfb8d5f5339b685f9425915

Currently, `ccn_snoop_dvm_domain_common()` is responsible for providing
a bitmap of HN-F and HN-I nodes in the interconnect. There is a request
node (RN) corresponding to the master interface (e.g. cluster) that needs
to be added or removed from the snoop/DVM domain. This request node is
removed from or added to each HN-F or HN-I node present in the bitmap
depending upon the type of domain.

The above logic is incorrect when participation of a master interface in
the DVM domain has to be managed. The request node should be removed
from or added to the single Miscellaneous Node (MN) in the system
instead of each HN-I node.

This patch fixes this by removing the intermediate
`ccn_snoop_dvm_domain_common()` and instead reads the MN registers to
get the needed node Id bitmap for snoop(HN-F bitmap) and DVM(MN bitmap)
domains.

Additionally, it renames `MN_DDC_SET_OFF` to `MN_DDC_SET_OFFSET` to
be inline with other macros.

Change-Id: Id896046dd0ccc5092419e74f8ac85e31b104f7a4

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

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>

By default ARM TF is built with the '-pedantic' compiler flag, which
helps detecting violations of the C standard. However, the mbed TLS
library and its associated authentication module in TF used to fail
building with this compiler flag. As a workaround, the mbed TLS
authentication module makefile used to set the 'DISABLE_PEDANTIC'
TF build flag.

The compiler errors flagged by '-pedantic' in the mbed TLS library
have been fixed between versions 1.3.9 and 2.2.0 and the library now
properly builds with this compiler flag.

This patch fixes the remaining compiler errors in the mbed TLS
authentication module in TF and unsets the 'DISABLE_PEDANTIC' TF
build flag. This means that TF is now always built with '-pedantic'.

In particular, this patch:

 * Removes the final semi-colon in REGISTER_COT() macro.

   This semi-colon was causing the following error message:

   drivers/auth/tbbr/tbbr_cot.c:544:23: error: ISO C does not allow
   extra ';' outside of a function [-Werror=pedantic]

   This has been fixed both in the mbed TLS authentication module
   as well as in the certificate generation tool. Note that the latter
   code didn't need fixing since it is not built with '-pedantic' but
   the change has been propagated for consistency.

   Also fixed the REGISTER_KEYS() and REGISTER_EXTENSIONS() macros,
   which were suffering from the same issue.

 * Fixes a pointer type.

   It was causing the following error message:

   drivers/auth/mbedtls/mbedtls_crypto.c: In function 'verify_hash':
   drivers/auth/mbedtls/mbedtls_crypto.c:177:42: error: pointer of
   type 'void *' used in arithmetic [-Werror=pointer-arith]

Change-Id: I7b7a04ef711efd65e17b5be26990d1a0d940257d

The 'ret' was missing in console_uninit() implementation, so the
program doesn't return from console_uninit(). Instead, it keeps
executing the following instructions which is not expected.

Change-Id: I810684f37f61c41c6f95a3bb36914d0765da8571
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>

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

The mbed TLS library has introduced some changes in the API from
the 1.3.x to the 2.x releases. Using the 2.x releases requires
some changes to the crypto and transport modules.

This patch updates both modules to the mbed TLS 2.x API.

All references to the mbed TLS library in the code or documentation
have been updated to 'mbed TLS'. Old references to PolarSSL have
been updated to 'mbed TLS'.

User guide updated to use mbed TLS 2.2.0.

NOTE: moving up to mbed TLS 2.x from 1.3.x is not backward compatible.
Applying this patch will require an mbed TLS 2.x release to be used.
Also note that the mbed TLS license changed to Apache version 2.0.

Change-Id: Iba4584408653cf153091f2ca2ee23bc9add7fda4

The Server Base System Architecture document (ARM-DEN-0029)
specifies a generic UART device. The programmer's view of this
generic UART is a subset of the ARM PL011 UART. However, the
current PL011 driver in Trusted Firmware uses some features
that are outside the generic UART specification.

This patch modifies the PL011 driver to exclude features outside
the SBSA generic UART specification by setting the boolean build
option 'PL011_GENERIC_UART=1'. Default value is 0 (use full
PL011 features).

User guide updated.

Fixes ARM-software/tf-issues#216

Change-Id: I6e0eb86f9d69569bc3980fb57e70d6da5d91a737

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

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

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

Following platform porting functions are introduced:

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

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

plat_bl1_common.c contains weak definitions for above functions.

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

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

Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed

Allowing console base address to be set to NULL conveniently
allows console driver to ignore further invocations to console_putc()
and console_getc(). This patch adds `console_uninit()` API to the
console driver which sets console base address as NULL. The BL images can
invoke this API to finish the use of console and ignore any further
invocations to print to the console.

Change-Id: I00a1762b3e0b7c55f2be2f9c4c9bee3967189dde

When resuming from system suspend the TZC needs to be
re-initialized. Hence the assertion for TZC base address
to detect re-initialization is removed.

Change-Id: I53d64146f6c919e95526441bb997f7b309c68141

This patch renames the GICv3 interrupt group macros from
INT_TYPE_G0, INT_TYPE_G1S and INT_TYPE_G1NS to INTR_GROUP0,
INTR_GROUP1S and INTR_GROUP1NS respectively.

Change-Id: I40c66f589ce6234fa42205adcd91f7d6ad8f33d4

The TZC-400 driver implementation incorrectly uses the component
ID registers to detect the TZC-400 peripheral. As all ARM
peripherals share the same component ID, it doesn't allow to
uniquely identify the TZC-400 peripheral. This patch fixes the
TZC-400 driver by relying on the `part_number_0` and
`part_number_1` fields in the `PID` registers instead.
The `tzc_read_component_id` function has been replaced by
`tzc_read_peripheral_id`, which reads the 'part_number' values
and compares them with the TZC-400 peripheral ID.

Also, it adds a debug assertion to detect when the TZC driver
initialisation function is called multiple times.

Change-Id: I35949f6501a51c0a794144cd1c3a6db62440dce6

Based on SP805 Programmer's model (ARM DDI 0270B). This driver
provides three public APIs:

    void sp805_start(uintptr_t base, unsigned long ticks);
    void sp805_stop(uintptr_t base);
    void sp805_refresh(uintptr_t base, unsigned long ticks);

Upon start, the watchdog starts counting down from the number of
ticks specified. When the count reaches 0 an interrupt is triggered.
The watchdog restarts counting down from the number of ticks
specified. If the count reaches 0 again, the system is reset. A
mechanism to handle the interrupt has not been implemented. Instead,
the API to refresh the watchdog should be used instead to prevent a
system reset.

Change-Id: I799d53f8d1213b10b341a4a67fde6486e89a3dab

This patch adds a driver for ARM GICv2 systems, example GIC-400. Unlike
the existing GIC driver in `include/drivers/arm/arm_gic.h`, this driver
is optimised for GICv2 and does not support GICv3 systems in GICv2
compatibility mode. The driver interface has been implemented in
`drivers/arm/gic/v2/gicv2_main.c`. The corresponding header is in
`include/drivers/arm/gicv2.h`. Helper functions are implemented in
`drivers/arm/gic/v2/gicv2_helpers.c` and are accessible through the
`drivers/arm/gic/v2/gicv2_private.h` header.

Change-Id: I09fffa4e621fb99ba3c01204839894816cd89a2a

This patch adds a driver for ARM GICv3 systems that need to run software
stacks where affinity routing is enabled across all privileged exception
levels for both security states. This driver is a partial implementation
of the ARM Generic Interrupt Controller Architecture Specification, GIC
architecture version 3.0 and version 4.0 (ARM IHI 0069A). The driver does
not cater for legacy support of interrupts and asymmetric configurations.

The existing GIC driver has been preserved unchanged. The common code for
GICv2 and GICv3 systems has been refactored into a new file,
`drivers/arm/gic/common/gic_common.c`. The corresponding header is in
`include/drivers/arm/gic_common.h`.

The driver interface is implemented in `drivers/arm/gic/v3/gicv3_main.c`.
The corresponding header is in `include/drivers/arm/gicv3.h`. Helper
functions are implemented in `drivers/arm/gic/v3/arm_gicv3_helpers.c`
and are accessible through the `drivers/arm/gic/v3/gicv3_private.h`
header.

Change-Id: I8c3c834a1d049d05b776b4dcb76b18ccb927444a

Patch 7e26fe1f deprecates IO specific return definitions in favour
of standard errno codes. This patch removes those definitions
and its usage from the IO framework, IO drivers and IO platform
layer. Following this patch, standard errno codes must be used
when checking the return value of an IO function.

Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f

This patch fixes a copy and paste issue that resulted in the cluster
indexes not being checked as intended. Note that this fix applies to
the deprecated CCI-400 driver, not the unified one.

Change-Id: I497132a91c236690e5eaff908f2db5c8c65e85ab

This patch adds a device driver which can be used to program the following
aspects of ARM CCN IP:

1. Specify the mapping between ACE/ACELite/ACELite+DVM/CHI master interfaces and
   Request nodes.
2. Add and remove master interfaces from the snoop and dvm
   domains.
3. Place the L3 cache in a given power state.
4. Configuring system adress map and enabling 3 SN striping mode of memory
   controller operation.

Change-Id: I0f665c6a306938e5b66f6a92f8549b529aa8f325

From Linux 3.17 onwards, the mainline kernel has support for GICv3
systems and if EL3 exists, it only needs to initialise ICC_SRE_EL3.SRE
and ICC_SRE_EL3.Enable to 1. Hence, this patch removes the redundant
updates of ICC_SRE_EL2 and ICC_PMR_EL1.

NOTE: For partner software's which enter kernel in EL1,
ICC_SRE_EL2.Enable and ICC_SRE_EL2.SRE bit needs to be set to 1
in EL2 before jumping to linux.

Change-Id: I09ed47869351b08a3b034735f532bc677eaa6917

The return value from the SYS_WRITE semihosting operation is 0 if
the call is successful or the number of bytes not written, if there
is an error. The implementation of the write function in the
semihosting driver treats the return value as the number of bytes
written, which is wrong. This patch fixes it.

Change-Id: Id39dac3d17b5eac557408b8995abe90924c85b85

This patch changes the type of the base address parameter in the
ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The
uintptr_t type allows coverage of the whole memory space and to
perform arithmetic operations on the addresses. ARM platform code
has also been updated to use uintptr_t as GIC base address in the
configuration.

Fixes ARM-software/tf-issues#214

Change-Id: I1b87daedadcc8b63e8f113477979675e07d788f1

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

This patch adds the following mbedTLS based libraries:

* Cryptographic library

It is used by the crypto module to verify a digital signature
and a hash. This library relies on mbedTLS to perform the
cryptographic operations. mbedTLS sources must be obtained
separately.

Two key algorithms are currently supported:

    * RSA-2048
    * ECDSA-SECP256R1

The platform is responsible for picking up the required
algorithm by defining the 'MBEDTLS_KEY_ALG' variable in the
platform makefile. Available options are:

    * 'rsa' (for RSA-2048) (default option)
    * 'ecdsa' (for ECDSA-SECP256R1)

Hash algorithm currently supported is SHA-256.

* Image parser library

Used by the image parser module to extract the authentication
parameters stored in X509v3 certificates.

Change-Id: I597c4be3d29287f2f18b82846973afc142ee0bf0

This patch adds the authentication framework that will be used as
the base to implement Trusted Board Boot in the Trusted Firmware.
The framework comprises the following modules:

- Image Parser Module (IPM)

    This module is responsible for interpreting images, check
    their integrity and extract authentication information from
    them during Trusted Board Boot.

    The module currently supports three types of images i.e.
    raw binaries, X509v3 certificates and any type specific to
    a platform. An image parser library must be registered for
    each image type (the only exception is the raw image parser,
    which is included in the main module by default).

    Each parser library (if used) must export a structure in a
    specific linker section which contains function pointers to:

        1. Initialize the library
        2. Check the integrity of the image type supported by
           the library
        3. Extract authentication information from the image

- Cryptographic Module (CM)

    This module is responsible for verifying digital signatures
    and hashes. It relies on an external cryptographic library
    to perform the cryptographic operations.

    To register a cryptographic library, the library must use the
    REGISTER_CRYPTO_LIB macro, passing function pointers to:

        1. Initialize the library
        2. Verify a digital signature
        3. Verify a hash

    Failing to register a cryptographic library will generate
    a build time error.

- Authentication Module (AM)

    This module provides methods to authenticate an image, like
    hash comparison or digital signatures. It uses the image parser
    module to extract authentication parameters, the crypto module
    to perform cryptographic operations and the Chain of Trust to
    authenticate the images.

    The Chain of Trust (CoT) is a data structure that defines the
    dependencies between images and the authentication methods
    that must be followed to authenticate an image.

The Chain of Trust, when added, must provide a header file named
cot_def.h with the following definitions:

- COT_MAX_VERIFIED_PARAMS

    Integer value indicating the maximum number of authentication
    parameters an image can present. This value will be used by the
    authentication module to allocate the memory required to load
    the parameters in the image descriptor.

Change-Id: Ied11bd5cd410e1df8767a1df23bb720ce7e58178

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

Add a delay timer driver for the ARM SP804 dual timer.

This driver only uses the first timer, called timer 1 in the
SP804 Technical Reference Manual (ARM DDI 0271D).

To use this driver, the BSP must provide three constants:

*   The base address of the SP804 dual timer
*   The clock multiplier
*   The clock divider

The BSP is responsible for calling sp804_timer_init(). The SP804
driver instantiates a constant timer_ops_t and calls the generic
timer_init().

Change-Id: I49ba0a52bdf6072f403d1d0a20e305151d4bc086
Co-authored-by: Dan Handley <dan.handley@arm.com>

The API is simple. The BSP or specific timer driver creates an
instance of timer_ops_t, fills in the timer specific data, then calls
timer_init(). The timer specific data includes a function pointer
to return the timer value and a clock multiplier/divider. The ratio
of the multiplier and the divider is the clock frequency in MHz.

After that, mdelay() or udelay() can be called to delay execution for
the specified time (milliseconds or microseconds, respectively).

Change-Id: Icf8a295e1d25874f789bf28b7412156329dc975c
Co-authored-by: Dan Handley <dan.handley@arm.com>