GitLab

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>

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>

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>

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>

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>

Since we use "?=" to set PLATFORM_ROOT, it is better to change the
name to be more special, or else it may be overridden by some
environment variables, such as in some CI build environments.
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>

This makes incremental builds work when the only change is to a definition
in a makefile. This version of the patch has been fixed to avoid depending
on the dependency makefiles that are generated at build time.

Fixes arm-software/tf-issues#551
Signed-off-by: Stephen Warren <swarren@nvidia.com>

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>

Seems to have unintended side-effects on the build system such as
rebuilding certain parts of TF even though nothing has changed.

This reverts commit c6f651f9

.

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

This patch makes some minor changes to `MAKE_DTBS` make macro
and adds `dtbs` target to the `all` make target.

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

This makes incremental builds work when the only change is to a
definition in a makefile.

Fixes arm-software/tf-issues#551
Signed-off-by: Stephen Warren <swarren@nvidia.com>

One typical usage of the pre-tool image filter is data compression,
and GZIP is one of the most commonly used compression methods.
I guess this is generic enough to be put in the common script instead
of platform.mk.

If you want to use this, you can add something like follows to your
platform.mk:

    BL32_PRE_TOOL_FILTER := GZIP
    BL33_PRE_TOOL_FILTER := GZIP
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

There are cases where we want to process images before they are
passed to cert_create / fiptool.

My main motivation is data compression.  By compressing images, we can
save data storage, and possibly speed up loading images.  The image
verification will also get faster because certificates are generated
based on compressed images.

Other image transformation filters (for ex. encryption), and their
combinations would be possible.  So, our build system should support
transformation filters in a generic manner.

The choice of applied filters is up to platforms (so specified in
platform.mk)

To define a new filter, <FILTER_NAME>_RULE and <FILTER_NAME>_SUFFIX
are needed.

For example, the GZIP compression filter can be implemented as follows:

------------------------>8------------------------
define GZIP_RULE
$(1): $(2)
        @echo "  GZIP    $$@"
        $(Q)gzip -n -f -9 $$< --stdout > $$@
endef

GZIP_SUFFIX := .gz
------------------------>8------------------------

The _RULE defines how to create the target $(1) from the source $(2).
The _SUFFIX defines the extension appended to the processed image path.
The suffix is not so important because the file name information is not
propagated to FIP, but adding a sensible suffix will be good to classify
the data file.

Platforms can specify which filter is applied to which BL image, like
this:

------------------------>8------------------------
BL32_PRE_TOOL_FILTER := GZIP
BL33_PRE_TOOL_FILTER := GZIP
------------------------>8------------------------

<IMAGE_NAME>_PRE_TOOL_FILTER specifies per-image filter.  With this,
different images can be transformed differently.  For the case above,
only BL32 and BL33 are GZIP-compressed.  Nothing is done for other
images.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

In the next commit, I need the image name in lowercase because
output files are generally named in lowercase.

Unfortunately, TOOL_ADD_IMG takes the first argument in uppercase
since we generally use uppercase Make variables.

make_helpers/build_macros.mk provides 'uppercase' macro to convert
a string into uppercase, but 'lowercase' does not exist.  We can
implement it if we like, but it would be more straightforward to
change the argument of TOOL_ADD_IMG.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The PHONY target "bl*" generate $(BIN) and $(DUMP), but host tools
(fiptool, cert_create) only need $(BIN).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The third argument was given "true" by images, but it was moved
to TOOL_ADD_PAYLOAD.  No more caller of CERT_ADD_CMD_OPT uses this.
So, the third argument is always empty.  Remove it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Now FIP_ADD_IMG takes care of both fiptool and cert_create
symmetrically.  Rename it so that it matches the behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Now FIP_ADD_PAYLOAD takes care of both fiptool and cert_create
symmetrically.  Rename it so that it matches the behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The fiptool and cert_create use the same command options for images.
It is pretty easy to handle both in the same, symmetrical way.

Move CRT_ARGS and CRT_DEPS to FIP_ADD_PAYLOAD.  This refactoring makes
sense because FIP_ADD_PAYLOAD is called from MAKE_BL (when building
images from source), and from FIP_ADD_IMG (when including external
images).  (FIP_ADD_PAYLOAD will be renamed later on since it now
caters to both fiptool and cert_create).

We can delete CERT_ADD_CMD_OPT for images in tbbr.mk.  It still
needs to call CERT_ADD_CMD_OPT directly for certificates.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The callers of these macros are supposed to use $(eval $(call, ...)).
The $(eval ...) on the callee side is unneeded.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The build system supports generating two FIP images, fip and fwu_fip.
Accordingly, we have similar build macros.

   FIP_ADD_PAYLOAD   <-->  FWU_FIP_ADD_PAYLOAD
   CERT_ADD_CMD_OPT  <-->  FWU_CERT_ADD_CMD_OPT
   FIP_ADD_IMG       <-->  FWU_FIP_ADD_IMG

The duplicated code increases the maintenance burden.  Also, the build
rule of BL2U looks clumsy - we want to call MAKE_BL to compile it from
source files, but we want to put it in fwu_fip.  We can not do it in a
single macro call since the current MAKE_BL does not support fwu_fip.

To refactor those in a clean way is to support one more argument to
specify the FIP prefix.  If it is empty, the images are targeted to
fip, whereas if the argument is "FWU_", targeted to fwu_fip.

The build macros prefixed with FWU_ go away.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Now, MAKE_TOOL_ARGS is only called from MAKE_BL.  Squash it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

check_* targets check if the required option are given, but do not
check the validity of the argument.  If the specified file does not
exist, let the build fail immediately instead of passing the invalid
file path to tools.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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>

It is better to not include BL2 in FIP when using `BL2 at EL3` as
platforms using this config would not have the capability to parse the
FIP format in Boot ROM and BL2 needs to be loaded independently. This
patch does the required changes for the same.

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

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>

check_* targets just check necessary command line argument, not
build any images.  They should be specified as .PHONY.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Commit 8f0617ef

 ("Apply TBBR naming convention to the fip_create
options") changed fiptool command options.  We often forget to update
documentation.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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>

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>

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>

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>

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>

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

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

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>

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>

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>

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>

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>

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>