GitLab

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

This patch removes the dash character from the image name, to
follow the image terminology in the Trusted Firmware Wiki page:

    https://github.com/ARM-software/arm-trusted-firmware/wiki

Changes apply to output messages, comments and documentation.

non-ARM platform files have been left unmodified.

Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76

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

This major change pulls out the common functionality from the
FVP and Juno platform ports into the following categories:

*   (include/)plat/common. Common platform porting functionality that
typically may be used by all platforms.

*   (include/)plat/arm/common. Common platform porting functionality
that may be used by all ARM standard platforms. This includes all
ARM development platforms like FVP and Juno but may also include
non-ARM-owned platforms.

*   (include/)plat/arm/board/common. Common platform porting
functionality for ARM development platforms at the board
(off SoC) level.

*   (include/)plat/arm/css/common. Common platform porting
functionality at the ARM Compute SubSystem (CSS) level. Juno
is an example of a CSS-based platform.

*   (include/)plat/arm/soc/common. Common platform porting
functionality at the ARM SoC level, which is not already defined
at the ARM CSS level.

No guarantees are made about the backward compatibility of
functionality provided in (include/)plat/arm.

Also remove any unnecessary variation between the ARM development
platform ports, including:

*   Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
Juno implementation, which copies the information from BL2 memory
instead of expecting it to persist in shared memory.

*   Unify the TZC configuration. There is no need to add a region
for SCP in Juno; it's enough to simply not allow any access to
this reserved region. Also set region 0 to provide no access by
default instead of assuming this is the case.

*   Unify the number of memory map regions required for ARM
development platforms, although the actual ranges mapped for each
platform may be different. For the FVP port, this reduces the
mapped peripheral address space.

These latter changes will only be observed when the platform ports
are migrated to use the new common platform code in subsequent
patches.

Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8