GitLab

This patch adds an optional API to the platform port:

    void plat_error_handler(int err) __dead2;

The platform error handler is called when there is a specific error
condition after which Trusted Firmware cannot continue. While panic()
simply prints the crash report (if enabled) and spins, the platform
error handler can be used to hand control over to the platform port
so it can perform specific bookeeping or post-error actions (for
example, reset the system). This function must not return.

The parameter indicates the type of error using standard codes from
errno.h. Possible errors reported by the generic code are:

    -EAUTH  : a certificate or image could not be authenticated
              (when Trusted Board Boot is enabled)
    -ENOENT : the requested image or certificate could not be found
              or an IO error was detected
    -ENOMEM : resources exhausted. Trusted Firmware does not use
              dynamic memory, so this error is usually an indication
              of an incorrect array size

A default weak implementation of this function has been provided.
It simply implements an infinite loop.

Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3

This patch adds an optional API to the platform port:

    void bl1_plat_prepare_exit(void);

This function is called prior to exiting BL1 in response to the
RUN_IMAGE_SMC request raised by BL2. It should be used to perform
platform specific clean up or bookkeeping operations before
transferring control to the next image.

A weak empty definition of this function has been provided to
preserve platform backwards compatibility.

Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1

The AArch64 synchronous exception vector code in BL1 is almost
reaching its architectural limit of 32 instructions. This means
there is very little space for this code to grow.

This patch reduces the size of the exception vector code by
moving most of its code in a function to which we branch from
SynchronousExceptionA64.

Change-Id: Ib35351767a685fb2c2398029d32e54026194f7ed

BL2 loads secure runtime code(BL3-1, BL3-2) and hence it has to
run in secure world otherwise BL3-1/BL3-2 have to execute from
non-secure memory. Hence, This patch removes the change_security_state()
call in bl1_run_bl2() and replaces it with an assert to confirm
the BL2 as secure.

Fixes ARM-software/tf-issues#314

Change-Id: I611b83f5c4090e58a76a2e950b0d797b46df3c29

This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto module and the image parser module to
authenticate the images in the Chain of Trust.

A new function 'load_auth_image()' has been implemented. When TBB
is enabled, this function will call the authentication module to
authenticate parent images following the CoT up to the root of
trust to finally load and authenticate the requested image.

The platform is responsible for picking up the right makefiles to
build the corresponding cryptographic and image parser libraries.
ARM platforms use the mbedTLS based libraries.

The platform may also specify what key algorithm should be used
to sign the certificates. This is done by declaring the 'KEY_ALG'
variable in the platform makefile. FVP and Juno use ECDSA keys.

On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
each to accommodate the ECDSA code.

REMOVED BUILD OPTIONS:

  * 'AUTH_MOD'

Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867

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

The validation of the caching enable state in bl1_main() was
incorrect resulting in the state not being checked. Using the right
operator fixes this.

Change-Id: I2a99478f420281a1dcdf365d3d4fd8394cd21b51

This patch introduces a new platform build option, called
PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
a programmable or fixed reset vector address.

If the reset vector address is fixed then the code relies on the
platform_get_entrypoint() mailbox mechanism to figure out where
it is supposed to jump. On the other hand, if it is programmable
then it is assumed that the platform code will program directly
the right address into the RVBAR register (instead of using the
mailbox redirection) so the mailbox is ignored in this case.

Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308

The attempt to run the CPU reset code as soon as possible after reset
results in highly complex conditional code relating to the
RESET_TO_BL31 option.

This patch relaxes this requirement a little. In the BL1, BL3-1 and
PSCI entrypoints code, the sequence of operations is now as follows:
 1) Detect whether it is a cold or warm boot;
 2) For cold boot, detect whether it is the primary or a secondary
    CPU. This is needed to handle multiple CPUs entering cold reset
    simultaneously;
 3) Run the CPU init code.

This patch also abstracts the EL3 registers initialisation done by
the BL1, BL3-1 and PSCI entrypoints into common code.

This improves code re-use and consolidates the code flows for
different types of systems.

NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
OTHERWISE, SECONDARY CPUS WILL PANIC.

Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546

The required platform constant PLATFORM_CACHE_LINE_SIZE is
unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
same information. CACHE_WRITEBACK_GRANULE is preferred since this
is an architecturally defined term and allows comparison with the
corresponding hardware register value.

Replace all usage of PLATFORM_CACHE_LINE_SIZE with
CACHE_WRITEBACK_GRANULE.

Also, add a runtime assert in BL1 to check that the provided
CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.

Change-Id: If87286be78068424217b9f3689be358356500dcd

In order for the symbol table in the ELF file to contain the size of
functions written in assembly, it is necessary to report it to the
assembler using the .size directive.

To fulfil the above requirements, this patch introduces an 'endfunc'
macro which contains the .endfunc and .size directives. It also adds
a .func directive to the 'func' assembler macro.

The .func/.endfunc have been used so the assembler can fail if
endfunc is omitted.

Fixes ARM-Software/tf-issues#295

Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
Signed-off-by: Kévin Petit <kevin.petit@arm.com>

This patch adds support to authenticate the BL2 content certificate
and image using the authentication module in BL1.

The FIP driver has been extended to include the BL2 certificate
UUID.

FVP and Juno ports include the BL2 certificate FIP file
definition.

Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325

This patch extends the build option `USE_COHERENT_MEMORY` to
conditionally remove coherent memory from the memory maps of
all boot loader stages. The patch also adds necessary
documentation for coherent memory removal in firmware-design,
porting and user guides.

Fixes ARM-Software/tf-issues#106

Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773

This patch fixes the incorrect value of the LENGTH attribute in
the linker scripts. This attribute must define the memory size, not
the limit address.

Fixes ARM-software/tf-issues#252

Change-Id: I328c38b9ec502debe12046a8912d7dfc54610c46

This patch gathers miscellaneous minor fixes to the documentation, and comments
in the source code.

Change-Id: I631e3dda5abafa2d90f464edaee069a1e58b751b
Co-Authored-By: Soby Mathew <soby.mathew@arm.com>
Co-Authored-By: Dan Handley <dan.handley@arm.com>

This patch introduces a framework which will allow CPUs to perform
implementation defined actions after a CPU reset, during a CPU or cluster power
down, and when a crash occurs. CPU specific reset handlers have been implemented
in this patch. Other handlers will be implemented in subsequent patches.

Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/.

Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956

This patch disables routing of external aborts from lower exception levels to
EL3 and ensures that a SError interrupt generated as a result of execution in
EL3 is taken locally instead of a lower exception level.

The SError interrupt is enabled in the TSP code only when the operation has not
been directly initiated by the normal world. This is to prevent the possibility
of an asynchronous external abort which originated in normal world from being
taken when execution is in S-EL1.

Fixes ARM-software/tf-issues#153

Change-Id: I157b996c75996d12fd86d27e98bc73dd8bce6cd5

Fix the following issues with the console log output:

* Make sure the welcome string is the first thing in the log output
(during normal boot).
* Prefix each message with the BL image name so it's clear which
BL the output is coming from.
* Ensure all output is wrapped in one of the log output macros so it can
be easily compiled out if necessary. Change some of the INFO() messages
to VERBOSE(), especially in the TSP.
* Create some extra NOTICE() and INFO() messages during cold boot.
* Remove all usage of \r in log output.

Fixes ARM-software/tf-issues#231

Change-Id: Ib24f7acb36ce64bbba549f204b9cde2dbb46c8a3

Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM

BLn_BASE and BLn_LIMIT definitions have been updated and are based on
these new memory regions.

The available memory for each bootloader in the linker script is
defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
region.

TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
the platform porting.

FVP common definitions are defined in fvp_def.h while platform_def.h
contains exclusively (with a few exceptions) the definitions that are
mandatory in the porting guide. Therefore, platform_def.h now includes
fvp_def.h instead of the other way around.

Porting guide has been updated to reflect these changes.

Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05

This patch reworks the manner in which the M,A, C, SA, I, WXN & EE bits of
SCTLR_EL3 & SCTLR_EL1 are managed. The EE bit is cleared immediately after reset
in EL3. The I, A and SA bits are set next in EL3 and immediately upon entry in
S-EL1. These bits are no longer managed in the blX_arch_setup() functions. They
do not have to be saved and restored either. The M, WXN and optionally the C
bit are set in the enable_mmu_elX() function. This is done during both the warm
and cold boot paths.

Fixes ARM-software/tf-issues#226

Change-Id: Ie894d1a07b8697c116960d858cd138c50bc7a069

Print out Trusted Firmware version at runtime at each BL stage.
Message consists of TF version as defined statically in the Makefile
(e.g. v0.4), build mode (debug|release) and a customizable build
string:

  1. By defining BUILD_STRING in command line when building TF
  2. Default string is git commit ID
  3. Empty if git meta-data is not available

Fixes ARM-software/tf-issues#203

Change-Id: I5c5ba438f66ab68810427d76b49c5b9177a957d6

This patch implements a "tf_printf" which supports only the commonly
used format specifiers in Trusted Firmware, which uses a lot less
stack space than the stdlib printf function.

Fixes ARM-software/tf-issues#116

Change-Id: I7dfa1944f4c1e634b3e2d571f49afe02d109a351

This patch reworks the cold boot path across the BL1, BL2, BL3-1 and BL3-2 boot
loader stages to not use stacks allocated in coherent memory for early platform
setup and enabling the MMU. Stacks allocated in normal memory are used instead.

Attributes for stack memory change from nGnRnE when the MMU is disabled to
Normal WBWA Inner-shareable when the MMU and data cache are enabled. It is
possible for the CPU to read stale stack memory after the MMU is enabled from
another CPUs cache. Hence, it is unsafe to turn on the MMU and data cache while
using normal stacks when multiple CPUs are a part of the same coherency
domain. It is safe to do so in the cold boot path as only the primary cpu
executes it. The secondary cpus are in a quiescent state.

This patch does not remove the allocation of coherent stack memory. That is done
in a subsequent patch.

Change-Id: I12c80b7c7ab23506d425c5b3a8a7de693498f830

This concept is no longer required since we now support loading of
images at fixed addresses only.

The image loader now automatically detects the position of the image
inside the current memory layout and updates the layout such that
memory fragmentation is minimised.

The 'attr' field of the meminfo data structure, which used to hold
the bottom/top loading information, has been removed. Also the 'next'
field has been removed as it wasn't used anywhere.

The 'init_bl2_mem_layout()' function has been moved out of common
code and put in BL1-specific code. It has also been renamed into
'bl1_init_bl2_mem_layout'.

Fixes ARM-software/tf-issues#109

Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d

Exclude stdlib files because they do not follow kernel code style.

Fixes ARM-software/tf-issues#73

Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab

This patch reworks FVP specific code responsible for determining
the entry point information for BL3-2 and BL3-3 stages when BL3-1
is configured as the reset handler.

Change-Id: Ia661ff0a6a44c7aabb0b6c1684b2e8d3642d11ec

Consolidate all BL3-1 CPU context initialization for cold boot, PSCI
and SPDs into two functions:
*  The first uses entry_point_info to initialize the relevant
   cpu_context for first entry into a lower exception level on a CPU
*  The second populates the EL1 and EL2 system registers as needed
   from the cpu_context to ensure correct entry into the lower EL

This patch alters the way that BL3-1 determines which exception level
is used when first entering EL1 or EL2 during cold boot - this is now
fully determined by the SPSR value in the entry_point_info for BL3-3,
as set up by the platform code in BL2 (or otherwise provided to BL3-1).

In the situation that EL1 (or svc mode) is selected for a processor
that supports EL2, the context management code will now configure all
essential EL2 register state to ensure correct execution of EL1. This
allows the platform code to run non-secure EL1 payloads directly
without requiring a small EL2 stub or OS loader.

Change-Id: If9fbb2417e82d2226e47568203d5a369f39d3b0f

Some platform porting functions were in BL specific header files.
These have been moved to platform.h so that all porting functions
are in the same place. The functions are now grouped by BL.
Obsolete BL headers files have been removed.

Also, the weak declaration of the init_bl2_mem_layout() function
has been moved out the header file and into the source file
(bl_common.c) using the more succinct #pragma syntax. This
mitigates the risk of 2 weak definitions being created and the
wrong one being picked up by the compiler.

Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83

Previously, platform.h contained many declarations and definitions
used for different purposes. This file has been split so that:

* Platform definitions used by common code that must be defined
  by the platform are now in platform_def.h. The exact include
  path is exported through $PLAT_INCLUDES in the platform makefile.

* Platform definitions specific to the FVP platform are now in
  /plat/fvp/fvp_def.h.

* Platform API declarations specific to the FVP platform are now
  in /plat/fvp/fvp_private.h.

* The remaining platform API declarations that must be ported by
  each platform are still in platform.h but this file has been
  moved to /include/plat/common since this can be shared by all
  platforms.

Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a

Function declarations implicitly have external linkage so do not
need the extern keyword.

Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32

Currently the platform code gets to define the base address of each
boot loader image. However, the linker scripts couteract this
flexibility by enforcing a fixed overall layout of the different
images. For example, they require that the BL3-1 image sits below
the BL2 image. Choosing BL3-1 and BL2 base addresses in such a way
that it violates this constraint makes the build fail at link-time.

This patch requires the platform code to now define a limit address
for each image. The linker scripts check that the image fits within
these bounds so they don't rely anymore on the position of a given
image in regard to the others.

Fixes ARM-software/tf-issues#163

Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c

BL1 RO and RW base address used to be fixed, respectively to the first
address of the Trusted ROM and the first address of the Trusted RAM.

Introduce new platform defines to configure the BL1 RO and RW base
addresses.

Change-Id: If26616513a47798593a4bb845a4b0fb37c867cd6

This change adds optional reset vector support to BL3-1
which means BL3-1 entry point can detect cold/warm boot,
initialise primary cpu, set up cci and mail box.

When using BL3-1 as a reset vector it is assumed that
the BL3-1 platform code can determine the location of
the BL3-2 images, or load them as there are no parameters
that can be passed to BL3-1 at reset.

It also fixes the incorrect initialisation of mailbox
registers on the FVP platform

This feature can be enabled by building the code with
make variable RESET_TO_BL31 set as 1

Fixes ARM-software/TF-issues#133
Fixes ARM-software/TF-issues#20

Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570

This patch is based on spec published at
https://github.com/ARM-software/tf-issues/issues/133

It rearranges the bl31_args struct into
bl31_params and bl31_plat_params which provide the
information needed for Trusted firmware and platform
specific data via x0 and x1

On the FVP platform BL3-1 params and BL3-1 plat params
and its constituents are stored at the start of TZDRAM.

The information about memory availability and size for
BL3-1, BL3-2 and BL3-3 is moved into platform specific data.

Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9

This patch reworks the handover interface from: BL1 to BL2 and
BL2 to BL3-1. It removes the raise_el(), change_el(), drop_el()
and run_image() functions as they catered for code paths that were
never exercised.
BL1 calls bl1_run_bl2() to jump into BL2 instead of doing the same
by calling run_image(). Similarly, BL2 issues the SMC to transfer
execution to BL3-1 through BL1 directly. Only x0 and x1 are used
to pass arguments to BL31. These arguments and parameters for
running BL3-1 are passed through a reference to a
'el_change_info_t' structure. They were being passed value in
general purpose registers earlier.

Change-Id: Id4fd019a19a9595de063766d4a66295a2c9307e1

This patch introduces macros (SPSR_64 and SPSR_32) to
create a SPSR for both aarch32 and aarch64 execution
states. These macros allow the user to set fields
in the SPSR depending upon its format.
The make_spsr() function which did not allow
manipulation of all the fields in the aarch32 SPSR
has been replaced by these new macros.

Change-Id: I9425dda0923e8d5f03d03ddb8fa0e28392c4c61e

Instead of using the system register helper functions to read
or write system registers, assembler coded functions should
use MRS/MSR instructions. This results in faster and more
compact code.

This change replaces all usage of the helper functions with
direct register accesses.

Change-Id: I791d5f11f257010bb3e6a72c6c5ab8779f1982b3

disable_mmu() cannot work as a C function as there is no control
over data accesses generated by the compiler between disabling and
cleaning the data cache. This results in reading stale data from
main memory.

As assembler version is provided for EL3, and a variant that also
disables the instruction cache which is now used by the BL1
exception handling function.

Fixes ARM-software/tf-issues#147

Change-Id: I0cf394d2579a125a23c2f2989c2e92ace6ddb1a6

The current code does not always use data and instruction
barriers as required by the architecture and frequently uses
barriers excessively due to their inclusion in all of the
write_*() helper functions.

Barriers should be used explicitly in assembler or C code
when modifying processor state that requires the barriers in
order to enable review of correctness of the code.

This patch removes the barriers from the helper functions and
introduces them as necessary elsewhere in the code.

PORTING NOTE: check any port of Trusted Firmware for use of
system register helper functions for reliance on the previous
barrier behaviour and add explicit barriers as necessary.

Fixes ARM-software/tf-issues#92

Change-Id: Ie63e187404ff10e0bdcb39292dd9066cb84c53bf