Prepare platforms to use refactored ARM GIC drivers

This patch adds platform helpers for the new GICv2 and GICv3 drivers in
plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
f

Prepare platforms to use refactored ARM GIC drivers

This patch adds platform helpers for the new GICv2 and GICv3 drivers in
plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
file in their build according to the GIC driver to be used. The existing
plat_gic.c is only meant for the legacy GIC driver.

In the case of ARM platforms, the major changes are as follows:

1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU
interface register values has been modified to detect the type of CPU
interface being used (System register or memory mappped interface) before
using the right interface to print the registers.

2. The power management helper function that is called after a core is powered
up has been further refactored. This is to highlight that the per-cpu
distributor interface should be initialised only when the core was originally
powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API
was used.

3. In the case of CSS platforms, the system power domain restore helper
`arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish`
handler as the system power domain is always expected to be initialized when
the `on_finish` handler is invoked.

Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6

show more ...

Merge pull request #454 from yatharth-arm/vk/deprecate-cci-400

Add CCI-400 specific driver to deprecated driver list

Add CCI-400 specific driver to deprecated driver list

Add compile time `__warn_deprecated` flag to public api's in CCI-400
specific driver so that user is aware of the driver being deprecated.
Simil

Add CCI-400 specific driver to deprecated driver list

Add compile time `__warn_deprecated` flag to public api's in CCI-400
specific driver so that user is aware of the driver being deprecated.
Similarly, it also adds an error message when `ERROR_DEPRECATED` is set
to prevent succesful compilation if CCI-400 specific driver is used.

Change-Id: Id7e61a560262abc01cbbd432ca85b9bf448a194d

show more ...

Remove the assert for TZC base during initialization

When resuming from system suspend the TZC needs to be
re-initialized. Hence the assertion for TZC base address
to detect re-initialization is rem

Remove the assert for TZC base during initialization

When resuming from system suspend the TZC needs to be
re-initialized. Hence the assertion for TZC base address
to detect re-initialization is removed.

Change-Id: I53d64146f6c919e95526441bb997f7b309c68141

show more ...

Merge pull request #452 from vwadekar/tegra-new-platform-apis-v2

Tegra new platform apis v2

Tegra: remove support for legacy platform APIs

This patch modifies the Tegra port to support the new platform
APIs so that we can disable the compat layer. This includes
modifications to the power m

Tegra: remove support for legacy platform APIs

This patch modifies the Tegra port to support the new platform
APIs so that we can disable the compat layer. This includes
modifications to the power management and platform topology code.

Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

show more ...

Enable use of FIQs and IRQs as TSP interrupts

On a GICv2 system, interrupts that should be handled in the secure world are
typically signalled as FIQs. On a GICv3 system, these interrupts are signal

Enable use of FIQs and IRQs as TSP interrupts

On a GICv2 system, interrupts that should be handled in the secure world are
typically signalled as FIQs. On a GICv3 system, these interrupts are signalled
as IRQs instead. The mechanism for handling both types of interrupts is the same
in both cases. This patch enables the TSP to run on a GICv3 system by:

1. adding support for handling IRQs in the exception handling code.
2. removing use of "fiq" in the names of data structures, macros and functions.

The build option TSPD_ROUTE_IRQ_TO_EL3 is deprecated and is replaced with a
new build flag TSP_NS_INTR_ASYNC_PREEMPT. For compatibility reasons, if the
former build flag is defined, it will be used to define the value for the
new build flag. The documentation is also updated accordingly.

Change-Id: I1807d371f41c3656322dd259340a57649833065e

show more ...

Unify interrupt return paths from TSP into the TSPD

The TSP is expected to pass control back to EL3 if it gets preempted due to
an interrupt while handling a Standard SMC in the following scenarios:

Unify interrupt return paths from TSP into the TSPD

The TSP is expected to pass control back to EL3 if it gets preempted due to
an interrupt while handling a Standard SMC in the following scenarios:

1. An FIQ preempts Standard SMC execution and that FIQ is not a TSP Secure
timer interrupt or is preempted by a higher priority interrupt by the time
the TSP acknowledges it. In this case, the TSP issues an SMC with the ID
as `TSP_EL3_FIQ`. Currently this case is never expected to happen as only
the TSP Secure Timer is expected to generate FIQ.

2. An IRQ preempts Standard SMC execution and in this case the TSP issues
an SMC with the ID as `TSP_PREEMPTED`.

In both the cases, the TSPD hands control back to the normal world and returns
returns an error code to the normal world to indicate that the standard SMC it
had issued has been preempted but not completed.

This patch unifies the handling of these two cases in the TSPD and ensures that
the TSP only uses TSP_PREEMPTED instead of separate SMC IDs. Also instead of 2
separate error codes, SMC_PREEMPTED and TSP_EL3_FIQ, only SMC_PREEMPTED is
returned as error code back to the normal world.

Background information: On a GICv3 system, when the secure world has affinity
routing enabled, in 2. an FIQ will preempt TSP execution instead of an IRQ. The
FIQ could be a result of a Group 0 or a Group 1 NS interrupt. In both case, the
TSPD passes control back to the normal world upon receipt of the TSP_PREEMPTED
SMC. A Group 0 interrupt will immediately preempt execution to EL3 where it
will be handled. This allows for unified interrupt handling in TSP for both
GICv3 and GICv2 systems.

Change-Id: I9895344db74b188021e3f6a694701ad272fb40d4

show more ...

Rename GICv3 interrupt group macros

This patch renames the GICv3 interrupt group macros from
INT_TYPE_G0, INT_TYPE_G1S and INT_TYPE_G1NS to INTR_GROUP0,
INTR_GROUP1S and INTR_GROUP1NS respectively.

Rename GICv3 interrupt group macros

This patch renames the GICv3 interrupt group macros from
INT_TYPE_G0, INT_TYPE_G1S and INT_TYPE_G1NS to INTR_GROUP0,
INTR_GROUP1S and INTR_GROUP1NS respectively.

Change-Id: I40c66f589ce6234fa42205adcd91f7d6ad8f33d4

show more ...

Fix SP804 delay timer on FVP

This patch fixes several issues with the SP804 delay timer on FVP:

* By default, the SP804 dual timer on FVP runs at 32 KHz. In order
to run the timer at 35 MHz (as s

Fix SP804 delay timer on FVP

This patch fixes several issues with the SP804 delay timer on FVP:

* By default, the SP804 dual timer on FVP runs at 32 KHz. In order
to run the timer at 35 MHz (as specified in the FVP user manual)
the Overwrite bit in the SP810 control register must be set.

* The CLKMULT and CLKDIV definitions are mixed up:

delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)

From the delay function:

delta_us = (delta * ops->clk_mult) / ops->clk_div;

Matching both expressions:

1 / f(MHz) = ops->clk_mult / ops->clk_div

And consequently:

f(MHz) = ops->clk_div / ops->clk_mult

Which, for a 35 MHz timer, translates to:

ops->clk_div = 35
ops->clk_mult = 1

* The comment in the delay timer header file has been corrected:
The ratio of the multiplier and the divider is the clock period
in microseconds, not the frequency.

Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1

show more ...

Merge pull request #446 from vikramkanigiri/vk/tzc-400

Fix TZC-400 peripheral detection

Merge pull request #449 from jcastillo-arm/jc/tbb_oid

TBB: add ARM OIDs

Merge pull request #444 from jcastillo-arm/jc/tbb_wdog

Jc/tbb wdog

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

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

show more ...

TBB: add ARM OIDs

This patch adds ARM specific OIDs which will be used to extract
the extension data from the certificates. These OIDs are arranged
as a subtree whose root node has been specifically

TBB: add ARM OIDs

This patch adds ARM specific OIDs which will be used to extract
the extension data from the certificates. These OIDs are arranged
as a subtree whose root node has been specifically allocated for
ARM Ltd.

{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) 4128 }

Change-Id: Ice20b3c8a31ddefe9102f3bd42f7429986f3ac34

show more ...

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

Merge pull request #445 from jcastillo-arm/jc/tf-issues/320

Add NULL pointer check before reading BL32 entry point information

Merge pull request #442 from soby-mathew/sm/remove_imf_read_intid

Remove the IMF_READ_INTERRUPT_ID build option

Fix TZC-400 peripheral detection

The TZC-400 driver implementation incorrectly uses the component
ID registers to detect the TZC-400 peripheral. As all ARM
peripherals share the same component ID, i

Fix TZC-400 peripheral detection

The TZC-400 driver implementation incorrectly uses the component
ID registers to detect the TZC-400 peripheral. As all ARM
peripherals share the same component ID, it doesn't allow to
uniquely identify the TZC-400 peripheral. This patch fixes the
TZC-400 driver by relying on the `part_number_0` and
`part_number_1` fields in the `PID` registers instead.
The `tzc_read_component_id` function has been replaced by
`tzc_read_peripheral_id`, which reads the 'part_number' values
and compares them with the TZC-400 peripheral ID.

Also, it adds a debug assertion to detect when the TZC driver
initialisation function is called multiple times.

Change-Id: I35949f6501a51c0a794144cd1c3a6db62440dce6

show more ...

Add a simple ARM SP805 watchdog driver

Based on SP805 Programmer's model (ARM DDI 0270B). This driver
provides three public APIs:

void sp805_start(uintptr_t base, unsigned long ticks);
void

Add a simple ARM SP805 watchdog driver

Based on SP805 Programmer's model (ARM DDI 0270B). This driver
provides three public APIs:

void sp805_start(uintptr_t base, unsigned long ticks);
void sp805_stop(uintptr_t base);
void sp805_refresh(uintptr_t base, unsigned long ticks);

Upon start, the watchdog starts counting down from the number of
ticks specified. When the count reaches 0 an interrupt is triggered.
The watchdog restarts counting down from the number of ticks
specified. If the count reaches 0 again, the system is reset. A
mechanism to handle the interrupt has not been implemented. Instead,
the API to refresh the watchdog should be used instead to prevent a
system reset.

Change-Id: I799d53f8d1213b10b341a4a67fde6486e89a3dab

show more ...

Add basic NOR flash driver for ARM platforms

FVP and Juno platforms include a NOR flash memory to store and
load the FIP, the kernel or a ramdisk. This NOR flash is arranged
as 2 x 16 bit flash devi

Add basic NOR flash driver for ARM platforms

FVP and Juno platforms include a NOR flash memory to store and
load the FIP, the kernel or a ramdisk. This NOR flash is arranged
as 2 x 16 bit flash devices and can be programmed using CFI
standard commands.

This patch provides a basic API to write single 32 bit words of
data into the NOR flash. Functions to lock/unlock blocks against
erase or write operations are also provided.

Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2

show more ...

User Guide: Remove reference to porting guide

The implications of the 'PROGRAMMABLE_RESET_ADDRESS' build option on
the platform porting layer are simple enough to be described in the
User Guide dire

User Guide: Remove reference to porting guide

The implications of the 'PROGRAMMABLE_RESET_ADDRESS' build option on
the platform porting layer are simple enough to be described in the
User Guide directly. This patch removes the reference to the Porting
Guide.

Change-Id: I7f753b18abd20effc4fd30836609e1fd51d9221d

show more ...

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

Document the EL3 payload support

- Document the new build option EL3_PAYLOAD_BASE

- Document the EL3 payload boot flow

- Document the FVP model parameters to boot an EL3 payload

Change-Id: Ie6

Document the EL3 payload support

- Document the new build option EL3_PAYLOAD_BASE

- Document the EL3 payload boot flow

- Document the FVP model parameters to boot an EL3 payload

Change-Id: Ie6535914a9a68626e4401659bee4fcfd53d4bd37

show more ...

FVP: Do not power off secondary CPUs when booting an EL3 payload

Normally, in the FVP port, secondary CPUs are immediately powered
down if they are powered on at reset. However, when booting an EL3

FVP: Do not power off secondary CPUs when booting an EL3 payload

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

show more ...