GitLab

Conflict with function name and variable name within that function.
Change the name of the function from image_size to get_image_size
to remove conflict and make the function fit the normal project
naming convention.

Rule 5.3:  An identifier declared in an inner scope shall not
           hide an identifier declared in an outer scope

Fixed For:
    make LOG_LEVEL=50 PLAT=fvp

Change-Id: I1a63d2730113e2741fffa79730459c584b0224d7
Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>

File: include/common/aarch64/el3_common_macros.S

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

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>

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>

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>

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

Rule 8.3: All declarations of an object or function shall
          use the same names and type qualifiers

Fixed for:
	make DEBUG=1 PLAT=fvp SPD=tspd TRUSTED_BOARD_BOOT=1 \
	     GENERATE_COT=1 ARM_ROTPK_LOCATION=devel_rsa \
	     ROT_KEY=arm_rotprivk_rsa.pem MBEDTLS_DIR=mbedtls all

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

For the adr instruction, it require the label's offset from the
address of this instruction must be in the range +/-1MB. If the
option "BL2_IN_XIP_MEM" is set to '1', in some cases, BL2's RW
memory will not in the range of +/-1MB from BL2's RO memory region.
so we need to use ldr instruction to cover this case.
Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.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>

Void pointers have been used to access linker symbols, by declaring an
extern pointer, then taking the address of it. This limits symbols
values to aligned pointer values. To remove this restriction an
IMPORT_SYM macro has been introduced, which declares it as a char
pointer and casts it to the required type.

Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
Signed-off-by: Joel Hutton <Joel.Hutton@Arm.com>

When the source code says 'SMCC' it is talking about the SMC Calling
Convention. The correct acronym is SMCCC. This affects a few definitions
and file names.

Some files have been renamed (smcc.h, smcc_helpers.h and smcc_macros.S)
but the old files have been kept for compatibility, they include the
new ones with an ERROR_DEPRECATED guard.

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

Rule 8.4: A compatible declaration shall be visible when
          an object or function with external linkage is defined

Fixed for:
	make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all

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

Rule 8.4: A compatible declaration shall be visible when
          an object or function with external linkage is defined.

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

Rule 8.3: All declarations of an object or function shall
          use the same names and type qualifiers.

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

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

The patch adds the necessary changes to load HW_CONFIG in BL2 for
ARM Platforms :

1. The load address of HW_CONFIG is specified via the `hw_config_addr`
property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size`
property defines the maximum size to be expected for the HW_CONFIG.
The `arm_dyn_cfg_helpers.c` and corresponding header implements
utility functions to parse these DT properties defined.
The `arm_dyn_cfg.c` implements wrappers to these helpers to enable
them to be invoked from ARM platform layer.

2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is
the list of images to be loaded by BL2.

3. The `libfdt` sources are now included when BL2 is built

4. A new helper `populate_next_bl_params_config()` is introduced in
desc_image_load.c to populate the subsequent executable BL images
with the `hw_config` and the corresponding `fw_config` if available.
The `plat_get_next_bl_params()` API for ARM platforms is modified to
invoke this new helper.

5. The implementation of `bl2_early_platform_setup2()` is modified to
consider `arg0` as well in addition to `arg1` passed from BL1.

6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt.

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

Change-Id: I9b1cdaf2430a1998a69aa366ea1461224a3d43dc
Co-Authoured-by: Jeenu Viswambharan <Jeenu.Viswambharan@arm.com>
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

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

This patch adds image IDs to `hw_config` and `tb_fw_config` and
includes them in the default Chain Of Trust (CoT).

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

Add 'lr_svc' as a boot parameter in AArch32 bl1. This is used by Optee
and Trusty to get the non-secure entry point on AArch32 platforms.

This change is not ported in AArch64 mode where the BL31, not BL32,
is in charge of booting the non secure image (BL33).
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

These APIs are used by platforms that need to decompress images.

image_decompress_init():
  This registers a temporary buffer and a decompressor callback.
  This should be called from platform init code.

image_decompress_prepare():
  This should be called before each compressed image is loaded.  The
  best location to call this will be bl*_plat_handle_pre_image_load().

image_decompress():
  This should be called after each compressed image is loaded.  The
  best location to call this will be bl*_plat_handle_post_image_load().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This patch introduces two workarounds for ARMv7 systems.  The
workarounds need to be applied prior to any `branch` instruction in
secure world.  This is achieved using a custom vector table where each
entry is an `add sp, sp, #1` instruction.

On entry to monitor mode, once the sequence of `ADD` instructions is
executed, the branch target buffer (BTB) is invalidated.  The bottom
bits of `SP` are then used to decode the exception entry type.

A side effect of this change is that the exception vectors are
installed before the CPU specific reset function.  This is now
consistent with how it is done on AArch64.

Note, on AArch32 systems, the exception vectors are typically tightly
integrated with the secure payload (e.g. the Trusted OS).  This
workaround will need porting to each secure payload that requires it.

The patch to modify the AArch32 per-cpu vbar to the corresponding
workaround vector table according to the CPU type will be done in a
later patch.

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

This patch change the name of the section containing the functions
defined in assembly files from text.* to text.asm.*. This change
makes possible to select in the linker script the functions
defined in those files.

Change-Id: If35e44ef1b43ffd951dfac5e052db75d7198e2e0
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>

Invalidate the Branch Target Buffer (BTB) on entry to EL3 by disabling
and enabling the MMU.  To achieve this without performing any branch
instruction, a per-cpu vbar is installed which executes the workaround
and then branches off to the corresponding vector entry in the main
vector table.  A side effect of this change is that the main vbar is
configured before any reset handling.  This is to allow the per-cpu
reset function to override the vbar setting.

This workaround is enabled by default on the affected CPUs.

Change-Id: I97788d38463a5840a410e3cea85ed297a1678265
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.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>

Previously the cache flush happened in 2 different places in code
depending on whether TRUSTED_BOARD_BOOT is enabled or not. This
patch unifies this code path for both the cases. The `load_image()`
function is now made an internal static function.

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

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>

Factor out SPE operations in a separate file.  Use the publish
subscribe framework to drain the SPE buffers before entering secure
world.  Additionally, enable SPE before entering normal world.

A side effect of this change is that the profiling buffers are now
only drained when a transition from normal world to secure world
happens.  Previously they were drained also on return from secure
world, which is unnecessary as SPE is not supported in S-EL1.

Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@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>

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>

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

Also need to add a SEV instruction in ARMv7 spin_unlock which
is implicit in ARMv8.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

The GIC driver initialization currently allows an array of interrupts to
be configured as secure. Future use cases would require more interrupt
configuration other than just security, such as priority.

This patch introduces a new interrupt property array as part of both
GICv2 and GICv3 driver data. The platform can populate the array with
interrupt numbers and respective properties. The corresponding driver
initialization iterates through the array, and applies interrupt
configuration as required.

This capability, and the current way of supplying array (or arrays, in
case of GICv3) of secure interrupts, are however mutually exclusive.
Henceforth, the platform should supply either:

  - A list of interrupts to be mapped as secure (the current way).
    Platforms that do this will continue working as they were. With this
    patch, this scheme is deprecated.

  - A list of interrupt properties (properties include interrupt group).
    Individual interrupt properties are specified via. descriptors of
    type 'interrupt_prop_desc_t', which can be populated with the macro
    INTR_PROP_DESC().

A run time assert checks that the platform doesn't specify both.

Henceforth the old scheme of providing list of secure interrupts is
deprecated. When built with ERROR_DEPRECATED=1, GIC drivers will require
that the interrupt properties are supplied instead of an array of secure
interrupts.

Add a section to firmware design about configuring secure interrupts.

Fixes ARM-software/tf-issues#262

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

This patch gives users control over logging messages printed from the C
code using the LOG macros defined in debug.h Users now have the ability
to reduce the log_level at run time using the tf_log_set_max_level()
function. The default prefix string can be defined by platform by
overriding the `plat_log_get_prefix()` platform API which is also
introduced in this patch.

The new log framework results in saving of some RO data. For example,
when BL1 is built for FVP with LOG_LEVEL=LOG_LEVEL_VERBOSE, resulted
in saving 384 bytes of RO data and increase of 8 bytes of RW data. The
framework also adds about 108 bytes of code to the release build of FVP.

Fixes ARM-software/tf-issues#462

Change-Id: I476013d9c3deedfdd4c8b0b0f125665ba6250554
Co-authored-by: Eleanor Bonnici <Eleanor.bonnici@arm.com>
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

This patch introduces tf_vprintf() and tf_string_print() APIs
which is needed by the logging framework introduced in a later
patch.

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

Platform may use specific cache line sizes. Since CACHE_WRITEBACK_GRANULE
defines the platform specific cache line size, it is used to define the
size of the cpu data structure CPU_DATA_SIZE aligned on cache line size.

Introduce assembly macro 'mov_imm' for AArch32 to simplify implementation
of function '_cpu_data_by_index'.

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

Add Call Frame Information assembler directives to vector entries so
that debuggers display the backtrace of functions that triggered a
synchronous exception. For example, a function triggering a data abort
will be easier to debug if the backtrace can be displayed from a
breakpoint at the beginning of the synchronous exception vector.

DS-5 needs CFI otherwise it will not attempt to display the backtrace.
Other debuggers might have other needs. These debug information are
stored in the ELF file but not in the final binary.

Change-Id: I32dc4e4b7af02546c93c1a45c71a1f6d710d36b1
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Assembly routines are usually defined by using "func" and "endfunc":

    func foo
      ...
    endfunc foo

Currently, the "func" macro does not specify ".align" directive
by default.  It causes unaligned instruction under some circumstances.

As far as I tested, this problem happens for GCC 5 or older.  It did
not happen for GCC 6 or newer.  Taking into account that GCC 4.x / 5.x
is still used, make sure that assembly code is at least 4 byte aligned.

[ How to reproduce the problem ]

For example, use GCC 5.3 downloaded from Linaro:
http://releases.linaro.org/components/toolchain/binaries/5.3-2016.05/
aarch64-linux-gnu/gcc-linaro-5.3.1-2016.05-x86_64_aarch64-linux-gnu.tar.xz

Expand mbedtls-2.4.2 to the current directory.

Try the following:

  $ git log --oneline -1
  77544efb

 Merge pull request #1071 from jeenu-arm/syntax-fix
  $ aarch64-linux-gnu-gcc --version | head -1
  aarch64-linux-gnu-gcc (Linaro GCC 5.3-2016.05) 5.3.1 20160412
  $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=uniphier \
    TRUSTED_BOARD_BOOT=1 MBEDTLS_DIR=mbedtls-2.4.2
    ( snip build log )
  $ aarch64-linux-gnu-nm build/uniphier/release/bl1/bl1.elf | grep handler
  00000000800088f4 T bl1_fwu_smc_handler
  00000000800084c8 T bl1_smc_handler
  000000008000a6e0 t _panic_handler
  000000008000a8e0 W plat_error_handler
  000000008000a8e8 W plat_panic_handler
  000000008000a8d8 W plat_reset_handler
  000000008000a39f T reset_handler
  000000008000a367 t smc_handler
  000000008000a2ef t smc_handler64

You will notice "smc_handler64", "reset_handler", etc. are not properly
aligned.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Assembler programmers are used to being able to define functions with a
specific aligment with a pattern like this:

    .align X
  myfunction:

However, this pattern is subtly broken when instead of a direct label
like 'myfunction:', you use the 'func myfunction' macro that's standard
in Trusted Firmware. Since the func macro declares a new section for the
function, the .align directive written above it actually applies to the
*previous* section in the assembly file, and the function it was
supposed to apply to is linked with default alignment.

An extreme case can be seen in Rockchip's plat_helpers.S which contains
this code:

  [...]
  endfunc plat_crash_console_putc

  .align 16
  func platform_cpu_warmboot
  [...]

This assembles into the following plat_helpers.o:

  Sections:
  Idx Name                             Size  [...]  Algn
   9 .text.plat_crash_console_putc 00010000  [...]  2**16
  10 .text.platform_cpu_warmboot   00000080  [...]  2**3

As can be seen, the *previous* function actually got the alignment
constraint, and it is also 64KB big even though it contains only two
instructions, because the .align directive at the end of its section
forces the assembler to insert a giant sled of NOPs. The function we
actually wanted to align has the default constraint. This code only
works at all because the linker just happens to put the two functions
right behind each other when linking the final image, and since the end
of plat_crash_console_putc is aligned the start of platform_cpu_warmboot
will also be. But it still wastes almost 64KB of image space
unnecessarily, and it will break under certain circumstances (e.g. if
the plat_crash_console_putc function becomes unused and its section gets
garbage-collected out).

There's no real way to fix this with the existing func macro. Code like

 func myfunc
 .align X

happens to do the right thing, but is still not really correct code
(because the function label is inserted before the .align directive, so
the assembler is technically allowed to insert padding at the beginning
of the function which would then get executed as instructions if the
function was called). Therefore, this patch adds a new parameter with a
default value to the func macro that allows overriding its alignment.

Also fix up all existing instances of this dangerous antipattern.

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