Remove build option LOAD_IMAGE_V2

The code of LOAD_IMAGE_V2=0 has been removed.

Change-Id: Iea03e5bebb90c66889bdb23f85c07d0c9717fffe
Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Sig

Remove build option LOAD_IMAGE_V2

The code of LOAD_IMAGE_V2=0 has been removed.

Change-Id: Iea03e5bebb90c66889bdb23f85c07d0c9717fffe
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 #1535 from antonio-nino-diaz-arm/an/backtrace

Introduce backtrace function

Allow manually setting the AArch32 instruction set

At the moment the AArch32 instruction set isn't specified in the command
line, which means that the compiler is free to choose the one it sees
fit.

Allow manually setting the AArch32 instruction set

At the moment the AArch32 instruction set isn't specified in the command
line, which means that the compiler is free to choose the one it sees
fit. This decision may change between compiler versions, so it is better
to specify it manually.

The build option AARCH32_INSTRUCTION_SET has been introduced for this
reason. This option can be set to T32 or A32 to pass the correct flags
to the compiler.

The current behaviour is to default to T32 due to it's smaller size.

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

show more ...

Merge pull request #1533 from jeenu-arm/mpam

AArch64: Enable MPAM for lower ELs

AArch64: Enable MPAM for lower ELs

Memory Partitioning And Monitoring is an Armv8.4 feature that enables
various memory system components and resources to define partitions.
Software running at vari

AArch64: Enable MPAM for lower ELs

Memory Partitioning And Monitoring is an Armv8.4 feature that enables
various memory system components and resources to define partitions.
Software running at various ELs can then assign themselves to the
desired partition to control their performance aspects.

With this patch, when ENABLE_MPAM_FOR_LOWER_ELS is set to 1, EL3 allows
lower ELs to access their own MPAM registers without trapping to EL3.
This patch however doesn't make use of partitioning in EL3; platform
initialisation code should configure and use partitions in EL3 if
required.

Change-Id: I5a55b6771ccaa0c1cffc05543d2116b60cbbcdcd
Co-authored-by: James Morse <james.morse@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

show more ...

Merge pull request #1510 from robertovargas-arm/romlib

Add support for moving libraries to ROM

Add support for romlib in the build system

Romlib is a new image that is stored in ROM and contains the code of
several libraries that can be shared between different images. All
the functions withi

Add support for romlib in the build system

Romlib is a new image that is stored in ROM and contains the code of
several libraries that can be shared between different images. All
the functions within in the library are accessed using a jump table
which allows to update the romlib image whithout changing the binary
compatibility. This jump table can be also stored in RAM and it can
allow to patch a romlib with potential bugs fixes..

Change-Id: If980ccdaca24b7aaca900e32acc68baf6f94ab35
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

show more ...

Merge pull request #1386 from soby-mathew/sm/dyn_bl31

Extend dynamic configuration

Allow disabling authentication dynamically

This patch allows platforms to dynamically disable authentication of
images during cold boot. This capability is controlled via the
DYN_DISABLE_AUTH build

Allow disabling authentication dynamically

This patch allows platforms to dynamically disable authentication of
images during cold boot. This capability is controlled via the
DYN_DISABLE_AUTH build flag and is only meant for development
purposes.

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

show more ...

Merge pull request #1373 from jeenu-arm/ras-support

RAS support

RAS: Add fault injection support

The ARMv8.4 RAS extensions introduce architectural support for software
to inject faults into the system in order to test fault-handling
software. This patch introdu

RAS: Add fault injection support

The ARMv8.4 RAS extensions introduce architectural support for software
to inject faults into the system in order to test fault-handling
software. This patch introduces the build option FAULT_HANDLING_SUPPORT
to allow for lower ELs to use registers in the Standard Error Record to
inject fault. The build option RAS_EXTENSIONS must also be enabled along
with fault injection.

This feature is intended for testing purposes only, and is advisable to
keep disabled for production images.

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

show more ...

AArch64: Introduce RAS handling

RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional
extensions to base ARMv8.0 architecture.

This patch adds build system support to enable RAS feat

AArch64: Introduce RAS handling

RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional
extensions to base ARMv8.0 architecture.

This patch adds build system support to enable RAS features in ARM
Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for
this.

With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is
inserted at all EL3 vector entry and exit. ESBs will synchronize pending
external aborts before entering EL3, and therefore will contain and
attribute errors to lower EL execution. Any errors thus synchronized are
detected via. DISR_EL1 register.

When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1.

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

show more ...

AArch64: Introduce External Abort handling

At present, any External Abort routed to EL3 is reported as an unhandled
exception and cause a panic. This patch enables ARM Trusted Firmware to
handle Ext

AArch64: Introduce External Abort handling

At present, any External Abort routed to EL3 is reported as an unhandled
exception and cause a panic. This patch enables ARM Trusted Firmware to
handle External Aborts routed to EL3.

With this patch, when an External Abort is received at EL3, its handling
is delegated to plat_ea_handler() function. Platforms can provide their
own implementation of this function. This patch adds a weak definition
of the said function that prints out a message and just panics.

In order to support handling External Aborts at EL3, the build option
HANDLE_EA_EL3_FIRST must be set to 1.

Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to
compilation; this patch fixes that too.

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

show more ...

Merge pull request #1360 from antonio-nino-diaz-arm/an/smccc-v2

Add support for the SMC Calling Convention 2.0

Add support for the SMC Calling Convention 2.0

Due to differences in the bitfields of the SMC IDs, it is not possible
to support SMCCC 1.X and 2.0 at the same time.

The behaviour of `SMCCC_MAJOR_VE

Add support for the SMC Calling Convention 2.0

Due to differences in the bitfields of the SMC IDs, it is not possible
to support SMCCC 1.X and 2.0 at the same time.

The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build
option that specifies the major version of the SMCCC that the Trusted
Firmware supports. The only two allowed values are 1 and 2, and it
defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it.

Note: Support for SMCCC v2.0 is an experimental feature to enable
prototyping of secure partition specifications. Support for this
convention is disabled by default and could be removed without notice.

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

show more ...

Merge pull request #1328 from JiafeiPan/upstream-bl2-rom

Add support for BL2 in XIP memory

Add support for BL2 in XIP memory

In some use-cases BL2 will be stored in eXecute In Place (XIP) memory,
like BL1. In these use-cases, it is necessary to initialize the RW sections
in RAM, while lea

Add support for BL2 in XIP memory

In some use-cases BL2 will be stored in eXecute In Place (XIP) memory,
like BL1. In these use-cases, it is necessary to initialize the RW sections
in RAM, while leaving the RO sections in place. This patch enable this
use-case with a new build option, BL2_IN_XIP_MEM. For now, this option
is only supported when BL2_AT_EL3 is 1.

Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>

show more ...

Merge pull request #1292 from danh-arm/dh/spurious-dep-warn

Suppress spurious deprecated declaration warnings

Improve MULTI_CONSOLE_API deprecation warnings

For platforms that have not migrated to MULTI_CONSOLE_API == 1, there
are a lot of confusing deprecated declaration warnings relating to
use of console

Improve MULTI_CONSOLE_API deprecation warnings

For platforms that have not migrated to MULTI_CONSOLE_API == 1, there
are a lot of confusing deprecated declaration warnings relating to
use of console_init() and console_uninit(). Some of these relate to use
by the generic code, not the platform code. These functions are not really
deprecated but *removed* when MULTI_CONSOLE_API == 1.

This patch consolidates these warnings into a single preprocessor warning.
The __deprecated attribute is removed from the console_init() and
console_uninit() declarations.

For preprocessor warnings like this to not cause fatal build errors,
this patch adds -Wno-error=cpp to the build flags when
ERROR_DEPRECATED == 0.
This option (and -Wno-error=deprecated-declarations) is now added to
CPPFLAGS instead of TF_CFLAGS to ensure the build flags are used in the
assembler as well as the compiler.

This patch also disentangles the MULTI_CONSOLE_API and ERROR_DEPRECATED
build flags by defaulting MULTI_CONSOLE_API to 0 instead of
ERROR_DEPRECATED. This allows platforms that have not migrated to
MULTI_CONSOLE_API to use ERROR_DEPRECATED == 1 to emit a more meaningful
build error.

Finally, this patch bans use of MULTI_CONSOLE_API == 1 and AARCH32, since
the AArch32 console implementation does not support
MULTI_CONSOLE_API == 1.

Change-Id: If762165ddcb90c28aa7a4951aba70cb15c2b709c
Signed-off-by: Dan Handley <dan.handley@arm.com>

show more ...

Merge pull request #1193 from jwerner-chromium/JW_coreboot

New console API and coreboot support [v4]

Add platform-independent coreboot support library

This patch adds the foundation for a platform-independent coreboot
support library that can be shared by all platforms that boot BL31 from
coreboot

Add platform-independent coreboot support library

This patch adds the foundation for a platform-independent coreboot
support library that can be shared by all platforms that boot BL31 from
coreboot (acting as BL2). It adds code to parse the "coreboot table", a
data structure that coreboot uses to communicate different kinds of
information to later-stage firmware and certain OS drivers.

As a first small use case for this information, allow platforms to
access the serial console configuration used by coreboot, removing the
need to hardcode base address and divisors and allowing Trusted Firmware
to benefit from coreboot's user configuration (e.g. which UART to pick
and which baud rate to use).

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

show more ...

Merge pull request #1200 from robertovargas-arm/bl2-el3

Add BL2_AT_EL3 build option

bl2-el3: Add BL2_EL3 image

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly

bl2-el3: Add BL2_EL3 image

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL
stages without need for BL1. This is not currently possible because
BL2 executes at S-EL1 and cannot jump straight to EL3.

Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

show more ...

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