GitLab

Removing semihosting from the plat_io_storage code copied from FVP.
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>

Juno has a "taped out" BL1.

To run your own BL1 on the board, you have to place it in a "ROM bypass"
address and configure the platform to boot from there.

The agreed bypass address is an offset of 0x03EC0000 from the start of
NOR flash (0x08000000), which equates to 0x0BEC0000.

To run the model using a BL1 in bypass mode, you should use a parameter
set something like this:

	<path to>/FVP_CSS_Juno3 \
		-C css.aon.scp.ROMloader.fname=<SCP ROM filename> \
		--data css.cluster1.cpu0=bl1.bin@0x0BEC0000 \
		-C soc.scc.apps_alt_boot=0x0BEC0000

To build BL1 as a ROM located at address zero, you can over-ride the
default value for TZROM_BASE by passing parameters to make, eg:

	ASFLAGS="-D TZROM_BASE=0x00000000" \
	CFLAGS="-D TZROM_BASE=0x00000000" \
	CROSS_COMPILE=aarch64-linux-gnu- \
	make PLAT=juno DEBUG=1 all

Then you can launch the model using a command such as:

	<path to>/FVP_CSS_Juno3 \
		-C css.aon.scp.ROMloader.fname=<SCP ROM filename> \
		-C css.trustedBootROMloader.fname=<path to>/bl1.bin \
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>

Currently UEFI and Linux are using SMC calls in the 'ARM Architecture'
Owning Entity range so lets implement these to get things working.

UEFI probably doesn't actually need to issue the ID_PRESENCE and ID_UID
calls it does, and the device-tree used by Linux could specify the PSCI
identifiers instead. After those changes, this patch isn't required.
Signed-off-by: Jon Medhurst <tixy@linaro.org>

This is a temporary solution for issue #20
Signed-off-by: Jon Medhurst <tixy@linaro.org>

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

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

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

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

The SCP Ready command is sent by the SCP to indicate that the BL3-0 RAM
Firmware image is successfully up and running.
Signed-off-by: Jon Medhurst <tixy@linaro.org>

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

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

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

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

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

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

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

Note, on Juno mailboxes are 16 bytes because any bigger and they would
overlap the memory used for MHU payload data for SCP->AP transfers.
Signed-off-by: Jon Medhurst <tixy@linaro.org>

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

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

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

Juno doesn't have TZDRAM as FVP does, and there is real reason why we
need a special memory region for bl31_args anyway, assuming we take care
to copy it in BL31 before BL2's memory is reused.
Signed-off-by: Jon Medhurst <tixy@linaro.org>

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

At present, bl1_arch_setup() and bl31_arch_setup() program the counter
frequency using a value from the memory mapped generic timer. The
generic timer however is not necessarily present on all ARM systems
(although it is architected to be present on all server systems).

This patch moves the timer setup to platform-specific code and updates
the relevant documentation. Also, CNTR.FCREQ is set as the specification
requires the bit corresponding to the counter's frequency to be set when
enabling. Since we intend to use the base frequency, set bit 8.

Fixes ARM-software/tf-issues#24

Change-Id: I32c52cf882253e01f49056f47c58c23e6f422652

This patch removes the 'CPU present' flag that's being set but not
referred or used anywhere else.

Change-Id: Iaf82bdb354134e0b33af16c7ba88eb2259b2682a

Fixes ARM-software/tf-issues#41

The policy functions for each file to be loaded were implemented by
copy/pasting one method and then varying the data checked.

This patch creates a generic function to check the policy based on the
data stored in a table.

This removes the amount of duplicated code but also makes the code
simpler and more efficient.

Change-Id: I1c52eacf6f18a1442dabbb33edd03d4bb8bbeae0
Signed-off-by: Ryan Harkin <ryan.harkin@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>

Make gicd_set_ipriorityr() actually write to the priority register.

Also correct callers of this function which want the highest priority
to use the value zero as this is the highest priority value according
to the ARM Generic Interrupt Controller Architecture Specification.

To make this easier to get right, we introduce defines for the lowest
and highest priorities for secure and non-secure interrupts.

Fixes ARM-software/tf-issues#21
Signed-off-by: Jon Medhurst <tixy@linaro.org>

The UART used to be initialised in bl1_platform_setup(). This is too
late because there are some calls to the assert() macro, which needs
to print some messages on the console, before that.

This patch moves the UART initialisation code to
bl1_early_platform_setup().

Fixes ARM-software/tf-issues#49

Change-Id: I98c83a803866372806d2a9c2e1ed80f2ef5b3bcc

At present many recoverable failures are reported as errors. This patch
modifies all such failures to be reported as warnings instead.

Change-Id: I5141653c82498defcada9b90fdf7498ba496b2f2

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>

This patch adds the ability to specify the base address of a UART
device for initialising the console. This allows a boot loader stage
to use a different UART device from UART0 (default) for the console.

Change-Id: Ie60b927389ae26085cfc90d22a564ff83ba62955

This patch factors out the ARM FVP specific code to create MMU
translation tables so that it is possible for a boot loader stage to
create a different set of tables instead of using the default ones.
The default translation tables are created with the assumption that
the calling boot loader stage executes out of secure SRAM. This might
not be true for the BL3_2 stage in the future.

A boot loader stage can define the `fill_xlation_tables()` function as
per its requirements. It returns a reference to the level 1
translation table which is used by the common platform code to setup
the TTBR_EL3.

This patch is a temporary solution before a larger rework of
translation table creation logic is introduced.

Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6

This patch adds the following support to the BL3-1 stage:

1. BL3-1 allows runtime services to specify and determine the security
   state of the next image after BL3-1. This has been done by adding
   the `bl31_set_next_image_type()` & `bl31_get_next_image_type()`
   apis. The default security state is non-secure. The platform api
   `bl31_get_next_image_info()` has been modified to let the platform
   decide which is the next image in the desired security state.

2. BL3-1 exports the `bl31_prepare_next_image_entry()` function to
   program entry into the target security state. It uses the apis
   introduced in 1. to do so.

3. BL3-1 reads the information populated by BL2 about the BL3-2 image
   into its internal data structures.

4. BL3-1 introduces a weakly defined reference `bl32_init()` to allow
   initialisation of a BL3-2 image. A runtime service like the Secure
   payload dispatcher will define this function if present.

Change-Id: Icc46dcdb9e475ce6575dd3f9a5dc7a48a83d21d1

This patch adds support for loading a BL3-2 image in BL2. In case a
BL3-2 image is found, it also passes information to BL3-1 about where it
is located and the extents of memory available to it. Information about
memory extents is populated by platform specific code.

The documentation has also been updated to reflect the above changes.

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