GitLab

So it updates each time a bootloader changes, not just when bl*_main.c
files are recompiled.

Fixes ARM-software/tf-issues#33

Change-Id: Ie8e1a7bd7e1913d2e96ac268606284f76af8c5ab
Signed-off-by: Jon Medhurst <tixy@linaro.org>

Change-Id: I559c5a4d86cad55ce3f6ad71285b538d3cfd76dc
Signed-off-by: Jon Medhurst <tixy@linaro.org>

This change requires all platforms to now specify a list of source files
rather than object files.

New source files should preferably be specified by using the path as
well and we should add this in the future for all files so we can remove
use of vpath. This is desirable because vpath hides issues like the fact
that BL2 currently pulls in a BL1 file bl1/aarch64/early_exceptions.S
and if in the future we added bl2/aarch64/early_exceptions.S then it's
likely only one of the two version would be used for both bootloaders.

This change also removes the 'dump' build target and simply gets
bootloaders to always generate a dump file. At the same time the -x
option is added so the section headers and symbols table are listed.

Fixes ARM-software/tf-issues#11

Change-Id: Ie38f7be76fed95756c8576cf3f3ea3b7015a18dc
Signed-off-by: Jon Medhurst <tixy@linaro.org>

This patch reworks the service provided by the TSP to perform common
arithmetic operations on a set of arguments provided by the non-secure
world. For a addition, division, subtraction & multiplication operation
requested on two arguments in x0 and x1 the steps are:

1. TSPD saves the non-secure context and passes the operation and its
   arguments to the TSP.

2. TSP asks the TSPD to return the same arguments once again. This
   exercises an additional SMC path.

3. TSP now has two copies of both x0 and x1. It performs the operation
   on the corresponding copies i.e. in case of addition it returns x0+x0
   and x1+x1.

4. TSPD receives the result, saves the secure context, restores the
   non-secure context and passes the result back to the non-secure
   client.

Change-Id: I6eebfa2ae0a6f28b1d2e11a31f575c7a4b96724b
Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

This patch implements a set of handlers in the SPD which are called by
the PSCI runtime service upon receiving a power management
operation. These handlers in turn pass control to the Secure Payload
image if required before returning control to PSCI. This ensures that
the Secure Payload has complete visibility of all power transitions in
the system and can prepare accordingly.

Change-Id: I2d1dba5629b7cf2d53999d39fe807dfcf3f62fe2

This patch adds the TSPD service which is responsible for managing
communication between the non-secure state and the Test Secure Payload
(TSP) executing in S-EL1.

The TSPD does the following:

1. Determines the location of the TSP (BL3-2) image and passes control
   to it for initialization. This is done by exporting the 'bl32_init()'
   function.

2. Receives a structure containing the various entry points into the TSP
   image as a response to being initialized. The TSPD uses this
   information to determine how the TSP should be entered depending on
   the type of operation.

3. Implements a synchronous mechanism for entering into and returning
   from the TSP image. This mechanism saves the current C runtime
   context on top of the current stack and jumps to the TSP through an
   ERET instruction. The TSP issues an SMC to indicate completion of the
   previous request. The TSPD restores the saved C runtime context and
   resumes TSP execution.

This patch also introduces a Make variable 'SPD' to choose the specific
SPD to include in the build. By default, no SPDs are included in the
build.

Change-Id: I124da5695cdc510999b859a1bf007f4d049e04f3
Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

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>