@ -9,9 +9,10 @@ Contents :
4. [Getting the Trusted Firmware source code ](#4--getting-the-trusted-firmware-source-code )
5. [Building the Trusted Firmware ](#5--building-the-trusted-firmware )
6. [Building the rest of the software stack ](#6--building-the-rest-of-the-software-stack )
7. [Preparing the images to run on FVP ](#7--preparing-the-images-to-run-on-fvp )
8. [Running the software on FVP ](#8--running-the-software-on-fvp )
9. [Running the software on Juno ](#9--running-the-software-on-juno )
7. [EL3 payloads alternative boot flow ](#7--el3-payloads-alternative-boot-flow )
8. [Preparing the images to run on FVP ](#8--preparing-the-images-to-run-on-fvp )
9. [Running the software on FVP ](#9--running-the-software-on-fvp )
10. [Running the software on Juno ](#10--running-the-software-on-juno )
1. Introduction
@ -349,9 +350,18 @@ performed.
either 0 (fixed) or 1 (programmable). Default is 0. If the platform has a
programmable reset address, it is expected that a CPU will start executing
code directly at the right address, both on a cold and warm reset. In this
case, there is no need to identify the entrypoint on boot and this has
implication for `plat_get_my_entrypoint()` platform porting interface.
(see the [Porting Guide] for details)
case, there is no need to identify the entrypoint on boot and the boot path
can be optimised. The `plat_get_my_entrypoint()` platform porting interface
does not need to be implemented in this case.
* `COLD_BOOT_SINGLE_CPU` : This option indicates whether the platform may
release several CPUs out of reset. It can take either 0 (several CPUs may be
brought up) or 1 (only one CPU will ever be brought up during cold reset).
Default is 0. If the platform always brings up a single CPU, there is no
need to distinguish between primary and secondary CPUs and the boot path can
be optimised. The `plat_is_my_cpu_primary()` and
`plat_secondary_cold_boot_setup()` platform porting interfaces do not need
to be implemented in this case.
* `PSCI_EXTENDED_STATE_ID` : As per PSCI1.0 Specification, there are 2 formats
possible for the PSCI power-state parameter viz original and extended
@ -367,6 +377,17 @@ performed.
Firmware as error. It can take the value 1 (flag the use of deprecated
APIs as error) or 0. The default is 0.
* `SPIN_ON_BL1_EXIT` : This option introduces an infinite loop in BL1. It can
take either 0 (no loop) or 1 (add a loop). 0 is the default. This loop stops
execution in BL1 just before handing over to BL31. At this point, all
firmware images have been loaded in memory and the MMU as well as the caches
are turned off. Refer to the "Debugging options" section for more details.
* `EL3_PAYLOAD_BASE` : This option enables booting an EL3 payload instead of
the normal boot flow. It must specify the entry point address of the EL3
payload. Please refer to the "Booting an EL3 payload" section for more
details.
#### ARM development platform specific build options
* `ARM_TSP_RAM_LOCATION` : location of the TSP binary. Options:
@ -495,6 +516,25 @@ Extra debug options can be passed to the build system by setting `CFLAGS`:
BL33=< path-to > /< bl33_image > \
make PLAT=< platform > DEBUG=1 V=1 all fip
It is also possible to introduce an infinite loop to help in debugging the
post-BL2 phase of the Trusted Firmware. This can be done by rebuilding BL1 with
the `SPIN_ON_BL1_EXIT=1` build flag. Refer to the "Summary of build options"
section. In this case, the developer may take control of the target using a
debugger when indicated by the console output. When using DS-5, the following
commands can be used:
# Stop target execution
interrupt
#
# Prepare your debugging environment, e.g. set breakpoints
#
# Jump over the debug loop
set var $AARCH64::$Core::$PC = $AARCH64::$Core::$PC + 4
# Resume execution
continue
### Building the Test Secure Payload
@ -694,9 +734,49 @@ above. The EDK2 binary for use with the ARM Trusted Firmware can be found here:
instructions in the "Building the Trusted Firmware" section.
7. Preparing the images to run on FVP
7. EL3 payloads alternative boot flow
--------------------------------------
On a pre-production system, the ability to execute arbitrary, bare-metal code at
the highest exception level is required. It allows full, direct access to the
hardware, for example to run silicon soak tests.
Although it is possible to implement some baremetal secure firmware from
scratch, this is a complex task on some platforms, depending on the level of
configuration required to put the system in the expected state.
Rather than booting a baremetal application, a possible compromise is to boot
`EL3 payloads` through the Trusted Firmware instead. This is implemented as an
alternative boot flow, where a modified BL2 boots an EL3 payload, instead of
loading the other BL images and passing control to BL31. It reduces the
complexity of developing EL3 baremetal code by:
* putting the system into a known architectural state;
* taking care of platform secure world initialization;
* loading the BL30 image if required by the platform.
When booting an EL3 payload on ARM standard platforms, the configuration of the
TrustZone controller is simplified such that only region 0 is enabled and is
configured to permit secure access only. This gives full access to the whole
DRAM to the EL3 payload.
The system is left in the same state as when entering BL31 in the default boot
flow. In particular:
* Running in EL3;
* Current state is AArch64;
* Little-endian data access;
* All exceptions disabled;
* MMU disabled;
* Caches disabled.
8. Preparing the images to run on FVP
--------------------------------------
Note: This section can be ignored when booting an EL3 payload, as no Flattened
Device Tree or kernel image is needed in this case.
### Obtaining the Flattened Device Trees
Depending on the FVP configuration and Linux configuration used, different
@ -744,7 +824,7 @@ Copy the kernel image file `linux/arch/arm64/boot/Image` to the directory from
which the FVP is launched. Alternatively a symbolic link may be used.
8 . Running the software on FVP
9 . Running the software on FVP
-------------------------------
This version of the ARM Trusted Firmware has been tested on the following ARM
@ -1043,9 +1123,41 @@ The `bp.variant` parameter corresponds to the build variant field of the
`SYS_ID` register. Setting this to `0x0` allows the ARM Trusted Firmware to
detect the legacy VE memory map while configuring the GIC.
### Booting an EL3 payload on FVP
Booting an EL3 payload on FVP requires a couple of changes to the way the
model is normally invoked.
First of all, the EL3 payload image is not part of the FIP and is not loaded by
the Trusted Firmware. Therefore, it must be loaded in memory some other way.
There are 2 ways of doing that:
1. It can be loaded over JTAG at the appropriate time. The infinite loop
introduced in BL1 when compiling the Trusted Firmware with
`SPIN_ON_BL1_EXIT=1` stops execution at the right moment for a debugger to
take control of the target and load the payload.
2. It can be pre-loaded in the FVP memory using the following model parameter:
9. Running the software on Juno
--------------------------------
--data="< path-to-binary > "@< base-address-of-binary >
The base address provided to the FVP must match the `EL3_PAYLOAD_BASE`
address used when building the Trusted Firmware.
Secondly, the EL3 payloads boot flow requires the CPUs mailbox to be cleared
at reset for the secondary CPUs holding pen to work properly. Unfortunately,
its reset value is undefined on FVP. One way to clear it is to create an
8-byte file containing all zero bytes and pre-load it into the FVP memory at the
mailbox address (i.e. `0x04000000` ) using the same `--data` FVP parameter as
described above.
The following command creates such a file called `mailbox.dat` :
dd if=/dev/zero of=mailbox.dat bs=1 count=8
10. Running the software on Juno
---------------------------------
This version of the ARM Trusted Firmware has been tested on Juno r0 and Juno r1.
@ -1138,6 +1250,5 @@ _Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._
[Juno Software Guide]: http://community.arm.com/docs/DOC-8396
[DS-5]: http://www.arm.com/products/tools/software-tools/ds-5/index.php
[mbedTLS Repository]: https://github.com/ARMmbed/mbedtls.git
[Porting Guide]: ./porting-guide.md
[PSCI]: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf "Power State Coordination Interface PDD (ARM DEN 0022C)"
[Trusted Board Boot]: trusted-board-boot.md