Merge pull request #254 from achingupta/ag/v1.1-doc-updates
Documentation for version 1.1
diff --git a/docs/cpu-specific-build-macros.md b/docs/cpu-specific-build-macros.md
index b913f5f..2368fd2 100644
--- a/docs/cpu-specific-build-macros.md
+++ b/docs/cpu-specific-build-macros.md
@@ -21,7 +21,7 @@
ARM Trusted Firmware exports a series of build flags which control the
errata workarounds that are applied to each CPU by the reset handler. The
-errata details can be found in the CPU specifc errata documents published
+errata details can be found in the CPU specific errata documents published
by ARM. The errata workarounds are implemented for a particular revision
or a set of processor revisions. This is checked by reset handler at runtime.
Each errata workaround is identified by its `ID` as specified in the processor's
diff --git a/docs/firmware-design.md b/docs/firmware-design.md
index 2bde352..32ae60f 100644
--- a/docs/firmware-design.md
+++ b/docs/firmware-design.md
@@ -425,7 +425,7 @@
PSTATE.EL = 3
PSTATE.RW = 1
PSTATE.DAIF = 0xf
- CTLR_EL3.EE = 0
+ SCTLR_EL3.EE = 0
X0 and X1 can be used to pass information from the Trusted Boot Firmware to the
platform code in BL3-1:
@@ -1060,9 +1060,9 @@
The BL entrypoint code first invokes the `plat_reset_handler()` to allow
the platform to perform any system initialization required and any system
-errata wrokarounds that needs to be applied. The `get_cpu_ops_ptr()` reads
+errata workarounds that needs to be applied. The `get_cpu_ops_ptr()` reads
the current CPU midr, finds the matching `cpu_ops` entry in the `cpu_ops`
-array and returns it. Note that only the part number and implementator fields
+array and returns it. Note that only the part number and implementer fields
in midr are used to find the matching `cpu_ops` entry. The `reset_func()` in
the returned `cpu_ops` is then invoked which executes the required reset
handling for that CPU and also any errata workarounds enabled by the platform.
diff --git a/docs/porting-guide.md b/docs/porting-guide.md
index 09cd7d5..3ba6715 100644
--- a/docs/porting-guide.md
+++ b/docs/porting-guide.md
@@ -126,6 +126,36 @@
Name of the BL3-3 binary image on the host file-system. This name is used by
BL2 to load BL3-3 into non-secure memory from platform storage.
+* **#define : BL2_CERT_NAME**
+
+ Name of the BL2 content certificate on the host file-system (mandatory when
+ Trusted Board Boot is enabled).
+
+* **#define : TRUSTED_KEY_CERT_NAME**
+
+ Name of the Trusted Key certificate on the host file-system (mandatory when
+ Trusted Board Boot is enabled).
+
+* **#define : BL31_KEY_CERT_NAME**
+
+ Name of the BL3-1 Key certificate on the host file-system (mandatory when
+ Trusted Board Boot is enabled).
+
+* **#define : BL31_CERT_NAME**
+
+ Name of the BL3-1 Content certificate on the host file-system (mandatory
+ when Trusted Board Boot is enabled).
+
+* **#define : BL33_KEY_CERT_NAME**
+
+ Name of the BL3-3 Key certificate on the host file-system (mandatory when
+ Trusted Board Boot is enabled).
+
+* **#define : BL33_CERT_NAME**
+
+ Name of the BL3-3 Content certificate on the host file-system (mandatory
+ when Trusted Board Boot is enabled).
+
* **#define : PLATFORM_CACHE_LINE_SIZE**
Defines the size (in bytes) of the largest cache line across all the cache
@@ -194,6 +224,25 @@
Defines the base address in non-secure DRAM where BL2 loads the BL3-3 binary
image. Must be aligned on a page-size boundary.
+If a BL3-0 image is supported by the platform, the following constants must
+also be defined:
+
+* **#define : BL30_IMAGE_NAME**
+
+ Name of the BL3-0 binary image on the host file-system. This name is used by
+ BL2 to load BL3-0 into secure memory from platform storage before being
+ transfered to the SCP.
+
+* **#define : BL30_KEY_CERT_NAME**
+
+ Name of the BL3-0 Key certificate on the host file-system (mandatory when
+ Trusted Board Boot is enabled).
+
+* **#define : BL30_CERT_NAME**
+
+ Name of the BL3-0 Content certificate on the host file-system (mandatory
+ when Trusted Board Boot is enabled).
+
If a BL3-2 image is supported by the platform, the following constants must
also be defined:
@@ -202,6 +251,16 @@
Name of the BL3-2 binary image on the host file-system. This name is used by
BL2 to load BL3-2 into secure memory from platform storage.
+* **#define : BL32_KEY_CERT_NAME**
+
+ Name of the BL3-2 Key certificate on the host file-system (mandatory when
+ Trusted Board Boot is enabled).
+
+* **#define : BL32_CERT_NAME**
+
+ Name of the BL3-2 Content certificate on the host file-system (mandatory
+ when Trusted Board Boot is enabled).
+
* **#define : BL32_BASE**
Defines the base address in secure memory where BL2 loads the BL3-2 binary
@@ -1445,9 +1504,10 @@
It is mandatory to implement at least one storage driver. For the FVP the
Firmware Image Package(FIP) driver is provided as the default means to load data
from storage (see the "Firmware Image Package" section in the [User Guide]).
-The storage layer is described in the header file `include/io_storage.h`. The
-implementation of the common library is in `lib/io_storage.c` and the driver
-files are located in `drivers/io/`.
+The storage layer is described in the header file
+`include/drivers/io/io_storage.h`. The implementation of the common library
+is in `drivers/io/io_storage.c` and the driver files are located in
+`drivers/io/`.
Each IO driver must provide `io_dev_*` structures, as described in
`drivers/io/io_driver.h`. These are returned via a mandatory registration
diff --git a/docs/trusted-board-boot.md b/docs/trusted-board-boot.md
new file mode 100644
index 0000000..abba030
--- /dev/null
+++ b/docs/trusted-board-boot.md
@@ -0,0 +1,261 @@
+Trusted Board Boot Design Guide
+===============================
+
+Contents :
+
+1. [Introduction](#1--introduction)
+2. [Chain of Trust](#2--chain-of-trust)
+3. [Trusted Board Boot Sequence](#3--trusted-board-boot-sequence)
+4. [Authentication Module](#4--authentication-module)
+5. [Certificate Generation Tool](#5--certificate-generation-tool)
+
+
+1. Introduction
+----------------
+
+The Trusted Board Boot (TBB) feature prevents malicious firmware from running on
+the platform by authenticating all firmware images up to and including the
+normal world bootloader. It does this by establishing a Chain of Trust using
+Public-Key-Cryptography Standards (PKCS).
+
+This document describes the design of the ARM Trusted Firmware TBB
+implementation. The current implementation is a proof of concept; future
+versions will provide stronger architectural interfaces and implement the
+missing functionality required in a production TBB-enabled system.
+
+
+2. Chain of Trust
+------------------
+
+A Chain of Trust (CoT) starts with a set of implicitly trusted components. On
+the ARM development platforms, these components are:
+
+* A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
+ trusted root-key storage registers.
+
+* The BL1 image, on the assumption that it resides in ROM so cannot be
+ tampered with.
+
+The remaining components in the CoT are either certificates or boot loader
+images. The certificates follow the [X.509 v3] standard. This standard
+enables adding custom extensions to the certificates, which are used to store
+essential information to establish the CoT.
+
+In the TBB CoT all certificates are self-signed. There is no need for a
+Certificate Authority (CA) because the CoT is not established by verifying the
+validity of a certificate's issuer but by the content of the certificate
+extensions. To sign the certificates, the PKCS#1 SHA-1 with RSA Encryption
+signature scheme is used with a RSA key length of 2048 bits. Future version of
+Trusted Firmware will replace SHA-1 usage with SHA-256 and support additional
+cryptographic algorithms.
+
+The certificates are categorised as "Key" and "Content" certificates. Key
+certificates are used to verify public keys which have been used to sign content
+certificates. Content certificates are used to store the hash of a boot loader
+image. An image can be authenticated by calculating its hash and matching it
+with the hash extracted from the content certificate. The SHA-256 function is
+used to calculate all hashes. The public keys and hashes are included as
+non-standard extension fields in the [X.509 v3] certificates.
+
+The keys used to establish the CoT are:
+
+* **Root of trust key**
+
+ The private part of this key is used to sign the BL2 content certificate and
+ the trusted key certificate. The public part is the ROTPK.
+
+* **Trusted world key**
+
+ The private part is used to sign the key certificates corresponding to the
+ secure world images (BL3-0, BL3-1 and BL3-2). The public part is stored in
+ one of the extension fields in the trusted world certificate.
+
+* **Non-trusted world key**
+
+ The private part is used to sign the key certificate corresponding to the
+ non secure world image (BL3-3). The public part is stored in one of the
+ extension fields in the trusted world certificate.
+
+* **BL3-X keys**
+
+ For each of BL3-0, BL3-1, BL3-2 and BL3-3, the private part is used to sign
+ the content certificate for the BL3-X image. The public part is stored in
+ one of the extension fields in the corresponding key certificate.
+
+The following images are included in the CoT:
+
+* BL1
+* BL2
+* BL3-0 (optional)
+* BL3-1
+* BL3-3
+* BL3-2 (optional)
+
+The following certificates are used to authenticate the images.
+
+* **BL2 content certificate**
+
+ It is self-signed with the private part of the ROT key. It contains a hash
+ of the BL2 image.
+
+* **Trusted key certificate**
+
+ It is self-signed with the private part of the ROT key. It contains the
+ public part of the trusted world key and the public part of the non-trusted
+ world key.
+
+* **BL3-0 key certificate**
+
+ It is self-signed with the trusted world key. It contains the public part of
+ the BL3-0 key.
+
+* **BL3-0 content certificate**
+
+ It is self-signed with the BL3-0 key. It contains a hash of the BL3-0 image.
+
+* **BL3-1 key certificate**
+
+ It is self-signed with the trusted world key. It contains the public part of
+ the BL3-1 key.
+
+* **BL3-1 content certificate**
+
+ It is self-signed with the BL3-1 key. It contains a hash of the BL3-1 image.
+
+* **BL3-2 key certificate**
+
+ It is self-signed with the trusted world key. It contains the public part of
+ the BL3-2 key.
+
+* **BL3-2 content certificate**
+
+ It is self-signed with the BL3-2 key. It contains a hash of the BL3-2 image.
+
+* **BL3-3 key certificate**
+
+ It is self-signed with the non-trusted world key. It contains the public
+ part of the BL3-3 key.
+
+* **BL3-3 content certificate**
+
+ It is self-signed with the BL3-3 key. It contains a hash of the BL3-3 image.
+
+The BL3-0 and BL3-2 certificates are optional, but they must be present if the
+corresponding BL3-0 or BL3-2 images are present.
+
+
+3. Trusted Board Boot Sequence
+-------------------------------
+
+The CoT is verified through the following sequence of steps. The system panics
+if any of the steps fail.
+
+* BL1 loads and verifies the BL2 content certificate. The issuer public key is
+ read from the verified certificate. A hash of that key is calculated and
+ compared with the hash of the ROTPK read from the trusted root-key storage
+ registers. If they match, the BL2 hash is read from the certificate.
+
+ Note: the matching operation is platform specific and is currently
+ unimplemented on the ARM development platforms.
+
+* BL1 loads the BL2 image. Its hash is calculated and compared with the hash
+ read from the certificate. Control is transferred to the BL2 image if all
+ the comparisons succeed.
+
+* BL2 loads and verifies the trusted key certificate. The issuer public key is
+ read from the verified certificate. A hash of that key is calculated and
+ compared with the hash of the ROTPK read from the trusted root-key storage
+ registers. If the comparison succeeds, BL2 reads and saves the trusted and
+ non-trusted world public keys from the verified certificate.
+
+The next two steps are executed for each of the BL3-0, BL3-1 & BL3-2 images. The
+steps for the optional BL3-0 and BL3-2 images are skipped if these images are
+not present.
+
+* BL2 loads and verifies the BL3-x key certificate. The certificate signature
+ is verified using the trusted world public key. If the signature
+ verification succeeds, BL2 reads and saves the BL3-x public key from the
+ certificate.
+
+* BL2 loads and verifies the BL3-x content certificate. The signature is
+ verified using the BL3-x public key. If the signature verification succeeds,
+ BL2 reads and saves the BL3-x image hash from the certificate.
+
+The next two steps are executed only for the BL3-3 image.
+
+* BL2 loads and verifies the BL3-3 key certificate. If the signature
+ verification succeeds, BL2 reads and saves the BL3-3 public key from the
+ certificate.
+
+* BL2 loads and verifies the BL3-3 content certificate. If the signature
+ verification succeeds, BL2 reads and saves the BL3-3 image hash from the
+ certificate.
+
+The next step is executed for all the boot loader images.
+
+* BL2 calculates the hash of each image. It compares it with the hash obtained
+ from the corresponding content certificate. The image authentication succeeds
+ if the hashes match.
+
+The Trusted Board Boot implementation spans both generic and platform-specific
+BL1 and BL2 code, and in tool code on the host build machine. The feature is
+enabled through use of specific build flags as described in the [User Guide].
+
+On the host machine, a tool generates the certificates, which are included in
+the FIP along with the boot loader images. These certificates are loaded in
+Trusted SRAM using the IO storage framework. They are then verified by an
+Authentication module included in the Trusted Firmware.
+
+The mechanism used for generating the FIP and the Authentication module are
+described in the following sections.
+
+
+4. Authentication Module
+-------------------------
+
+The authentication module implements the required support to authenticate the
+corresponding certificates or images at each step in the Trusted Board Boot
+sequence. The module relies on the PolarSSL library (v1.3.9) to perform the
+following operations:
+
+* Parsing X.509 certificates and verifying them using SHA-1 with RSA
+ Encryption.
+* Extracting public keys and hashes from the certificates.
+* Generating hashes (SHA-256) of boot loader images
+
+At each step, the module is responsible for allocating memory to store the
+public keys or hashes that will be used in later steps. The step identifier is
+used to determine what information must be saved, according to the CoT model
+detailed in the previous sections.
+
+The authentication module resides in the `common/auth/polarssl` directory.
+Instructions for including the necessary modules of the PolarSSL SSL library and
+building the authentication module can be found in the [User Guide].
+
+
+5. Certificate Generation Tool
+-------------------------------
+
+The `cert_create` tool is built and runs on the host machine as part of the
+Trusted Firmware build process when `GENERATE_COT=1`. It takes the boot loader
+images and keys as inputs (keys must be in PEM format) and generates the
+certificates (in DER format) required to establish the CoT. New keys can be
+generated by the tool in case they are not provided. The certificates are then
+passed as inputs to the `fip_create` tool for creating the FIP.
+
+The certificates are also stored individually in the in the output build
+directory.
+
+The tool resides in the `tools/cert_create` directory. It uses OpenSSL SSL
+library version 1.0.1 or later to generate the X.509 certificates. Instructions
+for building and using the tool can be found in the [User Guide].
+
+
+- - - - - - - - - - - - - - - - - - - - - - - - - -
+
+_Copyright (c) 2015, ARM Limited and Contributors. All rights reserved._
+
+
+[X.509 v3]: http://www.ietf.org/rfc/rfc5280.txt
+[X.690]: http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
+[User Guide]: user-guide.md
diff --git a/docs/user-guide.md b/docs/user-guide.md
index 4209be7..fde8827 100644
--- a/docs/user-guide.md
+++ b/docs/user-guide.md
@@ -10,8 +10,7 @@
5. [Obtaining the normal world software](#5--obtaining-the-normal-world-software)
6. [Preparing the images to run on FVP](#6--preparing-the-images-to-run-on-fvp)
7. [Running the software on FVP](#7--running-the-software-on-fvp)
-8. [Preparing the images to run on Juno](#8--preparing-the-images-to-run-on-juno)
-9. [Running the software on Juno](#9--running-the-software-on-juno)
+8. [Running the software on Juno](#8--running-the-software-on-juno)
1. Introduction
@@ -60,7 +59,7 @@
wget http://releases.linaro.org/14.07/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.9-2014.07_linux.tar.xz
tar -xf gcc-linaro-aarch64-none-elf-4.9-2014.07_linux.tar.xz
-* (Optional) For debugging, ARM [Development Studio 5 (DS-5)][DS-5] v5.19.
+* (Optional) For debugging, ARM [Development Studio 5 (DS-5)][DS-5] v5.20.
4. Building the Trusted Firmware
@@ -256,6 +255,64 @@
default model (when the value is 0) is to route non-secure interrupts
to S-EL1 (TSP).
+* `TRUSTED_BOARD_BOOT`: Boolean flag to include support for the Trusted Board
+ Boot feature. When set to '1', BL1 and BL2 images include support to load
+ and verify the certificates and images in a FIP. The default value is '0'.
+ A successful build, when `TRUSTED_BOARD_BOOT=1`, depends upon the correct
+ initialization of the `AUTH_MOD` option. Generation and inclusion of
+ certificates in the FIP depends upon the value of the `GENERATE_COT` option.
+
+* `AUTH_MOD`: This option is used when `TRUSTED_BOARD_BOOT=1`. It specifies
+ the name of the authentication module that will be used in the Trusted Board
+ Boot sequence. The module must be located in `common/auth/<module name>`
+ directory. The directory must contain a makefile `<module name>.mk` which
+ will be used to build the module. More information can be found in
+ [Trusted Board Boot]. The default module name is 'none'.
+
+* `GENERATE_COT`: Boolean flag used to build and execute the `cert_create`
+ tool to create certificates as per the Chain of Trust described in
+ [Trusted Board Boot]. The build system then calls the `fip_create` tool to
+ include the certificates in the FIP. Default value is '0'.
+
+ Specify `TRUSTED_BOARD_BOOT=1` and `GENERATE_COT=1` to include support for
+ the Trusted Board Boot Sequence in the BL1 and BL2 images and the FIP.
+
+ Note that if `TRUSTED_BOARD_BOOT=0` and `GENERATE_COT=1`, the BL1 and BL2
+ images will not include support for Trusted Board Boot. The FIP will still
+ include the key and content certificates. This FIP can be used to verify the
+ Chain of Trust on the host machine through other mechanisms.
+
+ Note that if `TRUSTED_BOARD_BOOT=1` and `GENERATE_COT=0`, the BL1 and BL2
+ images will include support for Trusted Board Boot, but the FIP will not
+ include the key and content certificates, causing a boot failure.
+
+* `CREATE_KEYS`: This option is used when `GENERATE_COT=1`. It tells the
+ certificate generation tool to create new keys in case no valid keys are
+ present or specified. Allowed options are '0' or '1'. Default is '1'.
+
+* `ROT_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
+ file that contains the ROT private key in PEM format.
+
+* `TRUSTED_WORLD_KEY`: This option is used when `GENERATE_COT=1`. It
+ specifies the file that contains the Trusted World private key in PEM
+ format.
+
+* `NON_TRUSTED_WORLD_KEY`: This option is used when `GENERATE_COT=1`. It
+ specifies the file that contains the Non-Trusted World private key in PEM
+ format.
+
+* `BL30_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
+ file that contains the BL3-0 private key in PEM format.
+
+* `BL31_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
+ file that contains the BL3-1 private key in PEM format.
+
+* `BL32_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
+ file that contains the BL3-2 private key in PEM format.
+
+* `BL33_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
+ file that contains the BL3-3 private key in PEM format.
+
#### FVP specific build options
* `FVP_TSP_RAM_LOCATION`: location of the TSP binary. Options:
@@ -391,6 +448,48 @@
---------------------------
Creating "build/fvp/release/fip.bin"
+
+### Building the Certificate Generation Tool
+
+The `cert_create` tool can be built separately through the following commands:
+
+ $ cd tools/cert_create
+ $ make [DEBUG=1] [V=1]
+
+`DEBUG=1` builds the tool in debug mode. `V=1` makes the build process more
+verbose. The following command should be used to obtain help about the tool:
+
+ $ ./cert_create -h
+
+The `cert_create` tool is automatically built with the `fip` target when
+`GENERATE_COT=1`.
+
+
+### Building a FIP image with support for Trusted Board Boot
+
+The Trusted Board Boot feature is described in [Trusted Board Boot]. The
+following steps should be followed to build a FIP image with support for this
+feature.
+
+1. Fulfill the dependencies of the `polarssl` authentication module by checking
+ out the tag `polarssl-1.3.9` from the [PolarSSL Repository].
+
+ The `common/auth/polarssl/polarssl.mk` contains the list of PolarSSL source
+ files the module depends upon. `common/auth/polarssl/polarssl_config.h`
+ contains the configuration options required to build the PolarSSL sources.
+
+ Note that the PolarSSL SSL library is licensed under the GNU GPL version 2
+ or later license. Using PolarSSL source code will affect the licensing of
+ Trusted Firmware binaries that are built using this library.
+
+2. Ensure that the following command line variables are set while invoking
+ `make` to build Trusted Firmware:
+
+ * `POLARSSL_DIR=<path of the directory containing PolarSSL sources>`
+ * `AUTH_MOD=polarssl`
+ * `TRUSTED_BOARD_BOOT=1`
+ * `GENERATE_COT=1`
+
### Checking source code style
@@ -436,7 +535,7 @@
cd edk2
git remote add -f --tags arm-software https://github.com/ARM-software/edk2.git
- git checkout --detach v1.2
+ git checkout --detach v2.1-rc0
2. Copy build config templates to local workspace
@@ -511,11 +610,11 @@
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Not all required features are available in the kernel mainline yet. These
- can be obtained from the ARM-software EDK2 repository instead:
+ can be obtained from the ARM-software Linux repository instead:
cd linux
git remote add -f --tags arm-software https://github.com/ARM-software/linux.git
- git checkout --detach 1.1-Juno
+ git checkout --detach 1.3-Juno
2. Build with the Linaro GCC tools.
@@ -590,8 +689,8 @@
NOTE: The unpacked disk image grows to 3 GiB in size.
- wget http://releases.linaro.org/14.07/openembedded/aarch64/vexpress64-openembedded_lamp-armv8-gcc-4.9_20140727-682.img.gz
- gunzip vexpress64-openembedded_lamp-armv8-gcc-4.9_20140727-682.img.gz
+ wget http://releases.linaro.org/14.12/openembedded/aarch64/vexpress64-openembedded_lamp-armv8-gcc-4.9_20141211-701.img.gz
+ gunzip vexpress64-openembedded_lamp-armv8-gcc-4.9_20141211-701.img.gz
2. Make sure the Linux kernel has Virtio support enabled using
`make ARCH=arm64 menuconfig`.
@@ -653,14 +752,14 @@
1. Download the file-system image:
- wget http://releases.linaro.org/14.07/openembedded/aarch64/linaro-image-lamp-genericarmv8-20140727-701.rootfs.tar.gz
+ wget http://releases.linaro.org/14.12/openembedded/aarch64/linaro-image-lamp-genericarmv8-20141212-729.rootfs.tar.gz
2. Modify the Linaro image:
# Prepare for use as RAM-disk. Normally use MMC, NFS or VirtioBlock.
# Be careful, otherwise you could damage your host file-system.
mkdir tmp; cd tmp
- sudo sh -c "zcat ../linaro-image-lamp-genericarmv8-20140727-701.rootfs.tar.gz | cpio -id"
+ sudo sh -c "zcat ../linaro-image-lamp-genericarmv8-20141212-729.rootfs.tar.gz | cpio -id"
sudo ln -s sbin/init .
sudo sh -c "echo 'devtmpfs /dev devtmpfs mode=0755,nosuid 0 0' >> etc/fstab"
sudo sh -c "find . | cpio --quiet -H newc -o | gzip -3 -n > ../filesystem.cpio.gz"
@@ -676,11 +775,11 @@
This version of the ARM Trusted Firmware has been tested on the following ARM
FVPs (64-bit versions only).
-* `Foundation_v8` (Version 2.1, Build 9.0.24)
-* `FVP_Base_AEMv8A-AEMv8A` (Version 5.8, Build 0.8.5802)
-* `FVP_Base_Cortex-A57x4-A53x4` (Version 5.8, Build 0.8.5802)
-* `FVP_Base_Cortex-A57x1-A53x1` (Version 5.8, Build 0.8.5802)
-* `FVP_Base_Cortex-A57x2-A53x4` (Version 5.8, Build 0.8.5802)
+* `Foundation_Platform` (Version 9.1, Build 9.1.33)
+* `FVP_Base_AEMv8A-AEMv8A` (Version 6.2, Build 0.8.6202)
+* `FVP_Base_Cortex-A57x4-A53x4` (Version 6.2, Build 0.8.6202)
+* `FVP_Base_Cortex-A57x1-A53x1` (Version 6.2, Build 0.8.6202)
+* `FVP_Base_Cortex-A57x2-A53x4` (Version 6.2, Build 0.8.6202)
NOTE: The build numbers quoted above are those reported by launching the FVP
with the `--version` parameter.
@@ -700,7 +799,7 @@
### Running on the Foundation FVP with reset to BL1 entrypoint
-The following `Foundation_v8` parameters should be used to boot Linux with
+The following `Foundation_Platform` parameters should be used to boot Linux with
4 CPUs using the ARM Trusted Firmware.
NOTE: Using the `--block-device` parameter is not necessary if a Linux RAM-disk
@@ -710,7 +809,7 @@
Firmware Image Package at the start of NOR FLASH0 (see the "Building the
Trusted Firmware" section above).
- <path-to>/Foundation_v8 \
+ <path-to>/Foundation_Platform \
--cores=4 \
--secure-memory \
--visualization \
@@ -790,7 +889,6 @@
-C cluster0.NUM_CORES=4 \
-C cluster1.NUM_CORES=4 \
-C cache_state_modelled=1 \
- -C bp.pl011_uart0.untimed_fifos=1 \
-C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \
-C bp.flashloader0.fname="<path-to>/<FIP-binary>" \
-C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>"
@@ -808,7 +906,6 @@
-C bp.secure_memory=1 \
-C bp.tzc_400.diagnostics=1 \
-C cache_state_modelled=1 \
- -C bp.pl011_uart0.untimed_fifos=1 \
-C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \
-C bp.flashloader0.fname="<path-to>/<FIP-binary>" \
-C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>"
@@ -828,7 +925,6 @@
-C cluster0.NUM_CORES=4 \
-C cluster1.NUM_CORES=4 \
-C cache_state_modelled=1 \
- -C bp.pl011_uart0.untimed_fifos=1 \
-C cluster0.cpu0.RVBAR=0x04023000 \
-C cluster0.cpu1.RVBAR=0x04023000 \
-C cluster0.cpu2.RVBAR=0x04023000 \
@@ -855,7 +951,6 @@
-C bp.secure_memory=1 \
-C bp.tzc_400.diagnostics=1 \
-C cache_state_modelled=1 \
- -C bp.pl011_uart0.untimed_fifos=1 \
-C cluster0.cpu0.RVBARADDR=0x04023000 \
-C cluster0.cpu1.RVBARADDR=0x04023000 \
-C cluster0.cpu2.RVBARADDR=0x04023000 \
@@ -913,7 +1008,7 @@
The following parameters configure the Foundation FVP to use GICv2 with the
legacy VE memory map:
- <path-to>/Foundation_v8 \
+ <path-to>/Foundation_Platform \
--cores=4 \
--secure-memory \
--visualization \
@@ -950,14 +1045,21 @@
detect the legacy VE memory map while configuring the GIC.
-8. Preparing the images to run on Juno
----------------------------------------
+8. Running the software on Juno
+--------------------------------
### Preparing Trusted Firmware images
+To execute the versions of software components on Juno referred to in this
+document, the latest [Juno Board Recovery Image] must be installed. If you
+have an earlier version installed or are unsure which version is installed,
+follow the recovery image update instructions in the [Juno Software Guide]
+on the [ARM Connected Community] website.
+
The Juno platform requires a BL3-0 image to boot up. This image contains the
-runtime firmware that runs on the SCP (System Control Processor). It can be
-downloaded from [this ARM website] [SCP download] (requires registration).
+runtime firmware that runs on the SCP (System Control Processor). This image is
+embedded within the [Juno Board Recovery Image] but can also be
+[downloaded directly][Juno SCP Firmware].
Rebuild the Trusted Firmware specifying the BL3-0 image. Refer to the section
"Building the Trusted Firmware". Alternatively, the FIP image can be updated
@@ -971,92 +1073,29 @@
<path-to-linux>/arch/arm64/boot/dts/juno.dtb
-### Deploying a root filesystem on a USB mass storage device
-
-1. Format the partition on the USB mass storage as ext4 filesystem.
-
- A 2GB or larger USB mass storage device is required. If another filesystem
- type is preferred then support needs to be enabled in the kernel. For
- example, if the USB mass storage corresponds to /dev/sdb device on your
- computer, use the following command to format partition 1 as ext4:
-
- sudo mkfs.ext4 /dev/sdb1
-
- Note: Please be cautious with this command as it could format your hard
- drive instead if you specify the wrong device.
-
-2. Mount the USB mass storage on the computer (if not done automatically):
-
- sudo mount /dev/sdb1 /media/usb_storage
-
- where '/media/usb_storage' corresponds to the mount point (the directory
- must exist prior to using the mount command).
-
-3. Download the rootfs specified in section "Prepare RAM-disk" and extract the
- files as root user onto the formatted partition:
-
- sudo tar zxf <linaro-image>.tar.gz -C /media/usb_storage/
-
- Note: It is not necessary to modify the Linaro image as described in that
- section since we are not using a RAM-disk.
-
-5. Unmount the USB mass storage:
-
- sudo umount /media/usb_storage
-
+### Other Juno software information
-9. Running the software on Juno
---------------------------------
-
-The steps to install and run the binaries on Juno are as follows:
-
-1. Connect a serial cable to the UART0 port (the top UART port on the back
- panel). The UART settings are 115200 bauds, 8 bits data, no parity, 1 stop
- bit.
-
-2. Mount the Juno board storage via the CONFIG USB port
-
- This is the only USB type B port on the board, labelled DBG_USB and located
- on the back panel next to the ON/OFF and HW RESET buttons. Plug a type B USB
- cable into this port on the Juno board and plug the other end into a host
- PC, and then issue the following command in the UART0 session:
-
- Cmd> usb_on
-
- If the board doesn't show the Cmd> prompt then press the black HW RESET
- button once. Once the Juno board storage is detected by your PC, mount it
- (if not automatically done by your operating system).
-
- mount /dev/sdbX /media/JUNO
-
- For the rest of the installation instructions, we will assume that the Juno
- board storage has been mounted under the /media/JUNO directory.
-
-3. Copy the files obtained from the build process into /media/JUNO/SOFTWARE:
-
- bl1.bin
- fip.bin
- Image
- juno.dtb
-
-4. Umount the Juno board storage
-
- umount /media/JUNO
-
-5. Reboot the board. In the UART0 session, type:
+Please refer to the [Juno Software Guide] to:
- Cmd> reboot
+* Deploy a root filesystem
+* Install and run the Juno binaries on the board
+* Obtain any other Juno software information
- - - - - - - - - - - - - - - - - - - - - - - - - -
-_Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved._
+_Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._
[Firmware Design]: ./firmware-design.md
-[ARM FVP website]: http://www.arm.com/fvp
-[SCP download]: https://silver.arm.com/download/download.tm?pv=1764630
-[Linaro Toolchain]: http://releases.linaro.org/14.07/components/toolchain/binaries/
-[EDK2]: http://github.com/tianocore/edk2
-[DS-5]: http://www.arm.com/products/tools/software-tools/ds-5/index.php
+[ARM FVP website]: http://www.arm.com/fvp
+[ARM Connected Community]: http://community.arm.com
+[Juno Software Guide]: http://community.arm.com/docs/DOC-8396
+[Juno Board Recovery Image]: http://community.arm.com/servlet/JiveServlet/download/9427-1-15432/board_recovery_image_0.10.1.zip
+[Juno SCP Firmware]: http://community.arm.com/servlet/JiveServlet/download/9427-1-15422/bl30.bin.zip
+[Linaro Toolchain]: http://releases.linaro.org/14.07/components/toolchain/binaries/
+[EDK2]: http://github.com/tianocore/edk2
+[DS-5]: http://www.arm.com/products/tools/software-tools/ds-5/index.php
+[Polarssl Repository]: https://github.com/polarssl/polarssl.git
+[Trusted Board Boot]: trusted-board-boot.md