GitLab

Change-Id: I7f3e4bfd46613c6311ba4015d56705414fd6feab
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

This function fills the buffer (first argument) with the specified
number of bytes (second argument) from the trusted entropy source.

This function will be used to initialize the stack protector canary.

Change-Id: Iff15aaf4778c13fa883ecb5528fcf9b8479d4489
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

Juno platform Makefile is responsible for enabling all the relevant
errata. As the Juno platform port does not know which revision of Juno
the TF
is compiled for, the revision of the cores are unknown and so all errata
up to this date are needed on at least one revision of Juno.

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

ARM erratum 855873 applies to all Cortex-A53 CPUs.
The recommended workaround is to promote "data cache clean"
instructions to "data cache clean and invalidate" instructions.
For core revisions of r0p3 and later this can be done by setting a bit
in the CPUACTLR_EL1 register, so that hardware takes care of the promotion.
As CPUACTLR_EL1 is both IMPLEMENTATION DEFINED and can be trapped to EL3,
we set the bit in firmware.
Also we dump this register upon crashing to provide more debug
information.

Enable the workaround for the Juno boards.

Change-Id: I3840114291958a406574ab6c49b01a9d9847fec8
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

TLBI instructions for EL3 won't have the desired effect under specific
circumstances in Cortex-A57 r0p0. The workaround is to execute DSB and
TLBI twice each time.

Even though this errata is only needed in r0p0, the current errata
framework is not prepared to apply run-time workarounds. The current one
is always applied if compiled in, regardless of the CPU or its revision.

This errata has been enabled for Juno.

The `DSB` instruction used when initializing the translation tables has
been changed to `DSB ISH` as an optimization and to be consistent with
the barriers used for the workaround.

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

Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to
`ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines
related to the translation tables but to the image size as well.

The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and
`PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h.
This way, ARM platforms no longer have to set their own values if
`ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values
otherwise. The common sizes have been set to the highest values used
for any of the current build configurations.

This is needed because in some build configurations some images are
running out of space. This way there is a common set of values known
to work for all of them and it can be optimized for each particular
platform if needed.

The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been
increased. This is needed because when memory optimisations are
disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and
`MAX_XLAT_TABLES` are higher. If in this situation the code is
compiled in debug mode and with "-O0", the code won't fit.

Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e

This patch migrates ARM Standard platforms to the refactored TZC driver.

Change-Id: I2a2f60b645f73e14d8f416740c4551cec87cb1fb

`board_arm_def.h` contains multiple definitions of
`PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
memory usage depending upon the chosen build configuration. To ease
maintenance of these constants, this patch replaces their multiple
definitions with a single set of definitions that will work on all ARM
platforms.

Platforms can override the defaults with optimal values by enabling the
`ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
the Juno ADP port.

Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
future ARM platforms.

Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0

The common topology description helper funtions and macros for
ARM Standard platforms assumed a dual cluster system. This is not
flexible enough to scale to multi cluster platforms. This patch does
the following changes for more flexibility in defining topology:

1. The `plat_get_power_domain_tree_desc()` definition is moved from
   `arm_topology.c` to platform specific files, that is `fvp_topology.c`
   and `juno_topology.c`. Similarly the common definition of the porting
   macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
   specific `platform_def.h` header.

2. The ARM common layer porting macros which were dual cluster specific
   are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
   which must be defined by each ARM standard platform.

3. A new mandatory ARM common layer porting API
   `plat_arm_get_cluster_core_count()` is introduced to enable the common
   implementation of `arm_check_mpidr()` to validate MPIDR.

4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
   introduced which allows the user to specify the cluster count to be
   used to build the topology tree within Trusted Firmare. This enables
   Trusted Firmware to be built for multi cluster FVP models.

Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b

ARM Trusted Firmware supports 2 different interconnect peripheral
drivers: CCI and CCN. ARM platforms are implemented using either of the
interconnect peripherals.

This patch adds a layer of abstraction to help ARM platform ports to
choose the right interconnect driver and corresponding platform support.
This is as described below:

1. A set of ARM common functions have been implemented to initialise an
interconnect and for entering/exiting a cluster from coherency. These
functions are prefixed as "plat_arm_interconnect_". Weak definitions of
these functions have been provided for each type of driver.

2.`plat_print_interconnect_regs` macro used for printing CCI registers is
moved from a common arm_macros.S to cci_macros.S.

3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure
is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.

Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c

Prior to this patch, it was assumed that on all ARM platforms the bare
minimal security setup required is to program TrustZone protection. This
would always be done by programming the TZC-400 which was assumed to be
present in all ARM platforms. The weak definition of
platform_arm_security_setup() in plat/arm/common/arm_security.c
reflected these assumptions.

In reality, each ARM platform either decides at runtime whether
TrustZone protection needs to be programmed (e.g. FVPs) or performs
some security setup in addition to programming TrustZone protection
(e.g. NIC setup on Juno). As a result, the weak definition of
plat_arm_security_setup() is always overridden.

When a platform needs to program TrustZone protection and implements the
TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is
also possible to program TrustZone protection through other peripherals
that include a TrustZone controller e.g. DMC-500. The programmer's
interface is slightly different across these various peripherals.

In order to satisfy the above requirements, this patch makes the
following changes to the way security setup is done on ARM platforms.

1. arm_security.c retains the definition of arm_tzc_setup() and has been
   renamed to arm_tzc400.c. This is to reflect the reliance on the
   TZC-400 peripheral to perform TrustZone programming. The new file is
   not automatically included in all platform ports through
   arm_common.mk. Each platform must include it explicitly in a platform
   specific makefile if needed.

   This approach enables introduction of similar library code to program
   TrustZone protection using a different peripheral. This code would be
   used by the subset of ARM platforms that implement this peripheral.

2. Due to #1 above, existing platforms which implements the TZC-400 have been
   updated to include the necessary files for both BL2, BL2U and BL31
   images.

Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735

This patch adds support for Firmware update in BL2U for ARM
platforms such that TZC initialization is performed on all
ARM platforms and (optionally) transfer of SCP_BL2U image on
ARM CSS platforms.

BL2U specific functions are added to handle early_platform and
plat_arch setup. The MMU is configured to map in the BL2U
code/data area and other required memory.

Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f

This patch adds Firmware Update support for ARM platforms.

New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
platform specific Firmware update code.

BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
authenticating NS_BL2U image(For both FVP and JUNO platform).

Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555

Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
separate drivers instead of providing a single driver that can work on both
versions of the GIC architecture. These drivers correspond to the following
software use cases:

1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
   e.g. GIC-400

2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
   e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features

3. A deprecated GICv3 driver that operates in legacy mode. This driver can
   operate only in the GICv2 mode in the secure world. On a GICv3 system, this
   driver allows normal world to run in either GICv3 mode (asymmetric mode)
   or in the GICv2 mode. Both modes of operation are deprecated on GICv3
   systems.

ARM platforms implement both versions of the GIC architecture. This patch adds a
layer of abstraction to help ARM platform ports chose the right GIC driver and
corresponding platform support. This is as described below:

1. A set of ARM common functions have been introduced to initialise the GIC and
   the driver during cold and warm boot. These functions are prefixed as
   "plat_arm_gic_". Weak definitions of these functions have been provided for
   each type of driver.

2. Each platform includes the sources that implement the right functions
   directly into the its makefile. The FVP can be instantiated with different
   versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
   to specify which of the three drivers should be included in the build.

3. A list of secure interrupts has to be provided to initialise each of the
  three GIC drivers. For GIC v3.0 the interrupt ids have to be further
  categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
  types are merged and treated as Group 0 interrupts.

  The two lists of interrupts are exported from the platform_def.h. The lists
  are constructed by adding a list of board specific interrupt ids to a list of
  ids common to all ARM platforms and Compute sub-systems.

This patch also makes some fields of `arm_config` data structure in FVP redundant
and these unused fields are removed.

Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8

This patch adds watchdog support on ARM platforms (FVP and Juno).
A secure instance of SP805 is used as Trusted Watchdog. It is
entirely managed in BL1, being enabled in the early platform setup
hook and disabled in the exit hook. By default, the watchdog is
enabled in every build (even when TBB is disabled).

A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
has been introduced to allow the user to disable the watchdog at
build time. This feature may be used for testing or debugging
purposes.

Specific error handlers for Juno and FVP are also provided in this
patch. These handlers will be called after an image load or
authentication error. On FVP, the Table of Contents (ToC) in the FIP
is erased. On Juno, the corresponding error code is stored in the
V2M Non-Volatile flags register. In both cases, the CPU spins until
a watchdog reset is generated after 256 seconds (as specified in
the TBBR document).

Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4

Cortex-A72 library support is now compiled into the Juno platform port to go
with the existing A53/A57 support. This enables a single set of Juno TF
binaries to run on Juno R0, R1 and R2 boards.

Change-Id: I4a601dc4f671e98bdb19d98bbb66f02f0d8b7fc7

This patch adds the capability to power down at system power domain level
on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers
are modified to add support for power management operations at system
power domain level. A new helper for populating `get_sys_suspend_power_state`
handler in plat_psci_ops is defined. On entering the system suspend state,
the SCP powers down the SYSTOP power domain on the SoC and puts the memory
into retention mode. On wakeup from the power down, the system components
on the CSS will be reinitialized by the platform layer and the PSCI client
is responsible for restoring the context of these system components.

According to PSCI Specification, interrupts targeted to cores in PSCI CPU
SUSPEND should be able to resume it. On Juno, when the system power domain
is suspended, the GIC is also powered down. The SCP resumes the final core
to be suspend when an external wake-up event is received. But the other
cores cannot be woken up by a targeted interrupt, because GIC doesn't
forward these interrupts to the SCP. Due to this hardware limitation,
we down-grade PSCI CPU SUSPEND requests targeted to the system power domain
level to cluster power domain level in `juno_validate_power_state()`
and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c.

A system power domain resume helper `arm_system_pwr_domain_resume()` is
defined for ARM standard platforms which resumes/re-initializes the
system components on wakeup from system suspend. The security setup also
needs to be done on resume from system suspend, which means
`plat_arm_security_setup()` must now be included in the BL3-1 image in
addition to previous BL images if system suspend need to be supported.

Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47

This patch migrates ARM reference platforms, Juno and FVP, to the new platform
API mandated by the new PSCI power domain topology and composite power state
frameworks. The platform specific makefiles now exports the build flag
ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.

Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29

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

Move the Juno port from plat/juno to plat/arm/board/juno. Also rename
some of the files so they are consistently prefixed with juno_.
Update the platform makefiles accordingly.

Change-Id: I0af6cb52a5fee7ef209107a1188b76a3c33a2a9f

Major update to the Juno platform port to use the common platform code
in (include/)plat/arm/* and (include/)plat/common/*. This mainly
consists of removing duplicated code but also introduces some small
behavioural changes where there was unnecessary variation between the
FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
platform code` for details.

Also move the ARM SoC specific security setup (i.e. NIC-400 and PCIe
initialization) from BL1 to `plat_arm_security_setup()` in BL2,
where the other security setup is done.

Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124

This patch updates the FVP and Juno platform ports to use the common
driver for ARM Cache Coherent Interconnects.

Change-Id: Ib142f456b9b673600592616a2ec99e9b230d6542

Cortex-A57 erratum #806969 applies to revision r0p0 of the CPU
but does not manifest itself on Juno r0. It is not applicable
to Juno r1 in any case.

This patch modifies the Juno platform Makefile to no longer
compile this erratum workaround in.

Change-Id: I32b16835b2ac897e639e869ab2b78b62a51a0139

This patch adds the function plat_match_rotpk() to the platform
porting layer to provide a Root Of Trust Public key (ROTPK)
verification mechanism. This function is called during the
Trusted Board Boot process and receives a supposed valid copy
of the ROTPK as a parameter, usually obtained from an external
source (for instance, a certificate). It returns 0 (success) if
that key matches the actual ROTPK stored in the system or any
other value otherwise.

The mechanism to access the actual ROTPK stored in the system
is platform specific and should be implemented as part of this
function. The format of the ROTPK is also platform specific
(to save memory, some platforms might store a hash of the key
instead of the whole key).

TRUSTED_BOARD_BOOT build option has been added to allow the user
to enable the Trusted Board Boot features. The implementation of
the plat_match_rotpk() funtion is mandatory when Trusted Board
Boot is enabled.

For development purposes, FVP and Juno ports provide a dummy
function that returns always success (valid key). A safe trusted
boot implementation should provide a proper matching function.

Documentation updated accordingly.

Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3

This patch moves the bakery locks out of coherent memory to normal memory.
This implies that the lock information needs to be placed on a separate cache
line for each cpu. Hence the bakery_lock_info_t structure is allocated in the
per-cpu data so as to minimize memory wastage. A similar platform per-cpu
data is introduced for the platform locks.

As a result of the above changes, the bakery lock api is completely changed.
Earlier, a reference to the lock structure was passed to the lock implementation.
Now a unique-id (essentially an index into the per-cpu data array) and an offset
into the per-cpu data for bakery_info_t needs to be passed to the lock
implementation.

Change-Id: I1e76216277448713c6c98b4c2de4fb54198b39e0

This patch replaces the usage of the GIC private driver in Juno with
the generic ARM GIC driver. The private driver is no longer necessary
and has been removed from the Juno port.

Fixes ARM-software/tf-issues#253

Change-Id: I6aaabc252e5e6fb5fcf44ab6d0febd9b38791056

This patch optimizes the Cortex-A57 cluster power down sequence by not
flushing the Level1 data cache. The L1 data cache and the L2 unified
cache are inclusive. A flush of the L2 by set/way flushes any dirty
lines from the L1 as well. This is a known safe deviation from the
Cortex-A57 TRM defined power down sequence. This optimization can be
enabled by the platform through the 'SKIP_A57_L1_FLUSH_PWR_DWN' build
flag. Each Cortex-A57 based platform must make its own decision on
whether to use the optimization.

This patch also renames the cpu-errata-workarounds.md to
cpu-specific-build-macros.md as this facilitates documentation
of both CPU Specific errata and CPU Specific Optimization
build macros.

Change-Id: I299b9fe79e9a7e08e8a0dffb7d345f9a00a71480

This patch configures the TrustZone Controller in Juno to split
the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure
regions:

- Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are
  used by the SCP for DDR retraining
- Non-Secure DDR-DRAM: remaining DRAM starting at base address

Build option PLAT_TSP_LOCATION selects the location of the secure
payload (BL3-2):

- 'tsram' : Trusted SRAM (default option)
- 'dram'  : Secure region in the DDR-DRAM (set by the TrustZone
            controller)

The MMU memory map has been updated to give BL2 permission to load
BL3-2 into the DDR-DRAM secure region.

Fixes ARM-software/tf-issues#233

Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b

This patch replaces direct accesses to the TZC-400 registers by the
appropiate calls to the generic driver available in the Trusted
Firmware in order to initialize the TrustZone Controller.

Functions related to the initialization of the secure memory,
like the TZC-400 configuration, have been moved to a new file
'plat_security.c'. This reorganization makes easier to set up
the secure memory from any BL stage.

TZC-400 initialization has been moved from BL1 to BL2 because BL1
does not access the non-secure memory. It is BL2's responsibility
to enable and configure the TZC-400 before loading the next BL
images.

In Juno, BL3-0 initializes some of the platform peripherals, like
the DDR controller. Thus, BL3-0 must be loaded before configuring
the TrustZone Controller. As a consequence, the IO layer
initialization has been moved to early platform initialization.

Fixes ARM-software/tf-issues#234

Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e

This patch adds the initial port of the ARM Trusted Firmware on the Juno
development platform. This port does not support a BL3-2 image or any PSCI APIs
apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected
Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno
platform errata (Defect id 831273).

Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893