GitLab

We have lots of duplicated defines (and comment blocks too).
Move them to include/plat/common/common_def.h.

While we are here, suffix the end address with _END instead of
_LIMIT.  The _END is a better fit to indicate the linker-derived
real end address.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The usage of _LIMIT seems odd here, so rename as follows:
  BL_CODE_LIMIT     --> BL_CODE_END
  BL_RO_DATA_LIMIT  --> BL_RO_DATA_END
  BL1_CODE_LIMIT    --> BL1_CODE_END
  BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END

Basically, we want to use _LIMIT and _END properly as follows:
  *_SIZE + *_MAX_SIZE = *_LIMIT
  *_SIZE + *_SIZE     = *_END

The _LIMIT is generally defined by platform_def.h to indicate the
platform-dependent memory constraint.  So, its typical usage is
  ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
in a linker script.

On the other hand, _END is used to indicate the end address of the
compiled image, i.e. we do not know it until the image is linked.

Here, all of these macros belong to the latter, so should be
suffixed with _END.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The arm_setup_page_tables() function used to expect a single set of
addresses defining the extents of the whole read-only section, code
and read-only data mixed up, which was mapped as executable.

This patch changes this behaviour. arm_setup_page_tables() now
expects 2 separate sets of addresses:

 - the extents of the code section;
 - the extents of the read-only data section.

The code is mapped as executable, whereas the data is mapped as
execute-never. New #defines have been introduced to identify the
extents of the code and the read-only data section. Given that
all BL images except BL1 share the same memory layout and linker
script structure, these #defines are common across these images.
The slight memory layout differences in BL1 have been handled by
providing values specific to BL1.

Note that this patch also affects the Xilinx platform port, which
uses the arm_setup_page_tables() function. It has been updated
accordingly, such that the memory mappings on this platform are
unchanged. This is achieved by passing null values as the extents
of the read-only data section so that it is ignored. As a result,
the whole read-only section is still mapped as executable.

Fixes ARM-software/tf-issues#85

Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5

This patch introduces the arm_setup_page_tables() function to
set up page tables on ARM platforms. It replaces the
arm_configure_mmu_elx() functions and does the same thing except
that it doesn't enable the MMU at the end. The idea is to reduce
the amount of per-EL code that is generated by the C preprocessor
by splitting the memory regions definitions and page tables creation
(which is generic) from the MMU enablement (which is the only per-EL
configuration).

As a consequence, the call to the enable_mmu_elx() function has been
moved up into the plat_arch_setup() hook. Any other ARM standard
platforms that use the functions `arm_configure_mmu_elx()` must be
updated.

Change-Id: I6f12a20ce4e5187b3849a8574aac841a136de83d

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

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