Merge changes from topic "little-build-fixes" into integration

* changes:
fix(build): don't rely on Event Log build tree
fix(build): link Event Log library directly
fix(build): scan symbols un

Merge changes from topic "little-build-fixes" into integration

* changes:
fix(build): don't rely on Event Log build tree
fix(build): link Event Log library directly
fix(build): scan symbols until all are resolved
fix(build): add include directory dependencies

show more ...

fix(build): link Event Log library directly

The `libraries` target is a `.PHONY` target to which various real
library targets, including the Event Log library, have been added over
the years. This t

fix(build): link Event Log library directly

The `libraries` target is a `.PHONY` target to which various real
library targets, including the Event Log library, have been added over
the years. This target is added as a dependency to any target created
with the `MAKE_BL` function. While this might look convenient on the
surface, it also dictates that a library must be linked even to images
it is totally irrelevant for.

The Event Log library is a good example of this; the library is not
typically used by all images, but by attaching itself to the `libraries`
target it becomes mandatory for all of them.

This change returns some of the control over when and where the Event
Log goes to platform maintainers via the introduction of two new
variables:

- `LIBEVLOG_LIBS`: the path to the Event Log static library.
- `LIBEVLOG_INCLUDE_DIRS`: include directories for the public API.

These can be appended to `BLx_LIBS` and `BLx_INCLUDE_DIRS` to include
the Event Log library in the relevant bootloaders.

Change-Id: I3e1a48cd45493334590b34b2ade0c6e29cbfd47a
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge changes from topic "hm/handoff-mb" into integration

* changes:
feat(arm): support boot info handoff and event log
fix(arm): update tsp_early_platform_setup prototype
fix(xilinx): update

Merge changes from topic "hm/handoff-mb" into integration

* changes:
feat(arm): support boot info handoff and event log
fix(arm): update tsp_early_platform_setup prototype
fix(xilinx): update tsp_early_platform_setup prototype
fix(socionext): update tsp_early_platform_setup prototype
fix(msm8916): update tsp_early_platform_setup prototype
feat(tsp): cascade boot arguments to platforms
feat(fvp): port event log to firmware handoff
feat(arm): port event log to firmware handoff
feat(fvp): increase bl2 mmap len for handoff
feat(measured-boot): add fw handoff event log utils

show more ...

feat(arm): support boot info handoff and event log

Add support for processing boot arguments via Firmware
Handoff on Arm platforms. Update platform hooks to pass
boot info to BL31 and BL32 stages.

feat(arm): support boot info handoff and event log

Add support for processing boot arguments via Firmware
Handoff on Arm platforms. Update platform hooks to pass
boot info to BL31 and BL32 stages.

Enable parsing and dumping of an event log from the
transfer list when MEASURED_BOOT is enabled. This allows
measured boot testing in the secure world.

Also update BL32 sources to include event log support when
TSPD and measured boot are both enabled.

Change-Id: Ia310696d0e6cfe93d756bfb075e9fda08342c0a1
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

Merge pull request #925 from dp-arm/dp/spdx

Use SPDX license identifiers

Use SPDX license identifiers

To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.

NOTE: Files that have been imported by

Use SPDX license identifiers

To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.

NOTE: Files that have been imported by FreeBSD have not been modified.

[0]: https://spdx.org/

Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

show more ...

Merge pull request #456 from soby-mathew/sm/gicv3-tsp-plat-changes-v2

Modify TSP and ARM standard platforms for new GIC drivers v2

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

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

show more ...

Merge pull request #361 from achingupta/for_sm/psci_proto_v5

For sm/psci proto v5

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 compos

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

show more ...

Merge pull request #295 from danh-arm/dh/plat-port-reorg

ARM platform port reorganization

Add common ARM and CSS platform code

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

* (include/)plat/common. Common platf

Add common ARM and CSS platform code

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

show more ...