andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/plat/arm/board/fvp/tsp/tsp-fvp.mk

15 lines
414 B
Makefile
Raw Normal View History

Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
#
TSP: Support multi-threading CPUs on FVP Commit 11ad8f208db42f7729b0ce2bd16c631c293e665c added supporting multi-threaded CPUs on FVP platform, including modifications for calculating CPU IDs. This patch imports the strong definition of the same CPU ID calculation on FVP platform for TSP. Without this patch, TSP on FVP was using the default CPU ID calculation, which would end up being wrong on CPUs with multi-threading. Change-Id: If67fd492dfce1f57224c9e693988c4b0f89a9a9a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-10-03 12:19:47 +01:00
# Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
#
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>
2017-05-03 09:38:09 +01:00
# SPDX-License-Identifier: BSD-3-Clause
Add Test Secure Payload (BL3-2) image This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2014-02-18 18:09:12 +00:00
#
# TSP source files specific to FVP platform
fvp: pwrc: Move to drivers/ folder Change-Id: I670ea80e0331c2d4b2ccfa563a45469a43f6902d Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-23 21:50:09 +00:00
BL32_SOURCES += drivers/arm/fvp/fvp_pwrc.c \
plat/arm/board/fvp/aarch64/fvp_helpers.S \
TSP: Support multi-threading CPUs on FVP Commit 11ad8f208db42f7729b0ce2bd16c631c293e665c added supporting multi-threaded CPUs on FVP platform, including modifications for calculating CPU IDs. This patch imports the strong definition of the same CPU ID calculation on FVP platform for TSP. Without this patch, TSP on FVP was using the default CPU ID calculation, which would end up being wrong on CPUs with multi-threading. Change-Id: If67fd492dfce1f57224c9e693988c4b0f89a9a9a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-10-03 12:19:47 +01:00
plat/arm/board/fvp/fvp_topology.c \
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
2015-11-03 14:18:34 +00:00
plat/arm/board/fvp/tsp/fvp_tsp_setup.c \
${FVP_GIC_SOURCES}
Migrate FVP port to use common code Major update to the FVP platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
include plat/arm/common/tsp/arm_tsp.mk