GitLab

The `ENABLE_AMU` build option can be used to enable the
architecturally defined AMU counters.  At present, there is no support
for the auxiliary counter group.

Change-Id: Ifc7532ef836f83e629f2a146739ab61e75c4abc8
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

The `ENABLE_AMU` build option can be used to enable the
architecturally defined AMU counters.  At present, there is no support
for the auxiliary counter group.

Change-Id: I7ea0c0a00327f463199d1b0a481f01dadb09d312
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

Change-Id: I96de88f44c36681ad8a70430af8e01016394bd14
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

The Cortex A75 has 5 AMU counters.  The first three counters are fixed
and the remaining two are programmable.

A new build option is introduced, `ENABLE_AMU`.  When set, the fixed
counters will be enabled for use by lower ELs.  The programmable
counters are currently disabled.

Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

Fix Makefile for ARMv8-A AArch32 builds

Commit 26e63c44

 broke the Makefile for ARMv8-A AArch32 platforms.
This patch fixes it.

Change-Id: I49b8eb5b88f3a131aa4c8642ef970e92d90b6dd2
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

SPM fixes

Support ARMv7 architectures

Flush the affinity data in psci_affinity_info

Add ARMv8.2 ID_AA64MMFR0_EL1.PARange value

Add support sha512 for hash algorithm

SDEI fixes

Move SPE code to lib/extensions

The flag support the following values:
    - sha256 (default)
    - sha384
    - sha512

Change-Id: I7a49d858c361e993949cf6ada0a86575c3291066
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>

This option enables the user to select the secure hash algorithm
to be used for generating the hash. It supports the following
options:
    - sha256 (default)
    - sha384
    - sha512

Change-Id: Icb093cec1b5715e248c3d1c3749a2479a7ab4b89
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>

There is an edge case where the cache maintaince done in
psci_do_cpu_off may not seen by some cores. This case is handled in
psci_cpu_on_start but it hasn't handled in psci_affinity_info.

Change-Id: I4d64f3d1ca9528e364aea8d04e2d254f201e1702
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

Factor out SPE operations in a separate file.  Use the publish
subscribe framework to drain the SPE buffers before entering secure
world.  Additionally, enable SPE before entering normal world.

A side effect of this change is that the profiling buffers are now
only drained when a transition from normal world to secure world
happens.  Previously they were drained also on return from secure
world, which is unnecessary as SPE is not supported in S-EL1.

Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

It is not possible to detect at compile-time whether support for an
optional extension such as SPE should be enabled based on the
ARM_ARCH_MINOR build option value.  Therefore SPE is now enabled by
default.

Change-Id: I670db164366aa78a7095de70a0962f7c0328ab7c
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

Factor out extension enabling to a separate function that is called
before exiting from EL3 for first entry into Non-secure world.

Change-Id: Ic21401ebba531134d08643c0a1ca9de0fc590a1b
Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>

The explicit event dispatch sequence currently depicts handling done in
Secure EL1, although further error handling is typically done inside a
Secure Partition. Clarify the sequence diagram to that effect.

Change-Id: I53deedc6d5ee0706626890067950c2c541a62c78
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

The SDEI specification requires that binding a client interrupt
dispatches SDEI Normal priority event. This means that dynamic events
can't have Critical priority. Add asserts for this.

Change-Id: I0bdd9e0e642fb2b61810cb9f4cbfbd35bba521d1
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Register count is currently declared as unsigned, where as there are
asserts in place to check it being negative during unregister. These are
flagged as never being true.

Change-Id: I34f00f0ac5bf88205791e9c1298a175dababe7c8
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Change-Id: Ic381ab5d03ec68c7f6e8d357ac2e2cbf0cc6b2e8
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Move FPEXC32_EL2 to FP Context

If an implementation of ARMv8.2 includes ARMv8.2-LPA, the value 0b0110
is permitted in ID_AA64MMFR0_EL1.PARange, which means that the Physical
Address range supported is 52 bits (4 PiB). It is a reserved value
otherwise.

Change-Id: Ie0147218e9650aa09f0034a9ee03c1cca8db908a
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

The FPEXC32_EL2 register controls SIMD and FP functionality when the
lower ELs are executing in AArch32 mode. It is architecturally mapped
to AArch32 system register FPEXC.

This patch removes FPEXC32_EL2 register from the System Register context
and adds it to the floating-point context. EL3 only saves / restores the
floating-point context if the build option CTX_INCLUDE_FPREGS is set to 1.

The rationale for this change is that if the Secure world is using FP
functionality and EL3 is not managing the FP context, then the Secure
world will save / restore the appropriate FP registers.

NOTE - this is a break in behaviour in the unlikely case that
CTX_INCLUDE_FPREGS is set to 0 and the platform contains an AArch32
Secure Payload that modifies FPEXC, but does not save and restore
this register

Change-Id: Iab80abcbfe302752d52b323b4abcc334b585c184
Signed-off-by: David Cunado <david.cunado@arm.com>

The parameters passed to the Secure world from the Secure Partition
Manager when invoking SP_COMMUNICATE_AARCH32/64 were incorrect, as well
as the checks done on them.

Change-Id: I26e8c80cad0b83437db7aaada3d0d9add1c53a78
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

The code was incorrectly reading from ID_AA64PRF0_EL1 instead of
ID_AA64MMFR0_EL1 causing the supported granularity sizes returned by the
code to be wrong.

This wasn't causing any problem because it's just used to check the
alignment of the base of the buffer shared between Non-secure and Secure
worlds, and it was aligned to more than 64 KiB, which is the maximum
granularity supported by the architecture.

Change-Id: Icc0d949d9521cc0ef13afb753825c475ea62d462
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

SDEI: Fix build error with logging enabled

Change-Id: Iee617a3528225349b6eede2f8abb26da96640678
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

EHF and SDEI

The document includes SDEI sequence diagrams that are generated using
PlantUML [1].

A shell script is introduced to generate SVG files from PlantUML files
supplied in arguments.

[1] http://plantuml.com/PlantUML_Language_Reference_Guide.pdf



Change-Id: I433897856810bf1927f2800a7b2b1d81827c69b2
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

This allows for other EL3 components to schedule an SDEI event dispatch
to Normal world upon the next ERET. The API usage constrains are set out
in the SDEI dispatcher documentation.

Documentation to follow.

Change-Id: Id534bae0fd85afc94523490098c81f85c4e8f019
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Support SDEI on ARM platforms using frameworks implemented in earlier
patches by defining and exporting SDEI events: this patch defines the
standard event 0, and a handful of shared and private dynamic events.

Change-Id: I9d3d92a92cff646b8cc55eabda78e140deaa24e1
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Define number of priority bits, and allocate priority levels for SDEI.

Change-Id: Ib6bb6c5c09397f7caef950c4caed5a737b3d4112
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Provide a strong definition for plat_sdei_validate_sdei_entrypoint()
which translates client address to Physical Address, and then validating
the address to be present in DRAM.

Change-Id: Ib93eb66b413d638aa5524d1b3de36aa16d38ea11
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

The function arm_validate_ns_entrypoint() validates a given non-secure
physical address. This function however specifically returns PSCI error
codes.

Non-secure physical address validation is potentially useful across ARM
platforms, even for non-PSCI use cases. Therefore make this function
common by returning 0 for success or -1 otherwise.

Having made the function common, make arm_validate_psci_entrypoint() a
wrapper around arm_validate_ns_entrypoint() which only translates return
value into PSCI error codes. This wrapper is now used where
arm_validate_ns_entrypoint() was currently used for PSCI entry point
validation.

Change-Id: Ic781fc3105d6d199fd8f53f01aba5baea0ebc310
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

The implementation currently supports only interrupt-based SDEI events,
and supports all interfaces as defined by SDEI specification version
1.0 [1].

Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in
BL31.

Update user guide and porting guide. SDEI documentation to follow.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf



Change-Id: I758b733084e4ea3b27ac77d0259705565842241a
Co-authored-by: Yousuf A <yousuf.sait@arm.com>
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

On GICv3 systems, as a side effect of adding provision to handle EL3
interrupts (unconditionally routing FIQs to EL3), pending Non-secure
interrupts (signalled as FIQs) may preempt execution in lower Secure ELs
[1]. This will inadvertently disrupt the semantics of Fast SMC
(previously called Atomic SMC) calls.

To retain semantics of Fast SMCs, the GIC PMR must be programmed to
prevent Non-secure interrupts from preempting Secure execution. To that
effect, two new functions in the Exception Handling Framework subscribe
to events introduced in an earlier commit:

  - Upon 'cm_exited_normal_world', the Non-secure PMR is stashed, and
    the PMR is programmed to the highest Non-secure interrupt priority.

  - Upon 'cm_entering_normal_world', the previously stashed Non-secure
    PMR is restored.

The above sequence however prevents Yielding SMCs from being preempted
by Non-secure interrupts as intended. To facilitate this, the public API
exc_allow_ns_preemption() is introduced that programs the PMR to the
original Non-secure PMR value. Another API
exc_is_ns_preemption_allowed() is also introduced to check if
exc_allow_ns_preemption() had been called previously.

API documentation to follow.

[1] On GICv2 systems, this isn't a problem as, unlike GICv3, pending NS
    IRQs during Secure execution are signalled as IRQs, which aren't
    routed to EL3.

Change-Id: Ief96b162b0067179b1012332cd991ee1b3051dd0
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

EHF is a framework that allows dispatching of EL3 interrupts to their
respective handlers in EL3.

This framework facilitates the firmware-first error handling policy in
which asynchronous exceptions may be routed to EL3. Such exceptions may
be handed over to respective exception handlers. Individual handlers
might further delegate exception handling to lower ELs.

The framework associates the delegated execution to lower ELs with a
priority value. For interrupts, this corresponds to the priorities
programmed in GIC; for other types of exceptions, viz. SErrors or
Synchronous External Aborts, individual dispatchers shall explicitly
associate delegation to a secure priority. In order to prevent lower
priority interrupts from preempting higher priority execution, the
framework provides helpers to control preemption by virtue of
programming Priority Mask register in the interrupt controller.

This commit allows for handling interrupts targeted at EL3. Exception
handlers own interrupts by assigning them a range of secure priorities,
and registering handlers for each priority range it owns.

Support for exception handling in BL31 image is enabled by setting the
build option EL3_EXCEPTION_HANDLING=1.

Documentation to follow.

NOTE: The framework assumes the priority scheme supported by platform
interrupt controller is compliant with that of ARM GIC architecture (v2
or later).

Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>