Fix MISRA rule 8.4 Part 1

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 al

Fix MISRA rule 8.4 Part 1

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>

show more ...

Fix MISRA rule 8.4 in common code

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

Change-Id: I26e042cb251a6f9590afa1340fda

Fix MISRA rule 8.4 in common code

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>

show more ...

Fix MISRA rule 8.3 in common code

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

Change-Id: Iff384187c74a598a4e73f350a1893b60e9d16cec
Si

Fix MISRA rule 8.3 in common code

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>

show more ...

Dynamic cfg: MISRA fixes

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

ARM Platforms: Load HW_CONFIG in BL2

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`
propert

ARM Platforms: Load HW_CONFIG in BL2

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>

show more ...

Dynamic cfg: Introduce fdt wrappers

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

Dynamic cfg: Introduce fdt wrappers

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

show more ...

Add dynamic config image IDs

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

Dynamic cfg: Add HW and TB_FW configs to CoT

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

Change-Id: If7bb3e9be8a5e48be76614b35

Dynamic cfg: Add HW and TB_FW configs to CoT

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>

show more ...

Merge pull request #1173 from etienne-lms/armv7-qemu

support to boot OP-TEE on AArch32/Armv7+example with Cortex-A15/Qemu

aarch32: use lr as bl32 boot argument on aarch32 only systems

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

aarch32: use lr as bl32 boot argument on aarch32 only systems

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>

show more ...

image_decompress: add APIs for decompressing images

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

image_decompress_init():
This registers a temporary buffer and a decompressor

image_decompress: add APIs for decompressing images

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>

show more ...

Merge pull request #1228 from dp-arm/dp/cve_2017_5715

Workarounds for CVE-2017-5715 on A9/A15 and A17 + serial console reporting

Merge pull request #1193 from jwerner-chromium/JW_coreboot

New console API and coreboot support [v4]

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

Add BL2_AT_EL3 build option

sp_min: Implement workaround for CVE-2017-5715

This patch introduces two workarounds for ARMv7 systems. The
workarounds need to be applied prior to any `branch` instruction in
secure world. This i

sp_min: Implement workaround for CVE-2017-5715

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>

show more ...

Mark functions defined in assembly files

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

Mark functions defined in assembly files

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>

show more ...

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

Workaround for CVE-2017-5715 on Cortex A57 and A72

Invalidate the Branch Target Buffer (BTB) on entry to EL3 by disabling
and enabling the MMU. To achieve this without performing any branch
instruc

Workaround for CVE-2017-5715 on Cortex A57 and A72

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>

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

Unify cache flush code path after image load

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

Unify cache flush code path after image load

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>

show more ...

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

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

Support ARMv7 architectures

Refactor Statistical Profiling Extensions implementation

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

Refactor Statistical Profiling Extensions implementation

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>

show more ...

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