Merge pull request #1168 from matt2048/master

Replace macro ASM_ASSERTION with macro ENABLE_ASSERTIONS

Enable SVE for Non-secure world

This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
to one EL3 will check to see if the Scalable Vector Extension (SVE) is
implemented when entering

Enable SVE for Non-secure world

This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
to one EL3 will check to see if the Scalable Vector Extension (SVE) is
implemented when entering and exiting the Non-secure world.

If SVE is implemented, EL3 will do the following:

- Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.

- Exit from Non-secure world: SIMD, FP and SVE functionality is
disabled. As SIMD and FP registers are part of the SVE Z-registers
then any use of SIMD / FP functionality would corrupt the SVE
registers.

The build option default is 1. The SVE functionality is only supported
on AArch64 and so the build option is set to zero when the target
archiecture is AArch32.

This build option is not compatible with the CTX_INCLUDE_FPREGS - an
assert will be raised on platforms where SVE is implemented and both
ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.

Also note this change prevents secure world use of FP&SIMD registers on
SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on
such platforms unless ENABLE_SVE_FOR_NS is set to 0.

Additionally, on the first entry into the Non-secure world the SVE
functionality is enabled and the SVE Z-register length is set to the
maximum size allowed by the architecture. This includes the use case
where EL2 is implemented but not used.

Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae
Signed-off-by: David Cunado <david.cunado@arm.com>

show more ...

Merge pull request #1170 from dp-arm/dp/amu

Add support for Activity Monitors

Implement support for the Activity Monitor Unit on Cortex A75

The Cortex A75 has 5 AMU counters. The first three counters are fixed
and the remaining two are programmable.

A new build option is in

Implement support for the Activity Monitor Unit on Cortex A75

The Cortex A75 has 5 AMU counters. The first three counters are fixed
and the remaining two are programmable.

A new build option is introduced, `ENABLE_AMU`. When set, the fixed
counters will be enabled for use by lower ELs. The programmable
counters are currently disabled.

Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

show more ...

Replace macro ASM_ASSERTION with macro ENABLE_ASSERTIONS

This patch replaces the macro ASM_ASSERTION with the macro
ENABLE_ASSERTIONS in ARM Cortex-A53/57/72 MPCore Processor
related files. There is

Replace macro ASM_ASSERTION with macro ENABLE_ASSERTIONS

This patch replaces the macro ASM_ASSERTION with the macro
ENABLE_ASSERTIONS in ARM Cortex-A53/57/72 MPCore Processor
related files. There is build error when ASM_ASSERTION is set
to 1 and ENABLE_ASSERTIONS is set to 0 because function
asm_assert in common/aarch32/debug.S is defined in the macro
ENABLE_ASSERTIONS but is called with the macro ASM_ASSERTION.

There is also the indication to use ENABLE_ASSERTIONS but not
ASM_ASSERTION in the Makefile.

Signed-off-by: Matt Ma <matt.ma@spreadtrum.com>

show more ...

Merge pull request #1162 from dp-arm/spe-rework

Move SPE code to lib/extensions

Change Statistical Profiling Extensions build option handling

It is not possible to detect at compile-time whether support for an
optional extension such as SPE should be enabled based on the
ARM_AR

Change Statistical Profiling Extensions build option handling

It is not possible to detect at compile-time whether support for an
optional extension such as SPE should be enabled based on the
ARM_ARCH_MINOR build option value. Therefore SPE is now enabled by
default.

Change-Id: I670db164366aa78a7095de70a0962f7c0328ab7c
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

show more ...

Merge pull request #1152 from jeenu-arm/ehf-and-sdei

EHF and SDEI

BL31: Add SDEI dispatcher

The implementation currently supports only interrupt-based SDEI events,
and supports all interfaces as defined by SDEI specification version
1.0 [1].

Introduce the build o

BL31: Add SDEI dispatcher

The implementation currently supports only interrupt-based SDEI events,
and supports all interfaces as defined by SDEI specification version
1.0 [1].

Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in
BL31.

Update user guide and porting guide. SDEI documentation to follow.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf

Change-Id: I758b733084e4ea3b27ac77d0259705565842241a
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

show more ...

BL31: Introduce Exception Handling Framework

EHF is a framework that allows dispatching of EL3 interrupts to their
respective handlers in EL3.

This framework facilitates the firmware-first error ha

BL31: Introduce Exception Handling Framework

EHF is a framework that allows dispatching of EL3 interrupts to their
respective handlers in EL3.

This framework facilitates the firmware-first error handling policy in
which asynchronous exceptions may be routed to EL3. Such exceptions may
be handed over to respective exception handlers. Individual handlers
might further delegate exception handling to lower ELs.

The framework associates the delegated execution to lower ELs with a
priority value. For interrupts, this corresponds to the priorities
programmed in GIC; for other types of exceptions, viz. SErrors or
Synchronous External Aborts, individual dispatchers shall explicitly
associate delegation to a secure priority. In order to prevent lower
priority interrupts from preempting higher priority execution, the
framework provides helpers to control preemption by virtue of
programming Priority Mask register in the interrupt controller.

This commit allows for handling interrupts targeted at EL3. Exception
handlers own interrupts by assigning them a range of secure priorities,
and registering handlers for each priority range it owns.

Support for exception handling in BL31 image is enabled by setting the
build option EL3_EXCEPTION_HANDLING=1.

Documentation to follow.

NOTE: The framework assumes the priority scheme supported by platform
interrupt controller is compliant with that of ARM GIC architecture (v2
or later).

Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

show more ...

Merge pull request #1148 from antonio-nino-diaz-arm/an/spm

Introduce Secure Partition Manager

SPM: Introduce Secure Partition Manager

A Secure Partition is a software execution environment instantiated in
S-EL0 that can be used to implement simple management and security
services. Since S-EL

SPM: Introduce Secure Partition Manager

A Secure Partition is a software execution environment instantiated in
S-EL0 that can be used to implement simple management and security
services. Since S-EL0 is an unprivileged exception level, a Secure
Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
granted access to system and processor resources. Essentially, it is a
software sandbox that runs under the control of privileged software in
the Secure World and accesses the following system resources:

- Memory and device regions in the system address map.
- PE system registers.
- A range of asynchronous exceptions e.g. interrupts.
- A range of synchronous exceptions e.g. SMC function identifiers.

A Secure Partition enables privileged firmware to implement only the
absolutely essential secure services in EL3 and instantiate the rest in
a partition. Since the partition executes in S-EL0, its implementation
cannot be overly complex.

The component in ARM Trusted Firmware responsible for managing a Secure
Partition is called the Secure Partition Manager (SPM). The SPM is
responsible for the following:

- Validating and allocating resources requested by a Secure Partition.
- Implementing a well defined interface that is used for initialising a
Secure Partition.
- Implementing a well defined interface that is used by the normal world
and other secure services for accessing the services exported by a
Secure Partition.
- Implementing a well defined interface that is used by a Secure
Partition to fulfil service requests.
- Instantiating the software execution environment required by a Secure
Partition to fulfil a service request.

Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f
Co-authored-by: Douglas Raillard <douglas.raillard@arm.com>
Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Co-authored-by: Achin Gupta <achin.gupta@arm.com>
Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...

Merge pull request #1130 from jeenu-arm/gic-patches

New GIC APIs and specifying interrupt propertes

GIC: Add APIs to set interrupt type and query support

The back end GIC driver converts and assigns the interrupt type to
suitable group.

For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, wh

GIC: Add APIs to set interrupt type and query support

The back end GIC driver converts and assigns the interrupt type to
suitable group.

For GICv2, a build option GICV2_G0_FOR_EL3 is introduced, which
determines to which type Group 0 interrupts maps to.

- When the build option is set 0 (the default), Group 0 interrupts are
meant for Secure EL1. This is presently the case.

- Otherwise, Group 0 interrupts are meant for EL3. This means the SPD
will have to synchronously hand over the interrupt to Secure EL1.

The query API allows the platform to query whether the platform supports
interrupts of a given type.

API documentation updated.

Change-Id: I60fdb4053ffe0bd006b3b20914914ebd311fc858
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

show more ...

Merge pull request #1080 from soby-mathew/eb/RSA-PKCS1-5_support_1

Support legacy RSA PKCS#1 v1.5 in cert create

Export KEY_ALG as a user build option

The `KEY_ALG` variable is used to select the algorithm for key
generation by `cert_create` tool for signing the certificates. This
variable was previously undoc

Export KEY_ALG as a user build option

The `KEY_ALG` variable is used to select the algorithm for key
generation by `cert_create` tool for signing the certificates. This
variable was previously undocumented and did not have a global default
value. This patch corrects this and also adds changes to derive the
value of `TF_MBEDTLS_KEY_ALG` based on `KEY_ALG` if it not set by the
platform. The corresponding assignment of these variables are also now
removed from the `arm_common.mk` makefile.

Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Change-Id: I78e2d6f4fc04ed5ad35ce2266118afb63127a5a4

show more ...

Merge pull request #1046 from jeenu-arm/revc

Support for RevC FVP model

CCI: Adapt for specific product at run time

The current build system and driver requires the CCI product to be
specified at build time. The device constraints can be determined at run
time from its

CCI: Adapt for specific product at run time

The current build system and driver requires the CCI product to be
specified at build time. The device constraints can be determined at run
time from its ID registers, obviating the need for specifying them
ahead.

This patch adds changes to identify and validate CCI at run time. Some
global variables are renamed to be in line with the rest of the code
base.

The build option ARM_CCI_PRODUCT_ID is now removed, and user guide is
updated.

Change-Id: Ibb765e349d3bc95ff3eb9a64bde1207ab710a93d
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

show more ...

Merge pull request #997 from dp-arm/dp/spe

aarch64: Enable Statistical Profiling Extensions for lower ELs

aarch64: Enable Statistical Profiling Extensions for lower ELs

SPE is only supported in non-secure state. Accesses to SPE specific
registers from SEL1 will trap to EL3. During a world switch, befo

aarch64: Enable Statistical Profiling Extensions for lower ELs

SPE is only supported in non-secure state. Accesses to SPE specific
registers from SEL1 will trap to EL3. During a world switch, before
`TTBR` is modified the SPE profiling buffers are drained. This is to
avoid a potential invalid memory access in SEL1.

SPE is architecturally specified only for AArch64.

Change-Id: I04a96427d9f9d586c331913d815fdc726855f6b0
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

show more ...

Merge pull request #962 from antonio-nino-diaz-arm/an/fwu-checks

FWU: Check for overlaps when loading images, introduce `FWU_SMC_IMAGE_RESET`

Remove `DISABLE_PEDANTIC` build option

It doesn't make sense to use the `-pedantic` flag when building the
Trusted Firmware as we use GNU extensions and so our code is not
fully ISO C compliant. Thi

Remove `DISABLE_PEDANTIC` build option

It doesn't make sense to use the `-pedantic` flag when building the
Trusted Firmware as we use GNU extensions and so our code is not
fully ISO C compliant. This flag only makes sense if the code intends to
be ISO C compliant.

Change-Id: I6273564112759ff57f03b273f5349733a5f38aef
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

show more ...

Merge pull request #938 from masahir0y/tools_share

Collect headers shared between TF and host-tools into include/tools_share

cert: move platform_oid.h to include/tools_share for all platforms

Platforms aligned with TBBR are supposed to use their own OIDs, but
defining the same macros with different OIDs does not provide a

cert: move platform_oid.h to include/tools_share for all platforms

Platforms aligned with TBBR are supposed to use their own OIDs, but
defining the same macros with different OIDs does not provide any
value (at least technically).

For easier use of TBBR, this commit allows platforms to reuse the OIDs
obtained by ARM Ltd. This will be useful for non-ARM vendors that
do not need their own extension fields in their certificate files.

The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h

Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by
defining USE_TBBR_DEFS as 1. USE_TBBR_DEFS is 0 by default to keep the
backward compatibility.

For clarification, I inserted a blank line between headers from the
include/ directory (#include <...>) and ones from a local directory
(#include "..." ).

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

show more ...

Merge pull request #925 from dp-arm/dp/spdx

Use SPDX license identifiers