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.
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.
David Cunado [Fri, 20 Oct 2017 10:30:57 +0000 (11:30 +0100)]
Move FPEXC32_EL2 to FP Context
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>
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.
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.
ARM platforms: Provide SDEI entry point validation
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.
ARM platforms: Make arm_validate_ns_entrypoint() common
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.
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.
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).
Acknowledging interrupt shall return a raw value from the interrupt
controller in which the actual interrupt ID may be encoded. Add a
platform API to extract the actual interrupt ID from the raw value
obtained from interrupt controller.
Document the new function. Also clarify the semantics of interrupt
acknowledge.
At present, the GIC drivers enable Group 0 interrupts only if there are
Secure SPIs listed in the interrupt properties/list. This means that,
even if there are Group 0 SGIs/PPIs configured, the group remained
disabled in the absence of a Group 0 SPI.
Modify both GICv2 and GICv3 SGI/PPI configuration to enable Group 0 when
corresponding SGIs/PPIs are present.
The MP info struct is placed right after the boot info struct. However,
when calculating the address of the MP info, the size of the boot info
struct was being multiplied by the size of the MP boot info. This left
a big gap of empty space between the structs.
This didn't break any code because the boot info struct has a pointer to
the MP info struct. It was just wasting space.
Change-Id: I1668e3540d9173261968f6740623549000bd48db Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
A Secure Partition is a software execution environment instantiated in
S-EL0 that can be used to implement simple management and security
services. Since S-EL0 is an unprivileged exception level, a Secure
Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
granted access to system and processor resources. Essentially, it is a
software sandbox that runs under the control of privileged software in
the Secure World and accesses the following system resources:
- Memory and device regions in the system address map.
- PE system registers.
- A range of asynchronous exceptions e.g. interrupts.
- A range of synchronous exceptions e.g. SMC function identifiers.
A Secure Partition enables privileged firmware to implement only the
absolutely essential secure services in EL3 and instantiate the rest in
a partition. Since the partition executes in S-EL0, its implementation
cannot be overly complex.
The component in ARM Trusted Firmware responsible for managing a Secure
Partition is called the Secure Partition Manager (SPM). The SPM is
responsible for the following:
- Validating and allocating resources requested by a Secure Partition.
- Implementing a well defined interface that is used for initialising a
Secure Partition.
- Implementing a well defined interface that is used by the normal world
and other secure services for accessing the services exported by a
Secure Partition.
- Implementing a well defined interface that is used by a Secure
Partition to fulfil service requests.
- Instantiating the software execution environment required by a Secure
Partition to fulfil a service request.
Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
xlat: Make function to calculate TCR PA bits public
This function can be useful to setup TCR_ELx by callers that don't use
the translation tables library to setup the system registers related
to them. By making it common, it can be reused whenever it is needed
without duplicating code.
Change-Id: Ibfada9e846d2a6cd113b1925ac911bb27327d375 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
A line in the upstream SPDs is only compiled in in `DEBUG` builds. This
line is used to help with assertions and so assertion failures can
happen in release builds with assertions enabled. Use
`ENABLE_ASSERTIONS` instead of `DEBUG`.
This bug was introduced in commit aa61368eb5, which introduced the build
option `ENABLE_ASSERTIONS`.
Change-Id: I7977df9c89c68677b00099b2a1926fa3cb0937c6 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Masahiro Yamada [Fri, 3 Nov 2017 18:14:03 +0000 (03:14 +0900)]
uniphier: make sure to create build directory before ROT key
Building the UniPhier platform in parallel with TRUSTED_BOARD_BOOT=1
could fail due to non-existing directory. It might be difficult to
reproduce, but here is an easier way to trigger the problem:
Soby Mathew [Mon, 16 Oct 2017 14:19:31 +0000 (15:19 +0100)]
Fix PSCI STAT time stamp collection
This patch includes various fixes for PSCI STAT functionality
relating to timestamp collection:
1. The PSCI stat accounting for retention states for higher level
power domains were done outside the locks which could lead to
spurious values in some race conditions. This is moved inside
the locks. Also, the call to start the stat accounting was redundant
which is now removed.
2. The timestamp wrap-around case when calculating residency did
not cater for AArch32. This is now fixed.
3. In the warm boot path, `plat_psci_stat_accounting_stop()` was
getting invoked prior to population of target power states. This
is now corrected.
Roberto Vargas [Mon, 23 Oct 2017 07:22:17 +0000 (08:22 +0100)]
Fix usage of IMAGE_BLx macros
These macros are only defined for corresponding image,
and they are undefined for other images. It means that we have
to use ifdef or defined() instead of relying on being 0 by default.
Roberto Vargas [Fri, 20 Oct 2017 09:46:23 +0000 (10:46 +0100)]
Always define ARM_TSP_RAM_LOCATION_ID
ARM_TSP_RAM_LOCATION_ID was defined only in AARCH64, but the macro
was also used in AARCH32, and it meant that it was taking the value 0,
which happened to equal ARM_TRUSTED_SRAM_ID.
Roberto Vargas [Fri, 20 Oct 2017 09:37:48 +0000 (10:37 +0100)]
Include debug.h in debug.S
debug.S was using macros defined in debug.h, but since it didn't
include it, these macros were taking the value 0, which means that
all the preprocessor conditionals were wrong.
Etienne Carriere [Thu, 26 Oct 2017 10:05:01 +0000 (12:05 +0200)]
qemu/optee: load OP-TEE pageable part 2MB above OP-TEE image
OP-TEE dedicates the end of the Qemu secure DRAM as specific out-of-TEE
secure RAM. To support this configuration the trusted firmware should
not load OP-TEE resources in this area.
To overcome the issue, OP-TEE pageable image is now loaded 2MByte above
the secure RAM base address.
Michalis Pappas [Wed, 18 Oct 2017 01:43:37 +0000 (09:43 +0800)]
qemu: Add support for Trusted Board Boot
This patch adds support for TBB to qemu. An RSA ROT keypair is generated at
build time and is included into BL1/BL2. The key and content certificates
are read over semihosting.
These hooks are intended to allow one platform to try load
images from alternative places. There is a hook to initialize
the sequence of boot locations and a hook to pass to the next
sequence.
Etienne Carriere [Mon, 23 Oct 2017 23:09:52 +0000 (01:09 +0200)]
qemu: fix holding pen mailbox sequence
Before this change, plat_secondary_cold_boot_setup reads wake up mailbox
as a byte array but through 64bit accesses on unaligned 64bit addresses.
In the other hand qemu_pwr_domain_on wakes secondary cores by writing
into a 64bit array.
This change forces the 64bit mailbox format as PLAT_QEMU_HOLD_ENTRY_SIZE
explicitly specifies it.
This light-weight framework enables some EL3 components to publish
events which other EL3 components can subscribe to. Publisher can
optionally pass opaque data for subscribers. The order in which
subscribers are called is not defined.
Eleanor Bonnici [Wed, 4 Oct 2017 14:03:33 +0000 (15:03 +0100)]
Update Foundation, AEM and Cortex Models versions
Trusted Firmware has been tested as part of its CI system against Cortex
and Foundation models in the 11.1 Model release available on
developer.arm.com. Trusted Firmware has also been tested against the
v8.7 AEM model. This patch updates the user guide documentation to
reflect the version of the Foundation, AEM and Cortex Models that
Trusted Firmware has been tested against.
Change-Id: Ia0f51469032427b6056567d151bf8144a7cf0e42 Signed-off-by: Eleanor Bonnici <Eleanor.bonnici@arm.com>
Haojian Zhuang [Wed, 18 Oct 2017 11:52:20 +0000 (19:52 +0800)]
HiKey: init EDMA controller with non secure mode
Init EDMA controller with non secure mode. A lot of peripherals are
depend on EDMA controller. But EDMA controller is in secure mode
by default. And this operation has to be executed in secure mode.
Evan Lloyd [Thu, 25 May 2017 18:16:53 +0000 (19:16 +0100)]
fiptool: Enable Visual Studio build
Updates are required to enable the fiptool utility to be built on a
Windows platform. This change modifies the source files to enable
building with Visual Studio (detected via preprocessor settings).
The primary changes are:
1. Provide an implementation of the getopt_long function. This does
not exist in the Visual Studio CRT libraries because Windows
commands normally use '/' not '-' as an option indicator.
2. Redirect some function names to match those supported by the
Visual Studio libraries (when building with Visual Studio).
2. Modify a structure name (stat) to match that provided
by the Visual Studio libraries (_stat).
Note - this change does not provide makefile updates. It only modifies
the sources to enable the fiptool to be built from a Visual
Studio project. In normal use the presence of FIPTOOL.EXE is
enough to satisfy the make requirements. A makefile change may
be derived from the Visual Studio command line information at
some point in the future.
xlat: Introduce API to change memory attributes of a region
This patch introduces a new API in the translation tables library
(v2), that allows to change the memory attributes of a memory
region. It may be used to change its execution permissions and
data access permissions.
As a prerequisite, the memory must be already mapped. Moreover, it
must be mapped at the finest granularity (currently 4 KB).
Change-Id: I242a8c6f0f3ef2b0a81a61e28706540462faca3c Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Previously, in AArch32, `IMAGE_XLAT_DEFAULT_REGIME` wasn't defined. The
translation regime is only used in the AArch64 port of the translation
tables library v2, so this is not a problem for now, but future patches
will use it.
`IMAGE_EL` isn't used in AArch32, so it isn't needed to define it.
Change-Id: I4acdb01a58658956ab94bd82ed5b7fee1aa6ba90 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The GIC driver initialization currently allows an array of interrupts to
be configured as secure. Future use cases would require more interrupt
configuration other than just security, such as priority.
This patch introduces a new interrupt property array as part of both
GICv2 and GICv3 driver data. The platform can populate the array with
interrupt numbers and respective properties. The corresponding driver
initialization iterates through the array, and applies interrupt
configuration as required.
This capability, and the current way of supplying array (or arrays, in
case of GICv3) of secure interrupts, are however mutually exclusive.
Henceforth, the platform should supply either:
- A list of interrupts to be mapped as secure (the current way).
Platforms that do this will continue working as they were. With this
patch, this scheme is deprecated.
- A list of interrupt properties (properties include interrupt group).
Individual interrupt properties are specified via. descriptors of
type 'interrupt_prop_desc_t', which can be populated with the macro
INTR_PROP_DESC().
A run time assert checks that the platform doesn't specify both.
Henceforth the old scheme of providing list of secure interrupts is
deprecated. When built with ERROR_DEPRECATED=1, GIC drivers will require
that the interrupt properties are supplied instead of an array of secure
interrupts.
Add a section to firmware design about configuring secure interrupts.
ARM platforms: Migrate to using interrupt properties
An earlier patch added provision for the platform to provide secure
interrupt properties. ARM platforms already has a list of interrupts
that fall into different secure groups.
This patch defines macros that enumerate interrupt properties in the
same fashion, and points the driver driver data to a list of interrupt
properties rather than list of secure interrupts on ARM platforms. The
deprecated interrupt list definitions are however retained to support
legacy builds.
Configuration applied to individual interrupts remain unchanged, so no
runtime behaviour change expected.
NOTE: Platforms that use the arm/common function
plat_arm_gic_driver_init() must replace their PLAT_ARM_G1S_IRQS and
PLAT_ARM_G0_IRQS macro definitions with PLAT_ARM_G1S_IRQ_PROPS and
PLAT_ARM_G0_IRQ_PROPS macros respectively, using the provided
INTR_PROP_DESC macro.
These APIs allow the GIC implementation to categorize interrupt numbers
into SPIs, PPIs, and SGIs. The default implementations for GICv2 and
GICv3 follows interrupt numbering as specified by the ARM GIC
architecture.
The PE target mask is used to translate linear PE index (returned by
platform core position) to a bit mask used when targeting interrupts to
a PE, viz. when raising SGIs and routing SPIs.
The platform shall:
- Populate the driver data with a pointer to array that's to contain
per-PE target masks.
- Invoke the new driver API 'gicv2_set_pe_target_mask()' during
per-CPU initialization so that the driver populates the target mask
for that CPU.
Platforms that don't intend to target interrupts or raise SGIs need not
populate this.
projects / arm-tf.git / log