Merge pull request #443 from achingupta/sb/el3_payloads-cb_single_cpu

Add support to boot EL3 payloads and only a single CPU at cold reset

Introduce COLD_BOOT_SINGLE_CPU build option

This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
which allows platforms that only release a single CPU out of reset to
slightly optimi

Introduce COLD_BOOT_SINGLE_CPU build option

This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
which allows platforms that only release a single CPU out of reset to
slightly optimise their cold boot code, both in terms of code size
and performance.

COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform
may release several CPUs out of reset. In this case, the cold reset
code needs to coordinate all CPUs via the usual primary/secondary
CPU distinction.

If a platform guarantees that only a single CPU will ever be released
out of reset, there is no need to arbitrate execution ; the notion of
primary and secondary CPUs itself no longer exists. Such platforms
may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the
primary/secondary CPU identification in the cold reset code.

All ARM standard platforms can release several CPUs out of reset
so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like
Juno, bringing up more than one CPU at reset should only be attempted
when booting an EL3 payload, as it is not fully supported in the
normal boot flow.

For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform
APIs become optional:
- plat_secondary_cold_boot_setup();
- plat_is_my_cpu_primary().
The Porting Guide has been updated to reflect that.

User Guide updated as well.

Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b

show more ...

CSS: Enable booting of EL3 payloads

This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the

CSS: Enable booting of EL3 payloads

This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.

Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.

The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.

The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.

The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.

This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.

Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077

show more ...

Introduce SPIN_ON_BL1_EXIT build flag

This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which
puts an infinite loop in BL1. It is intended to help debugging
the post-BL2 phase of the Trusted

Introduce SPIN_ON_BL1_EXIT build flag

This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which
puts an infinite loop in BL1. It is intended to help debugging
the post-BL2 phase of the Trusted Firmware by stopping execution
in BL1 just before handing over to BL31. At this point, the
developer may take control of the target using a debugger.

This feature is disabled by default and can be enabled by
rebuilding BL1 with SPIN_ON_BL1_EXIT=1.

User Guide updated accordingly.

Change-Id: I6b6779d5949c9e5571dd371255520ef1ac39685c

show more ...

Merge pull request #438 from soby-mathew/sm/error_deprecate

Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED

Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED

This patch changes the build time behaviour when using deprecated API within
Trusted Firmware. Previously the use of deprecated APIs would o

Replace build macro WARN_DEPRECATED with ERROR_DEPRECATED

This patch changes the build time behaviour when using deprecated API within
Trusted Firmware. Previously the use of deprecated APIs would only trigger a
build warning (which was always treated as a build error), when
WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always
trigger a build time warning. Whether this warning is treated as error or not
is determined by the build flag ERROR_DEPRECATED which is disabled by default.
When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or
inclusion of deprecated headers will result in a build error.

Also the deprecated context management helpers in context_mgmt.c are now
conditionally compiled depending on the value of ERROR_DEPRECATED flag
so that the APIs themselves do not result in a build error when the
ERROR_DEPRECATED flag is set.

NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to
using ERROR_DEPRECATED, otherwise deprecated API usage will no longer
trigger a build error.

Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a

show more ...

Merge pull request #430 from jcastillo-arm/jc/tf-issues/333

Fix build error when `BL32` is not defined

Fix build error when `BL32` is not defined

If an SPD wants to use a prebuilt binary as BL32 image (for example,
the OPTEE Dispatcher), it must point the `BL32` variable to the
image file. This depen

Fix build error when `BL32` is not defined

If an SPD wants to use a prebuilt binary as BL32 image (for example,
the OPTEE Dispatcher), it must point the `BL32` variable to the
image file. This dependency should apply only to the `fip` target.
However, it also applies to the `all` target at the moment. If the
user tries to build all individual TF images using `make all`
without setting BL32, the build fails. The following command will
throw the error:

make CROSS_COMPILE=aarch64-linux-gnu- SPD=opteed all
...
...
aarch64-linux-gnu-gcc: fatal error: no input files
compilation terminated.
make: *** [build/fvp/release/bl32/bl32.ld] Error 1

The reason is that the build system checks if BL32 is defined, and
if it is not, it will try to build BL32 from source. If the SPD
makefile does not provide support for that (as is the case of the
OPTEE Dispatcher, since OPTEE is provided as an external binary),
the build will fail.

This patch fixes the issue by checking if `BL32_SOURCES` has been
defined by the SPD before attempting to build BL32 from source.
If neither `BL32` nor `BL32_SOURCES` is defined when building the
FIP, a warning message will be printed and the process aborted.

Fixes ARM-software/tf-issues#333

Change-Id: I5e801ad333103ed9b042e5c4757424c8df2ff6e4

show more ...

Merge pull request #427 from jcastillo-arm/jc/tf-issues/294

Add -mstrict-align to the gcc options

Add -mstrict-align to the gcc options

ARMv8 architecture allows unaligned memory accesses. However,
Trusted Firmware disables such feature by setting the SCTLR_A_BIT
and SCTLR_SA_BIT in the SCTLR_EL

Add -mstrict-align to the gcc options

ARMv8 architecture allows unaligned memory accesses. However,
Trusted Firmware disables such feature by setting the SCTLR_A_BIT
and SCTLR_SA_BIT in the SCTLR_EL3 register (it enables alignment
checks).

This patch adds -mstrict-align to the gcc build options. Although
there are not explicit unaligned memory accesses in Trusted Firmware,
this flag will tell the compiler not to use them.

Fixes ARM-software/tf-issues#294

Change-Id: I69748c6cf28504be9ca3dc975a331d14459c9ef1

show more ...

Merge pull request #425 from achingupta/ag/tf-issues#332

Re-introduce evaluation of ENABLE_PLAT_COMPAT build flag

Re-introduce evaluation of ENABLE_PLAT_COMPAT build flag

Commit #73c99d4eb377e0e25f7951be53087bf92e7b4b18 had refactored the top level
Makefile. This commit also broke platform ports that still rely

Re-introduce evaluation of ENABLE_PLAT_COMPAT build flag

Commit #73c99d4eb377e0e25f7951be53087bf92e7b4b18 had refactored the top level
Makefile. This commit also broke platform ports that still rely on an enabled
ENABLE_PLAT_COMPAT build option since the evaluation of this option was also
accidentally removed from the Makefile.

This patch fixes this break by re-introducing the necessary support to ensure
that this build option is enabled by default if a platform port does not disable
it explicitly.

Fixes ARM-software/tf-issues#332

Change-Id: I2217595d2e0bccae7de98cc6c0ea448b5bf3dae2

show more ...

Merge pull request #417 from jcastillo-arm/jc/makefile_2

Makefile rework and bug fix #2

Make: fix dependency files generation

Currently, if no make goal is specified in the command line, 'all'
is assumed by default, but the dependency files are not generated.
This might lead to a succe

Make: fix dependency files generation

Currently, if no make goal is specified in the command line, 'all'
is assumed by default, but the dependency files are not generated.
This might lead to a successful but inconsistent build. This patch
provides a fix to the problem.

Change-Id: I0148719e114dbdbe46f8a57c7d05da7cbc212c92

show more ...

Rework Makefile

This patch is a complete rework of the main Makefile. Functionality
remains the same but the code has been reorganized in sections in
order to improve readability and facilitate addi

Rework Makefile

This patch is a complete rework of the main Makefile. Functionality
remains the same but the code has been reorganized in sections in
order to improve readability and facilitate adding future extensions.

A new file 'build_macros.mk' has been created and will contain common
definitions (variables, macros, etc) that may be used from the main
Makefile and other platform specific makefiles.

A new macro 'FIP_ADD_IMG' has been introduced and it will allow the
platform to specify binary images and the necessary checks for a
successful build. Platforms that require a BL30 image no longer need
to specify the NEED_BL30 option. The main Makefile is now completely
unaware of additional images not built as part of Trusted Firmware,
like BL30. It is the platform responsibility to specify images using
the macro 'FIP_ADD_IMG'. Juno uses this macro to include the BL30
image in the build.

BL33 image is specified in the main Makefile to preserve backward
compatibility with the NEED_BL33 option. Otherwise, platform ports
that rely on the definition of NEED_BL33 might break.

All Trusted Board Boot related definitions have been moved to a
separate file 'tbbr_tools.mk'. The main Makefile will include this
file unless the platform indicates otherwise by setting the variable
'INCLUDE_TBBR_MK := 0' in the corresponding platform.mk file. This
will keep backward compatibility but ideally each platform should
include the corresponding TBB .mk file in platform.mk.

Change-Id: I35e7bc9930d38132412e950e20aa2a01e2b26801

show more ...

Merge pull request #361 from achingupta/for_sm/psci_proto_v5

For sm/psci proto v5

PSCI: Add deprecated API for SPD when compatibility is disabled

This patch defines deprecated platform APIs to enable Trusted
Firmware components like Secure Payload and their dispatchers(SPD)
to co

PSCI: Add deprecated API for SPD when compatibility is disabled

This patch defines deprecated platform APIs to enable Trusted
Firmware components like Secure Payload and their dispatchers(SPD)
to continue to build and run when platform compatibility is disabled.
This decouples the migration of platform ports to the new platform API
from SPD and enables them to be migrated independently. The deprecated
platform APIs defined in this patch are : platform_get_core_pos(),
platform_get_stack() and platform_set_stack().

The patch also deprecates MPIDR based context management helpers like
cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context().
A mechanism to deprecate APIs and identify callers of these APIs during
build is introduced, which is controlled by the build flag WARN_DEPRECATED.
If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be
flagged either as a link error for assembly files or compile time warning
for C files during build.

Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613

show more ...

PSCI: Switch to the new PSCI frameworks

This commit does the switch to the new PSCI framework implementation replacing
the existing files in PSCI folder with the ones in PSCI1.0 folder. The
correspo

PSCI: Switch to the new PSCI frameworks

This commit does the switch to the new PSCI framework implementation replacing
the existing files in PSCI folder with the ones in PSCI1.0 folder. The
corresponding makefiles are modified as required for the new implementation.
The platform.h header file is also is switched to the new one
as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults
to 1 to enable compatibility layer which let the existing platform ports to
continue to build and run with minimal changes.

The default weak implementation of platform_get_core_pos() is now removed from
platform_helpers.S and is provided by the compatibility layer.

Note: The Secure Payloads and their dispatchers still use the old platform
and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build
flag will remain enabled in subsequent patch. The compatibility for SPDs using
the older APIs on platforms migrated to the new APIs will be added in the
following patch.

Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719

show more ...

PSCI: Implement platform compatibility layer

The new PSCI topology framework and PSCI extended State framework introduces
a breaking change in the platform port APIs. To ease the migration of the
pl

PSCI: Implement platform compatibility layer

The new PSCI topology framework and PSCI extended State framework introduces
a breaking change in the platform port APIs. To ease the migration of the
platform ports to the new porting interface, a compatibility layer is
introduced which essentially defines the new platform API in terms of the
old API. The old PSCI helpers to retrieve the power-state, its associated
fields and the highest coordinated physical OFF affinity level of a core
are also implemented for compatibility. This allows the existing
platform ports to work with the new PSCI framework without significant
rework. This layer will be enabled by default once the switch to the new
PSCI framework is done and is controlled by the build flag ENABLE_PLAT_COMPAT.

Change-Id: I4b17cac3a4f3375910a36dba6b03d8f1700d07e3

show more ...

PSCI: Add framework to handle composite power states

The state-id field in the power-state parameter of a CPU_SUSPEND call can be
used to describe composite power states specific to a platform. The

PSCI: Add framework to handle composite power states

The state-id field in the power-state parameter of a CPU_SUSPEND call can be
used to describe composite power states specific to a platform. The current PSCI
implementation does not interpret the state-id field. It relies on the target
power level and the state type fields in the power-state parameter to perform
state coordination and power management operations. The framework introduced
in this patch allows the PSCI implementation to intepret generic global states
like RUN, RETENTION or OFF from the State-ID to make global state coordination
decisions and reduce the complexity of platform ports. It adds support to
involve the platform in state coordination which facilitates the use of
composite power states and improves the support for entering standby states
at multiple power domains.

The patch also includes support for extended state-id format for the power
state parameter as specified by PSCIv1.0.

The PSCI implementation now defines a generic representation of the power-state
parameter. It depends on the platform port to convert the power-state parameter
(possibly encoding a composite power state) passed in a CPU_SUSPEND call to this
representation via the `validate_power_state()` plat_psci_ops handler. It is an
array where each index corresponds to a power level. Each entry contains the
local power state the power domain at that power level could enter.

The meaning of the local power state values is platform defined, and may vary
between levels in a single platform. The PSCI implementation constrains the
values only so that it can classify the state as RUN, RETENTION or OFF as
required by the specification:
* zero means RUN
* all OFF state values at all levels must be higher than all RETENTION
state values at all levels
* the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values
to the framework

The platform also must define the macros PLAT_MAX_RET_STATE and
PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power
domains have been requested to enter a retention or power down state. The PSCI
implementation does not interpret the local power states defined by the
platform. The only constraint is that the PLAT_MAX_RET_STATE <
PLAT_MAX_OFF_STATE.

For a power domain tree, the generic implementation maintains an array of local
power states. These are the states requested for each power domain by all the
cores contained within the domain. During a request to place multiple power
domains in a low power state, the platform is passed an array of requested
power-states for each power domain through the plat_get_target_pwr_state()
API. It coordinates amongst these states to determine a target local power
state for the power domain. A default weak implementation of this API is
provided in the platform layer which returns the minimum of the requested
power-states back to the PSCI state coordination.

Finally, the plat_psci_ops power management handlers are passed the target
local power states for each affected power domain using the generic
representation described above. The platform executes operations specific to
these target states.

The platform power management handler for placing a power domain in a standby
state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for
placing a core power domain into a standby or retention state should now be
used to only place the core power domain in a standby or retention state.

The extended state-id power state format can be enabled by setting the
build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default.

Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c

show more ...

Merge pull request #315 from jcastillo-arm/jc/tbb_tmp9

Authentication Framework

TBB: switch to the new authentication framework

This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto

TBB: switch to the new authentication framework

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

show more ...

TBB: add ECDSA support to the certificate generation tool

This patch extends the 'cert_create' tool to support ECDSA keys
to sign the certificates. The '--key-alg' command line option
can be used to

TBB: add ECDSA support to the certificate generation tool

This patch extends the 'cert_create' tool to support ECDSA keys
to sign the certificates. The '--key-alg' command line option
can be used to specify the key algorithm when invoking the tool.
Available options are:

* 'rsa': create RSA-2048 keys (default option)
* 'ecdsa': create ECDSA-SECP256R1 keys

The TF Makefile has been updated to allow the platform to specify
the key algorithm by declaring the 'KEY_ALG' variable in the
platform makefile.

The behaviour regarding key management has changed. After applying
this patch, the tool will try first to open the keys from disk. If
one key does not exist or no key is specified, and the command line
option to create keys has been specified, new keys will be created.
Otherwise an error will be generated and the tool will exit. This
way, the user may specify certain keys while the tool will create
the remaining ones. This feature is useful for testing purposes
and CI infrastructures.

The OpenSSL directory may be specified using the build option
'OPENSSL_DIR' when building the certificate generation tool.
Default is '/usr'.

Change-Id: I98bcc2bfab28dd7179f17f1177ea7a65698df4e7

show more ...

TBB: add build option to save private keys

This patch adds a boolean build option 'SAVE_KEYS' to indicate the
certificate generation tool that it must save the private keys used
to establish the cha

TBB: add build option to save private keys

This patch adds a boolean build option 'SAVE_KEYS' to indicate the
certificate generation tool that it must save the private keys used
to establish the chain of trust. This option depends on 'CREATE_KEYS'
to be enabled. Default is '0' (do not save).

Because the same filenames are used as outputs to save the keys,
they are no longer a dependency to the cert_tool. This dependency
has been removed from the Makefile.

Documentation updated accordingly.

Change-Id: I67ab1c2b1f8a25793f0de95e8620ce7596a6bc3b

show more ...

Merge pull request #310 from sandrine-bailleux/sb/tf-issue-304-phase1

Enhance BL3-1 entrypoint handling to support non-TF boot firmware - Phase 1