Commit Graph

17 Commits

Author SHA1 Message Date
Dan Handley 1f37b9442f FWU: Pass client cookie to FWU_SMC_UPDATE_DONE
The current FWU_SMC_UPDATE_DONE implementation incorrectly passes
an unused framework cookie through to the 1st argument in the
platform function `bl1_plat_fwu_done`. The intent is to allow
the SMC caller to pass a cookie through to this function.

This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller
through to `bl1_plat_fwu_done`. The argument names are updated
for clarity.

Upstream platforms currently do not use this argument so no
impact is expected.

Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
2015-12-15 14:33:25 +00:00
Yatharth Kochar dcda29f637 FWU: Add Firmware Update support in BL2U for ARM platforms
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
2015-12-09 17:41:19 +00:00
Yatharth Kochar 436223def6 FWU: Add Firmware Update support in BL1 for ARM platforms
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
2015-12-09 17:41:18 +00:00
Achin Gupta 27573c59a6 Rework use of ARM GIC drivers on ARM platforms
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
2015-12-09 09:58:17 +00:00
Juan Castillo 7b4c140514 TBB: add Trusted Watchdog support on ARM platforms
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
2015-12-02 13:54:35 +00:00
Sandrine Bailleux 1dbe31591a Juno R2: Configure the correct L2 RAM latency values
The default reset values for the L2 Data & Tag RAM latencies on the
Cortex-A72 on Juno R2 are not suitable. This patch modifies
the Juno platform reset handler to configure the right settings
on Juno R2.

Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8
2015-11-19 14:53:58 +00:00
Sandrine Bailleux 23d39dbc7e Juno: Rework platform reset handler
This patch splits the Juno reset handler in 4 distinct pieces:

 - Detection of the board revision;
 - Juno R0 specific handler;
 - Juno R1 specific handler;
 - Juno R2 specific handler.

Depending on the board revision, the appropriate handler is called.
This makes the code easier to understand and maintain.

This patch is mainly cosmetic. The only functional change introduced
is that the Juno platform reset handler will now spin infinitely if
the board revision is not recognised. Previously, it would have
assumed that it was running on Juno R1 in this case.

Change-Id: I54ed77c4665085ead9d1573316c9c884d7d3ffa0
2015-11-19 14:53:58 +00:00
Brendan Jackman 0f829ea9fe Add A72 support for Juno R2
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
2015-11-04 16:23:42 +00:00
Soby Mathew c1bb8a0500 Support PSCI SYSTEM SUSPEND on Juno
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
2015-10-30 09:07:17 +00:00
Soby Mathew 5f3a60301e CSS: Implement topology support for System power domain
This patch implements the necessary topology changes for supporting
system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
specific. In addition, the `arm_power_domain_tree_desc[]` and
`arm_pm_idle_states[]` are modified to support the system power domain
at level 2. With this patch, even though the power management operations
involving the system power domain will not return any error, the platform
layer will silently ignore any operations to the power domain. The actual
power management support for the system power domain will be added later.

Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
2015-10-30 09:07:17 +00:00
David Wang 371d4399d1 Allow CSS to redefine function `plat_arm_calc_core_pos`
Currently all ARM CSS platforms which include css_helpers.S use the same
strong definition of `plat_arm_calc_core_pos`. This patch allows these CSS
platforms to define their own strong definition of this function.

* Replace the strong definition of `plat_arm_calc_core_pos` in
  css_helpers.S with a utility function `css_calc_core_pos_swap_cluster`
  does the same thing (swaps cluster IDs). ARM CSS platforms may choose
  to use this function or not.

* Add a Juno strong definition of `plat_arm_calc_core_pos`, which uses
  `css_calc_core_pos_swap_cluster`.

Change-Id: Ib5385ed10e44adf6cd1398a93c25973eb3506d9d
2015-10-27 10:11:55 +08:00
Vikram Kanigiri 883852ca0a Separate CSS security setup from SOC security setup
Currently, on ARM platforms(ex. Juno) non-secure access to specific
peripheral regions, config registers which are inside and outside CSS
is done in the soc_css_security_setup(). This patch separates the CSS
security setup from the SOC security setup in the css_security_setup().

The CSS security setup involves programming of the internal NIC to
provide access to regions inside the CSS. This is needed only in
Juno, hence Juno implements it in its board files as css_init_nic400().

Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
2015-09-11 11:50:26 +01:00
Vikram Kanigiri a7270d35d7 Configure all secure interrupts on ARM platforms
ARM TF configures all interrupts as non-secure except those which
are present in irq_sec_array. This patch updates the irq_sec_array
with the missing secure interrupts for ARM platforms.

It also updates the documentation to be inline with the latest
implementation.

Fixes ARM-software/tf-issues#312

Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
2015-09-01 14:11:09 +01:00
Soby Mathew 38dce70f51 PSCI: Migrate ARM reference platforms to new platform API
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
2015-08-13 23:48:06 +01:00
Juan Castillo 1779ba6b97 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
2015-06-25 08:53:27 +01:00
Sandrine Bailleux 452b7fa25e Remove FIRST_RESET_HANDLER_CALL build option
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required between the first and subsequent invocations
of the reset handling code, this should be detected at runtime.

On Juno, the platform reset handler is now always compiled in.
This means it is now executed twice on the cold boot path, first in
BL1 then in BL3-1, and it has the same behavior in both cases. It is
also executed twice on the warm boot path, first in BL1 then in the
PSCI entrypoint code.

Also update the documentation to reflect this change.

NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.

Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
2015-06-04 10:44:26 +01:00
Dan Handley 85135283f3 Move Juno port to plat/arm/board/juno
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
2015-04-28 19:50:56 +01:00