Add new function-pointer-based console API

This patch overhauls the console API to allow for multiple console
instances of different drivers that are active at the same time. Instead
of binding to w

Add new function-pointer-based console API

This patch overhauls the console API to allow for multiple console
instances of different drivers that are active at the same time. Instead
of binding to well-known function names (like console_core_init),
consoles now provide a register function (e.g. console_16550_register())
that will hook them into the list of active consoles. All console
operations will be dispatched to all consoles currently in the list.

The new API will be selected by the build-time option MULTI_CONSOLE_API,
which defaults to ${ERROR_DEPRECATED} for now. The old console API code
will be retained to stay backwards-compatible to older platforms, but
should no longer be used for any newly added platforms and can hopefully
be removed at some point in the future.

The new console API is intended to be used for both normal (bootup) and
crash use cases, freeing platforms of the need to set up the crash
console separately. Consoles can be individually configured to be active
active at boot (until first handoff to EL2), at runtime (after first
handoff to EL2), and/or after a crash. Console drivers should set a sane
default upon registration that can be overridden with the
console_set_scope() call. Code to hook up the crash reporting mechanism
to this framework will be added with a later patch.

This patch only affects AArch64, but the new API could easily be ported
to AArch32 as well if desired.

Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
Signed-off-by: Julius Werner <jwerner@chromium.org>

show more ...

Merge pull request #1178 from davidcunado-arm/dc/enable_sve

Enable SVE for Non-secure world

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 ...

ARM platforms: Fixup AArch32 builds

This patch fixes a couple of issues for AArch32 builds on ARM reference
platforms :

1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and

ARM platforms: Fixup AArch32 builds

This patch fixes a couple of issues for AArch32 builds on ARM reference
platforms :

1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and
AArch32 build. Since BL31 is not present in AArch32 mode, this meant that
the BL31 memory is empty when built for AArch32. Hence this patch allocates
BL32 to the memory region occupied by BL31 for AArch32 builds.

As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot
be used to control the load address of BL32 in AArch32 mode which was
never the intention of the macro anyway.

2. A static assert is added to sp_min linker script to check that the progbits
are within the bounds expected when overlaid with other images.

3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks
involved when building Juno for AArch32 mode, the build option SPD needed to
specifed. This patch corrects this and also updates the documentation in the
user-guide.

4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As
a result the previous assumption that BL31 must be always present is removed
and the certificates for BL31 is only generated if `NEED_BL31` is defined.

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

show more ...

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 ...

Merge pull request #1145 from etienne-lms/rfc-armv7-2

Support ARMv7 architectures

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 #1165 from geesun/qx/support-sha512

Add support sha512 for hash algorithm

tbbr: Add build flag HASH_ALG to let the user to select the SHA

The flag support the following values:
- sha256 (default)
- sha384
- sha512

Change-Id: I7a49d858c361e993949cf6ada0a86575c

tbbr: Add build flag HASH_ALG to let the user to select the SHA

The flag support the following values:
- sha256 (default)
- sha384
- sha512

Change-Id: I7a49d858c361e993949cf6ada0a86575c3291066
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>

show more ...

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 ...

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 ...

ARMv7 may not support Generic Timer Extension

If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform
shall define ARMV7_SUPPORTS_GENERIC_TIMER to enable generic timer
support.

Signed-off-

ARMv7 may not support Generic Timer Extension

If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform
shall define ARMV7_SUPPORTS_GENERIC_TIMER to enable generic timer
support.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

ARMv7 may not support Virtualization Extensions

ARMv7-A Virtualization extensions brings new instructions and resources
that were supported by later architectures. Reference ARM ARM Issue C.c
[DDI04

ARMv7 may not support Virtualization Extensions

ARMv7-A Virtualization extensions brings new instructions and resources
that were supported by later architectures. Reference ARM ARM Issue C.c
[DDI0406C_C].

ERET and extended MSR/MRS instructions, as specified in [DDI0406C_C] in
ID_PFR1 description of bits[15:12] (Virtualization Extensions):
A value of 0b0001 implies implementation of the HVC, ERET, MRS
(Banked register), and MSR (Banked register) instructions. The ID_ISARs
do not identify whether these instructions are implemented.

UDIV/SDIV were introduced with the Virtualization extensions, even if
not strictly related to the virtualization extensions.

If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform
shall define ARMV7_SUPPORTS_VIRTUALIZATION to enable virtualization
extension related resources.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

ARMv7 may not support large page addressing

ARCH_SUPPORTS_LARGE_PAGE_ADDRESSING allows build environment to
handle specific case when target ARMv7 core only supports 32bit MMU
descriptor mode.

If A

ARMv7 may not support large page addressing

ARCH_SUPPORTS_LARGE_PAGE_ADDRESSING allows build environment to
handle specific case when target ARMv7 core only supports 32bit MMU
descriptor mode.

If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform
shall define ARMV7_SUPPORTS_LARGE_PAGE_ADDRESSING to enable
large page addressing support.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

ARMv7 target is driven by ARM_ARCH_MAJOR==7

External build environment shall sets directive ARM_ARCH_MAJOR to 7
to specify a target ARMv7-A core.

As ARM-TF expects AARCH to be set, ARM_ARCH_MAJOR==

ARMv7 target is driven by ARM_ARCH_MAJOR==7

External build environment shall sets directive ARM_ARCH_MAJOR to 7
to specify a target ARMv7-A core.

As ARM-TF expects AARCH to be set, ARM_ARCH_MAJOR==7 mandates
AARCH=aarch32.

The toolchain target architecture/cpu is delegated after the platform
configuration is parsed. Platform shall define target core through
ARM_CORTEX_A<x>=yes, <x> being 5, 7, 9, 12, 15 and/or 17.

Platform can bypass ARM_CORTEX_A<x>=yes directive and provide straight
the toolchain target directive through MARCH32_DIRECTIVE.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

show more ...

Build: introduce ${BUILD_PLAT} target to create the top build directory

Some platforms (for ex. UniPhier) want to create files in the very
top of the build directory. Add ${BUILD_PLAT} so such file

Build: introduce ${BUILD_PLAT} target to create the top build directory

Some platforms (for ex. UniPhier) want to create files in the very
top of the build directory. Add ${BUILD_PLAT} so such files can
depend on it.

Make existing directory targets depend on ${BUILD_PLAT} because
they are sub-directories of ${BUILD_PLAT}.

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

show more ...

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 ...

Makefile: Add ability to build dtb

This is a revamp of the original approach in:
https://github.com/ARM-software/arm-trusted-firmware/pull/747

Current build system has no means to automatically gen

Makefile: Add ability to build dtb

This is a revamp of the original approach in:
https://github.com/ARM-software/arm-trusted-firmware/pull/747

Current build system has no means to automatically generate dtbs from
dts, instead, stores the dtbs in the fdts/ folder. While this makes
perfect sense for many reference platforms, this becomes a minor
breakage in development flow for newer platforms.

However, this can be solved by providing a rule for the dtbs while
building the ATF binaries by purely describing which dts sources we
need.

For example, with this change, we will now be able to describe the
dtbs we need for the platform in the corresponding platform.mk file:
FDT_SOURCES += fdts/abc.dts

This should be able to generate the abc.dtb appropriately.

Since device trees are specification of hardware, we don't tie the rule
to any specific BL, instead a generic rule is introduced.

Further, this approach allows us to generate appropriate dtbs which may be
need to be regenerated when a common dtsi gets updated, by just
restricting changes to the dtsi alone, instead of synchronizing all the
dtbs as well.

If dtc is not available in default paths, but is available in an
alternate location, it can be chosen by overriding the DTC variable
such as 'make DTC=~/dtc/dtc ....`

NOTE: dtbs are built only with the explicit make dtbs command. The rule
is only available if the platform defines a FDT_SOURCES variable.

Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>

show more ...

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 #1040 from sliai/support-opteed-header

Support opteed header

Support Trusted OS firmware extra images in TF tools

Since Trusted OS firmware may have extra images, need to
assign new uuid and image id for them.
The TBBR chain of trust has been extended to add

Support Trusted OS firmware extra images in TF tools

Since Trusted OS firmware may have extra images, need to
assign new uuid and image id for them.
The TBBR chain of trust has been extended to add support
for the new images within the existing Trusted OS firmware
content certificate.

Change-Id: I678dac7ba1137e85c5779b05e0c4331134c10e06
Signed-off-by: Summer Qin <summer.qin@arm.com>

show more ...