GitLab

Normally, in the FVP port, secondary CPUs are immediately powered
down if they are powered on at reset. However, when booting an EL3
payload, we need to keep them powered on as the requirement is for
all CPUs to enter the EL3 payload image. This patch puts them in a
holding pen instead of powering them off.

Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c

By default, only the primary CPU is powered on by SCP on CSS
platforms. Secondary CPUs are then powered on later using PSCI
calls.

However, it is possible to power on more than one CPU at boot time
using platform specific settings. In this case, several CPUs will
enter the Trusted Firmware and execute the cold boot path code.
This is currently not supported and secondary CPUs will panic.

This patch preserves this behaviour in the normal boot flow.
However, when booting an EL3 payload, secondary CPUs are now held in
a pen until their mailbox is populated, at which point they jump to
this address. Note that, since all CPUs share the same mailbox, they
will all be released from their holding pen at the same time and the
EL3 payload is responsible to arbitrate execution between CPUs if
required.

Change-Id: I83737e0c9f15ca5e73afbed2e9c761bc580735b9

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

This patch modifies the prototype of the bl1_plat_prepare_exit()
platform API to pass the address of the entry point info structure
received from BL2. The structure contains information that can be
useful, depending on the kind of clean up or bookkeeping operations
to perform.

The weak implementation of this function ignores this argument to
preserve platform backwards compatibility.

NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE
FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API.

Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb

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

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

This patch adds a per-soc system reset handler for Tegra chips. The
handler gets executed before the actual system resets. This allows
for custom handling of the system reset sequence on each SoC.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

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

Patch 7e26fe1f deprecates IO specific return definitions in favour
of standard errno codes. This patch removes those definitions
and its usage from the IO framework, IO drivers and IO platform
layer. Following this patch, standard errno codes must be used
when checking the return value of an IO function.

Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f

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

This patch adds an optional API to the platform port:

    void plat_error_handler(int err) __dead2;

The platform error handler is called when there is a specific error
condition after which Trusted Firmware cannot continue. While panic()
simply prints the crash report (if enabled) and spins, the platform
error handler can be used to hand control over to the platform port
so it can perform specific bookeeping or post-error actions (for
example, reset the system). This function must not return.

The parameter indicates the type of error using standard codes from
errno.h. Possible errors reported by the generic code are:

    -EAUTH  : a certificate or image could not be authenticated
              (when Trusted Board Boot is enabled)
    -ENOENT : the requested image or certificate could not be found
              or an IO error was detected
    -ENOMEM : resources exhausted. Trusted Firmware does not use
              dynamic memory, so this error is usually an indication
              of an incorrect array size

A default weak implementation of this function has been provided.
It simply implements an infinite loop.

Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3

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

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

This patch adds an optional API to the platform port:

    void bl1_plat_prepare_exit(void);

This function is called prior to exiting BL1 in response to the
RUN_IMAGE_SMC request raised by BL2. It should be used to perform
platform specific clean up or bookkeeping operations before
transferring control to the next image.

A weak empty definition of this function has been provided to
preserve platform backwards compatibility.

Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1

This patch does the following reorganization to psci power management (PM)
handler setup for ARM standard platform ports :

1. The mailbox programming required during `plat_setup_psci_ops()` is identical
   for all ARM platforms. Hence the implementation of this API is now moved
   to the common `arm_pm.c` file. Each ARM platform now must define the
   PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
   as ARM_SHARED_RAM_BASE.

2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
   exported via `plat_arm_psci_pm_ops`. This allows the common implementation
   of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
   In the case of CSS platforms, a default weak implementation of the same is
   provided in `css_pm.c` which can be overridden by each CSS platform.

3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
   made library functions and a new header file `css_pm.h` is added to export
   these generic PM handlers. This allows the platform to reuse the
   adequate CSS PM handlers and redefine others which need to be customized
   when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.

Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede

This patch fixes the relative path to the 'bl1_private.h' header file
included from 'arm_bl1_setup.c'. Note that, although the path was
incorrect, it wasn't causing a compilation error because the header
file still got included through an alternative include search path.

Change-Id: I28e4f3dbe50e3550ca6cad186502c88a9fb5e260

This patch adds a device driver which can be used to program the following
aspects of ARM CCN IP:

1. Specify the mapping between ACE/ACELite/ACELite+DVM/CHI master interfaces and
   Request nodes.
2. Add and remove master interfaces from the snoop and dvm
   domains.
3. Place the L3 cache in a given power state.
4. Configuring system adress map and enabling 3 SN striping mode of memory
   controller operation.

Change-Id: I0f665c6a306938e5b66f6a92f8549b529aa8f325

Currently, the non-overlapping video memory carveout region is cleared after
disabling the MMU at EL3. If at any exception level the carveout region is being
marked as cacheable, this zeroing of memory will not have an affect on the
cached lines. Hence, we first invalidate the dirty lines and update the memory
and invalidate again so that both caches and memory is zeroed out.

Change-Id: If3b2d139ab7227f6799c0911d59e079849dc86aa

This patch corrects the watchdog register setting. To update watchdog
register, the watchdog mode key must be set to make the register
configurable.

Change-Id: I9ca98ea4012f7f220b116013461030de4638ce0b
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>

1. update suspend pcm code (add dummy apb read before mcusys power down)

BRANCH=none
BUG=none
TEST=verified

Change-Id: I2802cf8665fc1c8fe2304fd7d5f3eab9948b0b78
Signed-off-by: yt.lee <yt.lee@mediatek.com>

This patch update Mediatek port to use the `DEFINE_BAKERY_LOCK` macro instead of
specifying the exact data structure to use for a bakery lock and the input
linker section that it should be allocated to.

Change-Id: I2116dbe27010bb46d7cc64fafef55c7240c4c721

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

On Juno and FVP platforms, the Non-Secure System timer corresponds
to frame 1. However, this is a platform-specific decision and it
shouldn't be hard-coded. Hence, this patch introduces
PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms
to specify the correct non-secure timer frame.

Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba

This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
support different TrustZone Controller base addresses across ARM platforms.

Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd

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

The previous logic in the memctrl driver was not catering to cases
where the new memory region lied inside the older region. This patch
fixes the if/elseif/elseif logic in the driver to take care of this
case.

Reported by: Vikram Kanigiri <vikram.kanigiri@arm.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch programs the CPUECTLR_EL1 and L2ECTLR_EL1 registers,
so that the core waits for 512 generic timer CNTVALUEB ticks before
entering retention state, after executing a WFI instruction.

This functionality is configurable and can be enabled for platforms
by setting the newly defined 'ENABLE_L2_DYNAMIC_RETENTION' and
'ENABLE_CPU_DYNAMIC_RETENTION' flag.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

Use constant macro defined in platform_def.h to replace hardcoded value.
This patch fix following assert in new psci-1.0 framework.

ASSERT: populate_power_domain_tree <183> : j == PLATFORM_CORE_COUNT

Change-Id: I9b7eda525479464a8c3805b6fe14ffb10debaf72
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>

1. SEJ should not be one of the wake up sources

BUG=chrome-os-partner:38426
TEST=powerd_dbus_suspend

Change-Id: If8f3f19a885e66d7c10b472c2e3182a5affa4773
Signed-off-by: kenny liang <kenny.liang@mediatek.com>

This patch adds the necessary documentation updates to porting_guide.md
for the changes in the platform interface mandated as a result of the new
PSCI Topology and power state management frameworks. It also adds a
new document `platform-migration-guide.md` to aid the migration of existing
platform ports to the new API.

The patch fixes the implementation and callers of
plat_is_my_cpu_primary() to use w0 as the return parameter as implied by
the function signature rather than x0 which was used previously.

Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b

This patch implements the platform power managment handler to verify
non secure entrypoint for ARM platforms. The handler ensures that the
entry point specified by the normal world during CPU_SUSPEND, CPU_ON
or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
DRAM.

Change-Id: I4795452df99f67a24682b22f0e0967175c1de429

Now that the FVP mailbox is no longer zeroed, the function
platform_mem_init() does nothing both on FVP and on Juno. Therefore,
this patch pools it as the default implementation on ARM platforms.

Change-Id: I007220f4531f15e8b602c3368a1129a5e3a38d91

Since there is a unique warm reset entry point, the FVP and Juno
port can use a single mailbox instead of maintaining one per core.
The mailbox gets programmed only once when plat_setup_psci_ops()
is invoked during PSCI initialization. This means mailbox is not
zeroed out during wakeup.

Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432

This patch adds support to the Juno and FVP ports for composite power states
with both the original and extended state-id power-state formats. Both the
platform ports use the recommended state-id encoding as specified in
Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
ARM_RECOM_STATE_ID_ENC is used to include this support.

By default, to maintain backwards compatibility, the original power state
parameter format is used and the state-id field is expected to be zero.

Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10

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

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

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

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