Merge branch 'upstream/master' into main
Change-Id: Id6f67665a9ee7f90cf5114727c525727a6c4cb19
diff --git a/.cz.json b/.cz.json
new file mode 100644
index 0000000..cb500ba
--- /dev/null
+++ b/.cz.json
@@ -0,0 +1,5 @@
+{
+ "path": "./node_modules/cz-conventional-changelog",
+ "maxHeaderWidth": 50,
+ "maxLineWidth": 72
+}
\ No newline at end of file
diff --git a/.editorconfig b/.editorconfig
index f523ca1..12f786d 100644
--- a/.editorconfig
+++ b/.editorconfig
@@ -1,5 +1,5 @@
#
-# Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.
+# Copyright (c) 2017-2020, Arm Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -38,10 +38,10 @@
insert_final_newline = true
# [LCS] Chapter 2: Breaking long lines and strings
-# "The limit on the length of lines is 80 columns"
+# "The limit on the length of lines is 100 columns"
# This is a "soft" requirement for Arm-TF, and should not be the sole
# reason for changes.
-max_line_length = 80
+max_line_length = 100
# [LCS] Chapter 1: Indentation
# "Tabs are 8 characters"
diff --git a/.gitignore b/.gitignore
index 64b389b..f524658 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,10 @@
tools/renesas/rcar_layout_create/*.srec
tools/renesas/rcar_layout_create/*.map
tools/renesas/rcar_layout_create/*.elf
+tools/renesas/rzg_layout_create/*.bin
+tools/renesas/rzg_layout_create/*.srec
+tools/renesas/rzg_layout_create/*.map
+tools/renesas/rzg_layout_create/*.elf
tools/fiptool/fiptool
tools/fiptool/fiptool.exe
tools/cert_create/src/*.o
@@ -38,3 +42,5 @@
# Ctags
tags
+# Node.js
+node_modules/
diff --git a/.husky/.gitignore b/.husky/.gitignore
new file mode 100644
index 0000000..31354ec
--- /dev/null
+++ b/.husky/.gitignore
@@ -0,0 +1 @@
+_
diff --git a/.husky/commit-msg b/.husky/commit-msg
new file mode 100755
index 0000000..c1c9600
--- /dev/null
+++ b/.husky/commit-msg
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+# shellcheck source=./_/husky.sh
+. "$(dirname "$0")/_/husky.sh"
+
+"$(dirname "$0")/commit-msg.gerrit" "$@"
+"$(dirname "$0")/commit-msg.commitlint" "$@"
diff --git a/.husky/commit-msg.commitlint b/.husky/commit-msg.commitlint
new file mode 100755
index 0000000..ca25ce1
--- /dev/null
+++ b/.husky/commit-msg.commitlint
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+npx --no-install commitlint --edit "$1"
diff --git a/.husky/commit-msg.gerrit b/.husky/commit-msg.gerrit
new file mode 100755
index 0000000..b8ce477
--- /dev/null
+++ b/.husky/commit-msg.gerrit
@@ -0,0 +1,194 @@
+#!/bin/sh
+# From Gerrit Code Review 2.14.20
+#
+# Part of Gerrit Code Review (https://www.gerritcodereview.com/)
+#
+# Copyright (C) 2009 The Android Open Source Project
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+unset GREP_OPTIONS
+
+CHANGE_ID_AFTER="Bug|Depends-On|Issue|Test|Feature|Fixes|Fixed"
+MSG="$1"
+
+# Check for, and add if missing, a unique Change-Id
+#
+add_ChangeId() {
+ clean_message=`sed -e '
+ /^diff --git .*/{
+ s///
+ q
+ }
+ /^Signed-off-by:/d
+ /^#/d
+ ' "$MSG" | git stripspace`
+ if test -z "$clean_message"
+ then
+ return
+ fi
+
+ # Do not add Change-Id to temp commits
+ if echo "$clean_message" | head -1 | grep -q '^\(fixup\|squash\)!'
+ then
+ return
+ fi
+
+ if test "false" = "`git config --bool --get gerrit.createChangeId`"
+ then
+ return
+ fi
+
+ # Does Change-Id: already exist? if so, exit (no change).
+ if grep -i '^Change-Id:' "$MSG" >/dev/null
+ then
+ return
+ fi
+
+ id=`_gen_ChangeId`
+ T="$MSG.tmp.$$"
+ AWK=awk
+ if [ -x /usr/xpg4/bin/awk ]; then
+ # Solaris AWK is just too broken
+ AWK=/usr/xpg4/bin/awk
+ fi
+
+ # Get core.commentChar from git config or use default symbol
+ commentChar=`git config --get core.commentChar`
+ commentChar=${commentChar:-#}
+
+ # How this works:
+ # - parse the commit message as (textLine+ blankLine*)*
+ # - assume textLine+ to be a footer until proven otherwise
+ # - exception: the first block is not footer (as it is the title)
+ # - read textLine+ into a variable
+ # - then count blankLines
+ # - once the next textLine appears, print textLine+ blankLine* as these
+ # aren't footer
+ # - in END, the last textLine+ block is available for footer parsing
+ $AWK '
+ BEGIN {
+ if (match(ENVIRON["OS"], "Windows")) {
+ RS="\r?\n" # Required on recent Cygwin
+ }
+ # while we start with the assumption that textLine+
+ # is a footer, the first block is not.
+ isFooter = 0
+ footerComment = 0
+ blankLines = 0
+ }
+
+ # Skip lines starting with commentChar without any spaces before it.
+ /^'"$commentChar"'/ { next }
+
+ # Skip the line starting with the diff command and everything after it,
+ # up to the end of the file, assuming it is only patch data.
+ # If more than one line before the diff was empty, strip all but one.
+ /^diff --git / {
+ blankLines = 0
+ while (getline) { }
+ next
+ }
+
+ # Count blank lines outside footer comments
+ /^$/ && (footerComment == 0) {
+ blankLines++
+ next
+ }
+
+ # Catch footer comment
+ /^\[[a-zA-Z0-9-]+:/ && (isFooter == 1) {
+ footerComment = 1
+ }
+
+ /]$/ && (footerComment == 1) {
+ footerComment = 2
+ }
+
+ # We have a non-blank line after blank lines. Handle this.
+ (blankLines > 0) {
+ print lines
+ for (i = 0; i < blankLines; i++) {
+ print ""
+ }
+
+ lines = ""
+ blankLines = 0
+ isFooter = 1
+ footerComment = 0
+ }
+
+ # Detect that the current block is not the footer
+ (footerComment == 0) && (!/^\[?[a-zA-Z0-9-]+:/ || /^[a-zA-Z0-9-]+:\/\//) {
+ isFooter = 0
+ }
+
+ {
+ # We need this information about the current last comment line
+ if (footerComment == 2) {
+ footerComment = 0
+ }
+ if (lines != "") {
+ lines = lines "\n";
+ }
+ lines = lines $0
+ }
+
+ # Footer handling:
+ # If the last block is considered a footer, splice in the Change-Id at the
+ # right place.
+ # Look for the right place to inject Change-Id by considering
+ # CHANGE_ID_AFTER. Keys listed in it (case insensitive) come first,
+ # then Change-Id, then everything else (eg. Signed-off-by:).
+ #
+ # Otherwise just print the last block, a new line and the Change-Id as a
+ # block of its own.
+ END {
+ unprinted = 1
+ if (isFooter == 0) {
+ print lines "\n"
+ lines = ""
+ }
+ changeIdAfter = "^(" tolower("'"$CHANGE_ID_AFTER"'") "):"
+ numlines = split(lines, footer, "\n")
+ for (line = 1; line <= numlines; line++) {
+ if (unprinted && match(tolower(footer[line]), changeIdAfter) != 1) {
+ unprinted = 0
+ print "Change-Id: I'"$id"'"
+ }
+ print footer[line]
+ }
+ if (unprinted) {
+ print "Change-Id: I'"$id"'"
+ }
+ }' "$MSG" > "$T" && mv "$T" "$MSG" || rm -f "$T"
+}
+_gen_ChangeIdInput() {
+ echo "tree `git write-tree`"
+ if parent=`git rev-parse "HEAD^0" 2>/dev/null`
+ then
+ echo "parent $parent"
+ fi
+ echo "author `git var GIT_AUTHOR_IDENT`"
+ echo "committer `git var GIT_COMMITTER_IDENT`"
+ echo
+ printf '%s' "$clean_message"
+}
+_gen_ChangeId() {
+ _gen_ChangeIdInput |
+ git hash-object -t commit --stdin
+}
+
+
+add_ChangeId
diff --git a/.husky/prepare-commit-msg b/.husky/prepare-commit-msg
new file mode 100755
index 0000000..593dfa8
--- /dev/null
+++ b/.husky/prepare-commit-msg
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+# shellcheck source=./_/husky.sh
+. "$(dirname "$0")/_/husky.sh"
+
+"$(dirname "$0")/prepare-commit-msg.cz" "$@"
diff --git a/.husky/prepare-commit-msg.cz b/.husky/prepare-commit-msg.cz
new file mode 100755
index 0000000..724527d
--- /dev/null
+++ b/.husky/prepare-commit-msg.cz
@@ -0,0 +1,28 @@
+#!/bin/bash
+
+file="$1"
+type="$2"
+
+if [ -z "$type" ]; then # only run on new commits
+ #
+ # Save any commit message trailers generated by Git.
+ #
+
+ trailers=$(git interpret-trailers --parse "$file")
+
+ #
+ # Execute the Commitizen hook.
+ #
+
+ (exec < "/dev/tty" && npx --no-install git-cz --hook) || true
+
+ #
+ # Restore any trailers that Commitizen might have overwritten.
+ #
+
+ printf "\n" >> "$file"
+
+ while IFS= read -r trailer; do
+ git interpret-trailers --in-place --trailer "$trailer" "$file"
+ done <<< "$trailers"
+fi
diff --git a/Makefile b/Makefile
index 5c9186e..4905291 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
#
-# Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+# Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -8,7 +8,7 @@
# Trusted Firmware Version
#
VERSION_MAJOR := 2
-VERSION_MINOR := 4
+VERSION_MINOR := 5
# Default goal is build all images
.DEFAULT_GOAL := all
@@ -129,12 +129,27 @@
$(error Unknown BRANCH_PROTECTION value ${BRANCH_PROTECTION})
endif
+# FEAT_RME
+ifeq (${ENABLE_RME},1)
+# RME doesn't support PIE
+ifneq (${ENABLE_PIE},0)
+ $(error ENABLE_RME does not support PIE)
+endif
+# RME requires AARCH64
+ifneq (${ARCH},aarch64)
+ $(error ENABLE_RME requires AArch64)
+endif
+# RME requires el2 context to be saved for now.
+CTX_INCLUDE_EL2_REGS := 1
+CTX_INCLUDE_AARCH32_REGS := 0
+ARM_ARCH_MAJOR := 8
+ARM_ARCH_MINOR := 6
+endif
+
# USE_SPINLOCK_CAS requires AArch64 build
ifeq (${USE_SPINLOCK_CAS},1)
ifneq (${ARCH},aarch64)
$(error USE_SPINLOCK_CAS requires AArch64)
-else
- $(info USE_SPINLOCK_CAS is an experimental feature)
endif
endif
@@ -185,13 +200,14 @@
else
target32-directive = -target armv8a-none-eabi
-# Set the compiler's target architecture profile based on ARM_ARCH_MINOR option
+# Set the compiler's target architecture profile based on
+# ARM_ARCH_MAJOR ARM_ARCH_MINOR options
ifeq (${ARM_ARCH_MINOR},0)
-march32-directive = -march=armv8-a
-march64-directive = -march=armv8-a
+march32-directive = -march=armv${ARM_ARCH_MAJOR}-a
+march64-directive = -march=armv${ARM_ARCH_MAJOR}-a
else
-march32-directive = -march=armv8.${ARM_ARCH_MINOR}-a
-march64-directive = -march=armv8.${ARM_ARCH_MINOR}-a
+march32-directive = -march=armv${ARM_ARCH_MAJOR}.${ARM_ARCH_MINOR}-a
+march64-directive = -march=armv${ARM_ARCH_MAJOR}.${ARM_ARCH_MINOR}-a
endif
endif
@@ -203,22 +219,52 @@
endif
endif
-# Enabled required option for memory stack tagging. Currently, these options are
-# enabled only for clang and armclang compiler.
+# Get architecture feature modifiers
+arch-features = ${ARM_ARCH_FEATURE}
+
+# Enable required options for memory stack tagging.
+# Currently, these options are enabled only for clang and armclang compiler.
ifeq (${SUPPORT_STACK_MEMTAG},yes)
ifdef mem_tag_arch_support
+# Check for armclang and clang compilers
ifneq ( ,$(filter $(notdir $(CC)),armclang clang))
-march64-directive = -march=armv${ARM_ARCH_MAJOR}.${ARM_ARCH_MINOR}-a+memtag
+# Add "memtag" architecture feature modifier if not specified
+ifeq ( ,$(findstring memtag,$(arch-features)))
+arch-features := $(arch-features)+memtag
+endif # memtag
ifeq ($(notdir $(CC)),armclang)
TF_CFLAGS += -mmemtag-stack
else ifeq ($(notdir $(CC)),clang)
TF_CFLAGS += -fsanitize=memtag
-endif
-endif
+endif # armclang
+endif # armclang clang
else
$(error "Error: stack memory tagging is not supported for architecture \
${ARCH},armv${ARM_ARCH_MAJOR}.${ARM_ARCH_MINOR}-a")
+endif # mem_tag_arch_support
+endif # SUPPORT_STACK_MEMTAG
+
+# Set the compiler's architecture feature modifiers
+ifneq ($(arch-features), none)
+# Strip "none+" from arch-features
+arch-features := $(subst none+,,$(arch-features))
+ifeq ($(ARCH), aarch32)
+march32-directive := $(march32-directive)+$(arch-features)
+else
+march64-directive := $(march64-directive)+$(arch-features)
endif
+# Print features
+$(info Arm Architecture Features specified: $(subst +, ,$(arch-features)))
+endif # arch-features
+
+# Determine if FEAT_RNG is supported
+ENABLE_FEAT_RNG = $(if $(findstring rng,${arch-features}),1,0)
+
+# Determine if FEAT_SB is supported
+ENABLE_FEAT_SB = $(if $(findstring sb,${arch-features}),1,0)
+
+ifeq "8.5" "$(word 1, $(sort 8.5 $(ARM_ARCH_MAJOR).$(ARM_ARCH_MINOR)))"
+ENABLE_FEAT_SB = 1
endif
ifneq ($(findstring armclang,$(notdir $(CC))),)
@@ -303,7 +349,7 @@
# General warnings
WARNINGS := -Wall -Wmissing-include-dirs -Wunused \
- -Wdisabled-optimization -Wvla -Wshadow \
+ -Wdisabled-optimization -Wvla -Wshadow \
-Wno-unused-parameter -Wredundant-decls
# Additional warnings
@@ -477,7 +523,6 @@
endif
ifeq (${SPD},spmd)
- $(warning "SPMD is an experimental feature")
# SPMD is located in std_svc directory
SPD_DIR := std_svc
@@ -490,6 +535,18 @@
ifeq ($(findstring optee_sp,$(ARM_SPMC_MANIFEST_DTS)),optee_sp)
DTC_CPPFLAGS += -DOPTEE_SP_FW_CONFIG
endif
+
+ ifeq ($(TS_SP_FW_CONFIG),1)
+ DTC_CPPFLAGS += -DTS_SP_FW_CONFIG
+ endif
+
+ ifneq ($(ARM_BL2_SP_LIST_DTS),)
+ DTC_CPPFLAGS += -DARM_BL2_SP_LIST_DTS=$(ARM_BL2_SP_LIST_DTS)
+ endif
+
+ ifneq ($(SP_LAYOUT_FILE),)
+ BL2_ENABLE_SP_LOAD := 1
+ endif
else
# All other SPDs in spd directory
SPD_DIR := spd
@@ -516,6 +573,18 @@
endif
################################################################################
+# Include rmmd Makefile if RME is enabled
+################################################################################
+
+ifneq (${ENABLE_RME},0)
+ifneq (${ARCH},aarch64)
+ $(error ENABLE_RME requires AArch64)
+endif
+include services/std_svc/rmmd/rmmd.mk
+$(warning "RME is an experimental feature")
+endif
+
+################################################################################
# Include the platform specific Makefile after the SPD Makefile (the platform
# makefile may use all previous definitions in this file)
################################################################################
@@ -548,11 +617,9 @@
endif
BL31_CFLAGS += -fpie
BL31_LDFLAGS += $(PIE_LDFLAGS)
-ifeq ($(ARCH),aarch64)
BL32_CFLAGS += -fpie
BL32_LDFLAGS += $(PIE_LDFLAGS)
endif
-endif
ifeq (${ARCH},aarch64)
BL1_CPPFLAGS += -DIMAGE_AT_EL3
@@ -661,12 +728,7 @@
# SDEI_IN_FCONF is only supported when SDEI_SUPPORT is enabled.
ifeq ($(SDEI_SUPPORT)-$(SDEI_IN_FCONF),0-1)
-$(error "SDEI_IN_FCONF is an experimental feature and is only supported when \
- SDEI_SUPPORT is enabled")
-endif
-
-ifeq ($(COT_DESC_IN_DTB),1)
- $(info CoT in device tree is an experimental feature)
+$(error "SDEI_IN_FCONF is only supported when SDEI_SUPPORT is enabled")
endif
# If pointer authentication is used in the firmware, make sure that all the
@@ -681,35 +743,28 @@
ifeq ($(CTX_INCLUDE_PAUTH_REGS),1)
ifneq (${ARCH},aarch64)
$(error CTX_INCLUDE_PAUTH_REGS requires AArch64)
- else
- $(info CTX_INCLUDE_PAUTH_REGS is an experimental feature)
endif
endif
-ifeq ($(ENABLE_PAUTH),1)
- $(info Pointer Authentication is an experimental feature)
-endif
-
-ifeq ($(ENABLE_BTI),1)
- $(info Branch Protection is an experimental feature)
-endif
-
ifeq ($(CTX_INCLUDE_MTE_REGS),1)
ifneq (${ARCH},aarch64)
$(error CTX_INCLUDE_MTE_REGS requires AArch64)
- else
- $(info CTX_INCLUDE_MTE_REGS is an experimental feature)
endif
endif
+# Trusted Boot is a prerequisite for Measured Boot. It provides trust that the
+# code taking the measurements and recording them has not been tampered
+# with. This is referred to as the Root of Trust for Measurement.
ifeq ($(MEASURED_BOOT),1)
ifneq (${TRUSTED_BOARD_BOOT},1)
$(error MEASURED_BOOT requires TRUSTED_BOARD_BOOT=1)
- else
- $(info MEASURED_BOOT is an experimental feature)
endif
endif
+ifeq ($(PSA_FWU_SUPPORT),1)
+ $(info PSA_FWU_SUPPORT is an experimental feature)
+endif
+
ifeq (${ARM_XLAT_TABLES_LIB_V1}, 1)
ifeq (${ALLOW_RO_XLAT_TABLES}, 1)
$(error "ALLOW_RO_XLAT_TABLES requires translation tables library v2")
@@ -719,8 +774,52 @@
ifneq (${DECRYPTION_SUPPORT},none)
ifeq (${TRUSTED_BOARD_BOOT}, 0)
$(error TRUSTED_BOARD_BOOT must be enabled for DECRYPTION_SUPPORT to be set)
- else
- $(info DECRYPTION_SUPPORT is an experimental feature)
+ endif
+endif
+
+# SME/SVE only supported on AArch64
+ifeq (${ARCH},aarch32)
+ ifeq (${ENABLE_SME_FOR_NS},1)
+ $(error "ENABLE_SME_FOR_NS cannot be used with ARCH=aarch32")
+ endif
+ ifeq (${ENABLE_SVE_FOR_NS},1)
+ # Warning instead of error due to CI dependency on this
+ $(warning "ENABLE_SVE_FOR_NS cannot be used with ARCH=aarch32")
+ $(warning "Forced ENABLE_SVE_FOR_NS=0")
+ override ENABLE_SVE_FOR_NS := 0
+ endif
+endif
+
+# Ensure ENABLE_RME is not used with SME
+ifeq (${ENABLE_RME},1)
+ ifeq (${ENABLE_SME_FOR_NS},1)
+ $(error "ENABLE_SME_FOR_NS cannot be used with ENABLE_RME")
+ endif
+endif
+
+# Secure SME/SVE requires the non-secure component as well
+ifeq (${ENABLE_SME_FOR_SWD},1)
+ ifeq (${ENABLE_SME_FOR_NS},0)
+ $(error "ENABLE_SME_FOR_SWD requires ENABLE_SME_FOR_NS")
+ endif
+endif
+ifeq (${ENABLE_SVE_FOR_SWD},1)
+ ifeq (${ENABLE_SVE_FOR_NS},0)
+ $(error "ENABLE_SVE_FOR_SWD requires ENABLE_SVE_FOR_NS")
+ endif
+endif
+
+# SVE and SME cannot be used with CTX_INCLUDE_FPREGS since secure manager does
+# its own context management including FPU registers.
+ifeq (${CTX_INCLUDE_FPREGS},1)
+ ifeq (${ENABLE_SME_FOR_NS},1)
+ $(error "ENABLE_SME_FOR_NS cannot be used with CTX_INCLUDE_FPREGS")
+ endif
+ ifeq (${ENABLE_SVE_FOR_NS},1)
+ # Warning instead of error due to CI dependency on this
+ $(warning "ENABLE_SVE_FOR_NS cannot be used with CTX_INCLUDE_FPREGS")
+ $(warning "Forced ENABLE_SVE_FOR_NS=0")
+ override ENABLE_SVE_FOR_NS := 0
endif
endif
@@ -728,10 +827,16 @@
# Process platform overrideable behaviour
################################################################################
-# Using BL2 implies that a BL33 image also needs to be supplied for the FIP and
-# Certificate generation tools. This flag can be overridden by the platform.
+ifdef BL1_SOURCES
+NEED_BL1 := yes
+endif
+
ifdef BL2_SOURCES
- ifdef EL3_PAYLOAD_BASE
+ NEED_BL2 := yes
+
+ # Using BL2 implies that a BL33 image also needs to be supplied for the FIP and
+ # Certificate generation tools. This flag can be overridden by the platform.
+ ifdef EL3_PAYLOAD_BASE
# If booting an EL3 payload there is no need for a BL33 image
# in the FIP file.
NEED_BL33 := no
@@ -746,6 +851,10 @@
endif
endif
+ifdef BL2U_SOURCES
+NEED_BL2U := yes
+endif
+
# If SCP_BL2 is given, we always want FIP to include it.
ifdef SCP_BL2
NEED_SCP_BL2 := yes
@@ -783,6 +892,10 @@
FIP_ARGS += --align ${FIP_ALIGN}
endif
+ifdef FDT_SOURCES
+NEED_FDT := yes
+endif
+
################################################################################
# Include libraries' Makefile that are used in all BL
################################################################################
@@ -826,30 +939,22 @@
################################################################################
# Include BL specific makefiles
################################################################################
-ifdef BL1_SOURCES
-NEED_BL1 := yes
+
+ifeq (${NEED_BL1},yes)
include bl1/bl1.mk
endif
-ifdef BL2_SOURCES
-NEED_BL2 := yes
+ifeq (${NEED_BL2},yes)
include bl2/bl2.mk
endif
-ifdef BL2U_SOURCES
-NEED_BL2U := yes
+ifeq (${NEED_BL2U},yes)
include bl2u/bl2u.mk
endif
ifeq (${NEED_BL31},yes)
-ifdef BL31_SOURCES
include bl31/bl31.mk
endif
-endif
-
-ifdef FDT_SOURCES
-NEED_FDT := yes
-endif
################################################################################
# Build options checks
@@ -858,6 +963,7 @@
$(eval $(call assert_booleans,\
$(sort \
ALLOW_RO_XLAT_TABLES \
+ BL2_ENABLE_SP_LOAD \
COLD_BOOT_SINGLE_CPU \
CREATE_KEYS \
CTX_INCLUDE_AARCH32_REGS \
@@ -867,17 +973,25 @@
CTX_INCLUDE_EL2_REGS \
CTX_INCLUDE_NEVE_REGS \
DEBUG \
+ DISABLE_MTPMU \
DYN_DISABLE_AUTH \
EL3_EXCEPTION_HANDLING \
ENABLE_AMU \
+ ENABLE_AMU_AUXILIARY_COUNTERS \
+ ENABLE_AMU_FCONF \
+ AMU_RESTRICT_COUNTERS \
ENABLE_ASSERTIONS \
ENABLE_MPAM_FOR_LOWER_ELS \
ENABLE_PIE \
ENABLE_PMF \
ENABLE_PSCI_STAT \
+ ENABLE_RME \
ENABLE_RUNTIME_INSTRUMENTATION \
+ ENABLE_SME_FOR_NS \
+ ENABLE_SME_FOR_SWD \
ENABLE_SPE_FOR_LOWER_ELS \
ENABLE_SVE_FOR_NS \
+ ENABLE_SVE_FOR_SWD \
ERROR_DEPRECATED \
FAULT_INJECTION_SUPPORT \
GENERATE_COT \
@@ -918,6 +1032,15 @@
RAS_TRAP_LOWER_EL_ERR_ACCESS \
COT_DESC_IN_DTB \
USE_SP804_TIMER \
+ ENABLE_FEAT_RNG \
+ ENABLE_FEAT_SB \
+ PSA_FWU_SUPPORT \
+ ENABLE_TRBE_FOR_NS \
+ ENABLE_SYS_REG_TRACE_FOR_NS \
+ ENABLE_TRF_FOR_NS \
+ ENABLE_FEAT_HCX \
+ ENABLE_MPMM \
+ ENABLE_MPMM_FCONF \
)))
$(eval $(call assert_numerics,\
@@ -926,6 +1049,8 @@
ARM_ARCH_MINOR \
BRANCH_PROTECTION \
FW_ENC_STATUS \
+ NR_OF_FW_BANKS \
+ NR_OF_IMAGES_IN_FW_BANK \
)))
ifdef KEY_SIZE
@@ -947,6 +1072,7 @@
ALLOW_RO_XLAT_TABLES \
ARM_ARCH_MAJOR \
ARM_ARCH_MINOR \
+ BL2_ENABLE_SP_LOAD \
COLD_BOOT_SINGLE_CPU \
CTX_INCLUDE_AARCH32_REGS \
CTX_INCLUDE_FPREGS \
@@ -956,7 +1082,11 @@
CTX_INCLUDE_EL2_REGS \
CTX_INCLUDE_NEVE_REGS \
DECRYPTION_SUPPORT_${DECRYPTION_SUPPORT} \
+ DISABLE_MTPMU \
ENABLE_AMU \
+ ENABLE_AMU_AUXILIARY_COUNTERS \
+ ENABLE_AMU_FCONF \
+ AMU_RESTRICT_COUNTERS \
ENABLE_ASSERTIONS \
ENABLE_BTI \
ENABLE_MPAM_FOR_LOWER_ELS \
@@ -964,9 +1094,13 @@
ENABLE_PIE \
ENABLE_PMF \
ENABLE_PSCI_STAT \
+ ENABLE_RME \
ENABLE_RUNTIME_INSTRUMENTATION \
+ ENABLE_SME_FOR_NS \
+ ENABLE_SME_FOR_SWD \
ENABLE_SPE_FOR_LOWER_ELS \
ENABLE_SVE_FOR_NS \
+ ENABLE_SVE_FOR_SWD \
ENCRYPT_BL31 \
ENCRYPT_BL32 \
ERROR_DEPRECATED \
@@ -991,6 +1125,7 @@
SPM_MM \
SPMD_SPM_AT_SEL2 \
TRUSTED_BOARD_BOOT \
+ TRNG_SUPPORT \
USE_COHERENT_MEM \
USE_DEBUGFS \
ARM_IO_IN_DTB \
@@ -1007,6 +1142,17 @@
RAS_TRAP_LOWER_EL_ERR_ACCESS \
COT_DESC_IN_DTB \
USE_SP804_TIMER \
+ ENABLE_FEAT_RNG \
+ ENABLE_FEAT_SB \
+ NR_OF_FW_BANKS \
+ NR_OF_IMAGES_IN_FW_BANK \
+ PSA_FWU_SUPPORT \
+ ENABLE_TRBE_FOR_NS \
+ ENABLE_SYS_REG_TRACE_FOR_NS \
+ ENABLE_TRF_FOR_NS \
+ ENABLE_FEAT_HCX \
+ ENABLE_MPMM \
+ ENABLE_MPMM_FCONF \
)))
ifeq (${SANITIZE_UB},trap)
@@ -1036,9 +1182,6 @@
# Generate and include sp_gen.mk if SPD is spmd and SP_LAYOUT_FILE is defined
ifeq (${SPD},spmd)
ifdef SP_LAYOUT_FILE
- ifeq (${SPMD_SPM_AT_SEL2},0)
- $(error "SPMD with SPM at S-EL1 does not require SP_LAYOUT_FILE")
- endif
-include $(BUILD_PLAT)/sp_gen.mk
FIP_DEPS += sp
CRT_DEPS += sp
@@ -1076,7 +1219,9 @@
# Expand build macros for the different images
ifeq (${NEED_BL1},yes)
-$(eval $(call MAKE_BL,1))
+BL1_SOURCES := $(sort ${BL1_SOURCES})
+
+$(eval $(call MAKE_BL,bl1))
endif
ifeq (${NEED_BL2},yes)
@@ -1084,8 +1229,10 @@
FIP_BL2_ARGS := tb-fw
endif
+BL2_SOURCES := $(sort ${BL2_SOURCES})
+
$(if ${BL2}, $(eval $(call TOOL_ADD_IMG,bl2,--${FIP_BL2_ARGS})),\
- $(eval $(call MAKE_BL,2,${FIP_BL2_ARGS})))
+ $(eval $(call MAKE_BL,bl2,${FIP_BL2_ARGS})))
endif
ifeq (${NEED_SCP_BL2},yes)
@@ -1098,10 +1245,10 @@
BL31_SOURCES := $(sort ${BL31_SOURCES})
ifneq (${DECRYPTION_SUPPORT},none)
$(if ${BL31}, $(eval $(call TOOL_ADD_IMG,bl31,--soc-fw,,$(ENCRYPT_BL31))),\
- $(eval $(call MAKE_BL,31,soc-fw,,$(ENCRYPT_BL31))))
+ $(eval $(call MAKE_BL,bl31,soc-fw,,$(ENCRYPT_BL31))))
else
$(if ${BL31}, $(eval $(call TOOL_ADD_IMG,bl31,--soc-fw)),\
- $(eval $(call MAKE_BL,31,soc-fw)))
+ $(eval $(call MAKE_BL,bl31,soc-fw)))
endif
endif
@@ -1114,14 +1261,25 @@
BUILD_BL32 := $(if $(BL32),,$(if $(BL32_SOURCES),1))
ifneq (${DECRYPTION_SUPPORT},none)
-$(if ${BUILD_BL32}, $(eval $(call MAKE_BL,32,tos-fw,,$(ENCRYPT_BL32))),\
+$(if ${BUILD_BL32}, $(eval $(call MAKE_BL,bl32,tos-fw,,$(ENCRYPT_BL32))),\
$(eval $(call TOOL_ADD_IMG,bl32,--tos-fw,,$(ENCRYPT_BL32))))
else
-$(if ${BUILD_BL32}, $(eval $(call MAKE_BL,32,tos-fw)),\
+$(if ${BUILD_BL32}, $(eval $(call MAKE_BL,bl32,tos-fw)),\
$(eval $(call TOOL_ADD_IMG,bl32,--tos-fw)))
endif
endif
+# If RMM image is needed but RMM is not defined, Test Realm Payload (TRP)
+# needs to be built from RMM_SOURCES.
+ifeq (${NEED_RMM},yes)
+# Sort RMM source files to remove duplicates
+RMM_SOURCES := $(sort ${RMM_SOURCES})
+BUILD_RMM := $(if $(RMM),,$(if $(RMM_SOURCES),1))
+
+$(if ${BUILD_RMM}, $(eval $(call MAKE_BL,rmm,rmm-fw)),\
+ $(eval $(call TOOL_ADD_IMG,rmm,--rmm-fw)))
+endif
+
# Add the BL33 image if required by the platform
ifeq (${NEED_BL33},yes)
$(eval $(call TOOL_ADD_IMG,bl33,--nt-fw))
@@ -1129,7 +1287,7 @@
ifeq (${NEED_BL2U},yes)
$(if ${BL2U}, $(eval $(call TOOL_ADD_IMG,bl2u,--ap-fwu-cfg,FWU_)),\
- $(eval $(call MAKE_BL,2u,ap-fwu-cfg,FWU_)))
+ $(eval $(call MAKE_BL,bl2u,ap-fwu-cfg,FWU_)))
endif
# Expand build macros for the different images
@@ -1210,7 +1368,8 @@
echo " with ${CHECKPATCH_OPTS} option(s)"; \
fi
${Q}COMMON_COMMIT=$$(git merge-base HEAD ${BASE_COMMIT}); \
- for commit in `git rev-list $$COMMON_COMMIT..HEAD`; do \
+ for commit in `git rev-list --no-merges $$COMMON_COMMIT..HEAD`; \
+ do \
printf "\n[*] Checking style of '$$commit'\n\n"; \
git log --format=email "$$commit~..$$commit" \
-- ${CHECK_PATHS} | \
@@ -1222,8 +1381,7 @@
certtool: ${CRTTOOL}
-.PHONY: ${CRTTOOL}
-${CRTTOOL}:
+${CRTTOOL}: FORCE
${Q}${MAKE} PLAT=${PLAT} USE_TBBR_DEFS=${USE_TBBR_DEFS} COT=${COT} OPENSSL_DIR=${OPENSSL_DIR} CRTTOOL=${CRTTOOL} --no-print-directory -C ${CRTTOOLPATH}
@${ECHO_BLANK_LINE}
@echo "Built $@ successfully"
@@ -1239,6 +1397,7 @@
endif
${BUILD_PLAT}/${FIP_NAME}: ${FIP_DEPS} ${FIPTOOL}
+ $(eval ${CHECK_FIP_CMD})
${Q}${FIPTOOL} create ${FIP_ARGS} $@
${Q}${FIPTOOL} info $@
@${ECHO_BLANK_LINE}
@@ -1255,6 +1414,7 @@
endif
${BUILD_PLAT}/${FWU_FIP_NAME}: ${FWU_FIP_DEPS} ${FIPTOOL}
+ $(eval ${CHECK_FWU_FIP_CMD})
${Q}${FIPTOOL} create ${FWU_FIP_ARGS} $@
${Q}${FIPTOOL} info $@
@${ECHO_BLANK_LINE}
@@ -1265,10 +1425,7 @@
fip: ${BUILD_PLAT}/${FIP_NAME}
fwu_fip: ${BUILD_PLAT}/${FWU_FIP_NAME}
-.PHONY: ${FIPTOOL}
-${FIPTOOL}:
- @${ECHO_BLANK_LINE}
- @echo "Building $@"
+${FIPTOOL}: FORCE
ifdef UNIX_MK
${Q}${MAKE} CPPFLAGS="-DVERSION='\"${VERSION_STRING}\"'" FIPTOOL=${FIPTOOL} --no-print-directory -C ${FIPTOOLPATH}
else
@@ -1276,15 +1433,12 @@
# to pass the gnumake flags to nmake.
${Q}set MAKEFLAGS= && ${MSVC_NMAKE} /nologo /f ${FIPTOOLPATH}/Makefile.msvc FIPTOOLPATH=$(subst /,\,$(FIPTOOLPATH)) FIPTOOL=$(subst /,\,$(FIPTOOL))
endif
- @${ECHO_BLANK_LINE}
sptool: ${SPTOOL}
-.PHONY: ${SPTOOL}
-${SPTOOL}:
+${SPTOOL}: FORCE
${Q}${MAKE} CPPFLAGS="-DVERSION='\"${VERSION_STRING}\"'" SPTOOL=${SPTOOL} --no-print-directory -C ${SPTOOLPATH}
-.PHONY: libraries
-romlib.bin: libraries
+romlib.bin: libraries FORCE
${Q}${MAKE} PLAT_DIR=${PLAT_DIR} BUILD_PLAT=${BUILD_PLAT} ENABLE_BTI=${ENABLE_BTI} ARM_ARCH_MINOR=${ARM_ARCH_MINOR} INCLUDES='${INCLUDES}' DEFINES='${DEFINES}' --no-print-directory -C ${ROMLIBPATH} all
# Call print_memory_map tool
@@ -1297,8 +1451,7 @@
enctool: ${ENCTOOL}
-.PHONY: ${ENCTOOL}
-${ENCTOOL}:
+${ENCTOOL}: FORCE
${Q}${MAKE} PLAT=${PLAT} BUILD_INFO=0 OPENSSL_DIR=${OPENSSL_DIR} ENCTOOL=${ENCTOOL} --no-print-directory -C ${ENCTOOLPATH}
@${ECHO_BLANK_LINE}
@echo "Built $@ successfully"
@@ -1352,3 +1505,6 @@
@echo ""
@echo "example: build all targets for the FVP platform:"
@echo " CROSS_COMPILE=aarch64-none-elf- make PLAT=fvp all"
+
+.PHONY: FORCE
+FORCE:;
diff --git a/bl1/aarch32/bl1_entrypoint.S b/bl1/aarch32/bl1_entrypoint.S
index 6a15566..94dfd37 100644
--- a/bl1/aarch32/bl1_entrypoint.S
+++ b/bl1/aarch32/bl1_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2016-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2016-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -49,7 +49,8 @@
_secondary_cold_boot=!COLD_BOOT_SINGLE_CPU \
_init_memory=1 \
_init_c_runtime=1 \
- _exception_vectors=bl1_vector_table
+ _exception_vectors=bl1_vector_table \
+ _pie_fixup_size=0
/* -----------------------------------------------------
* Perform BL1 setup
diff --git a/bl1/aarch64/bl1_context_mgmt.c b/bl1/aarch64/bl1_context_mgmt.c
index 2a8d58e..b9a7e5b 100644
--- a/bl1/aarch64/bl1_context_mgmt.c
+++ b/bl1/aarch64/bl1_context_mgmt.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2015-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -16,6 +16,7 @@
/* Following contains the cpu context pointers. */
static void *bl1_cpu_context_ptr[2];
+entry_point_info_t *bl2_ep_info;
void *cm_get_context(uint32_t security_state)
@@ -30,6 +31,40 @@
bl1_cpu_context_ptr[security_state] = context;
}
+#if ENABLE_RME
+/*******************************************************************************
+ * This function prepares the entry point information to run BL2 in Root world,
+ * i.e. EL3, for the case when FEAT_RME is enabled.
+ ******************************************************************************/
+void bl1_prepare_next_image(unsigned int image_id)
+{
+ image_desc_t *bl2_desc;
+
+ assert(image_id == BL2_IMAGE_ID);
+
+ /* Get the image descriptor. */
+ bl2_desc = bl1_plat_get_image_desc(BL2_IMAGE_ID);
+ assert(bl2_desc != NULL);
+
+ /* Get the entry point info. */
+ bl2_ep_info = &bl2_desc->ep_info;
+
+ bl2_ep_info->spsr = (uint32_t)SPSR_64(MODE_EL3, MODE_SP_ELX,
+ DISABLE_ALL_EXCEPTIONS);
+
+ /*
+ * Flush cache since bl2_ep_info is accessed after MMU is disabled
+ * before jumping to BL2.
+ */
+ flush_dcache_range((uintptr_t)bl2_ep_info, sizeof(entry_point_info_t));
+
+ /* Indicate that image is in execution state. */
+ bl2_desc->state = IMAGE_STATE_EXECUTED;
+
+ /* Print debug info and flush the console before running BL2. */
+ print_entry_point_info(bl2_ep_info);
+}
+#else
/*******************************************************************************
* This function prepares the context for Secure/Normal world images.
* Normal world images are transitioned to EL2(if supported) else EL1.
@@ -93,3 +128,4 @@
print_entry_point_info(next_bl_ep);
}
+#endif /* ENABLE_RME */
diff --git a/bl1/aarch64/bl1_entrypoint.S b/bl1/aarch64/bl1_entrypoint.S
index 00f2718..f61c060 100644
--- a/bl1/aarch64/bl1_entrypoint.S
+++ b/bl1/aarch64/bl1_entrypoint.S
@@ -1,13 +1,15 @@
/*
- * Copyright (c) 2013-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
#include <arch.h>
+#include <common/bl_common.h>
#include <el3_common_macros.S>
.globl bl1_entrypoint
+ .globl bl1_run_bl2_in_root
/* -----------------------------------------------------
@@ -66,5 +68,41 @@
* Do the transition to next boot image.
* --------------------------------------------------
*/
+#if ENABLE_RME
+ b bl1_run_bl2_in_root
+#else
b el3_exit
+#endif
endfunc bl1_entrypoint
+
+ /* -----------------------------------------------------
+ * void bl1_run_bl2_in_root();
+ * This function runs BL2 in root/EL3 when RME is enabled.
+ * -----------------------------------------------------
+ */
+
+func bl1_run_bl2_in_root
+ /* read bl2_ep_info */
+ adrp x20, bl2_ep_info
+ add x20, x20, :lo12:bl2_ep_info
+ ldr x20, [x20]
+
+ /* ---------------------------------------------
+ * MMU needs to be disabled because BL2 executes
+ * in EL3. It will initialize the address space
+ * according to its own requirements.
+ * ---------------------------------------------
+ */
+ bl disable_mmu_icache_el3
+ tlbi alle3
+
+ ldp x0, x1, [x20, #ENTRY_POINT_INFO_PC_OFFSET]
+ msr elr_el3, x0
+ msr spsr_el3, x1
+
+ ldp x6, x7, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x30)]
+ ldp x4, x5, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x20)]
+ ldp x2, x3, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x10)]
+ ldp x0, x1, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x0)]
+ exception_return
+endfunc bl1_run_bl2_in_root
diff --git a/bl1/bl1.mk b/bl1/bl1.mk
index b839990..9f63fd5 100644
--- a/bl1/bl1.mk
+++ b/bl1/bl1.mk
@@ -1,14 +1,14 @@
#
-# Copyright (c) 2013-2019, ARM Limited and Contributors. All rights reserved.
+# Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
-BL1_SOURCES += bl1/bl1_main.c \
- bl1/${ARCH}/bl1_arch_setup.c \
+BL1_SOURCES += bl1/${ARCH}/bl1_arch_setup.c \
bl1/${ARCH}/bl1_context_mgmt.c \
bl1/${ARCH}/bl1_entrypoint.S \
bl1/${ARCH}/bl1_exceptions.S \
+ bl1/bl1_main.c \
lib/cpus/${ARCH}/cpu_helpers.S \
lib/cpus/errata_report.c \
lib/el3_runtime/${ARCH}/context_mgmt.c \
@@ -16,6 +16,10 @@
plat/common/${ARCH}/platform_up_stack.S \
${MBEDTLS_SOURCES}
+ifeq (${DISABLE_MTPMU},1)
+BL1_SOURCES += lib/extensions/mtpmu/${ARCH}/mtpmu.S
+endif
+
ifeq (${ARCH},aarch64)
BL1_SOURCES += lib/cpus/aarch64/dsu_helpers.S \
lib/el3_runtime/aarch64/context.S
diff --git a/bl1/bl1_main.c b/bl1/bl1_main.c
index fd60232..663ec64 100644
--- a/bl1/bl1_main.c
+++ b/bl1/bl1_main.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -126,6 +126,9 @@
auth_mod_init();
#endif /* TRUSTED_BOARD_BOOT */
+ /* Initialize the measured boot */
+ bl1_plat_mboot_init();
+
/* Perform platform setup in BL1. */
bl1_platform_setup();
@@ -147,6 +150,9 @@
else
NOTICE("BL1-FWU: *******FWU Process Started*******\n");
+ /* Teardown the measured boot driver */
+ bl1_plat_mboot_finish();
+
bl1_prepare_next_image(image_id);
console_flush();
diff --git a/bl1/bl1_private.h b/bl1/bl1_private.h
index 2cfeeea..e119ba7 100644
--- a/bl1/bl1_private.h
+++ b/bl1/bl1_private.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -11,6 +11,8 @@
#include <common/bl_common.h>
+extern entry_point_info_t *bl2_ep_info;
+
/******************************************
* Function prototypes
*****************************************/
@@ -18,6 +20,7 @@
void bl1_arch_next_el_setup(void);
void bl1_prepare_next_image(unsigned int image_id);
+void bl1_run_bl2_in_root(void);
u_register_t bl1_fwu_smc_handler(unsigned int smc_fid,
u_register_t x1,
diff --git a/bl2/aarch32/bl2_el3_entrypoint.S b/bl2/aarch32/bl2_el3_entrypoint.S
index 2e851e6..40154aa 100644
--- a/bl2/aarch32/bl2_el3_entrypoint.S
+++ b/bl2/aarch32/bl2_el3_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2017-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2017-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -10,7 +10,6 @@
#include <el3_common_macros.S>
.globl bl2_entrypoint
- .globl bl2_run_next_image
func bl2_entrypoint
@@ -26,7 +25,8 @@
_secondary_cold_boot=!COLD_BOOT_SINGLE_CPU \
_init_memory=1 \
_init_c_runtime=1 \
- _exception_vectors=bl2_vector_table
+ _exception_vectors=bl2_vector_table \
+ _pie_fixup_size=0
/*
* Restore parameters of boot rom
@@ -55,37 +55,3 @@
no_ret plat_panic_handler
endfunc bl2_entrypoint
-
-func bl2_run_next_image
- mov r8,r0
-
- /*
- * MMU needs to be disabled because both BL2 and BL32 execute
- * in PL1, and therefore share the same address space.
- * BL32 will initialize the address space according to its
- * own requirement.
- */
- bl disable_mmu_icache_secure
- stcopr r0, TLBIALL
- dsb sy
- isb
- mov r0, r8
- bl bl2_el3_plat_prepare_exit
-
- /*
- * Extract PC and SPSR based on struct `entry_point_info_t`
- * and load it in LR and SPSR registers respectively.
- */
- ldr lr, [r8, #ENTRY_POINT_INFO_PC_OFFSET]
- ldr r1, [r8, #(ENTRY_POINT_INFO_PC_OFFSET + 4)]
- msr spsr_xc, r1
-
- /* Some BL32 stages expect lr_svc to provide the BL33 entry address */
- cps #MODE32_svc
- ldr lr, [r8, #ENTRY_POINT_INFO_LR_SVC_OFFSET]
- cps #MODE32_mon
-
- add r8, r8, #ENTRY_POINT_INFO_ARGS_OFFSET
- ldm r8, {r0, r1, r2, r3}
- exception_return
-endfunc bl2_run_next_image
diff --git a/bl2/aarch32/bl2_entrypoint.S b/bl2/aarch32/bl2_entrypoint.S
index 102fd2f..6e8e2c1 100644
--- a/bl2/aarch32/bl2_entrypoint.S
+++ b/bl2/aarch32/bl2_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2016-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2016-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -80,12 +80,14 @@
* ---------------------------------------------
*/
ldr r0, =__BSS_START__
- ldr r1, =__BSS_SIZE__
+ ldr r1, =__BSS_END__
+ sub r1, r1, r0
bl zeromem
#if USE_COHERENT_MEM
ldr r0, =__COHERENT_RAM_START__
- ldr r1, =__COHERENT_RAM_UNALIGNED_SIZE__
+ ldr r1, =__COHERENT_RAM_END_UNALIGNED__
+ sub r1, r1, r0
bl zeromem
#endif
diff --git a/bl2/aarch32/bl2_run_next_image.S b/bl2/aarch32/bl2_run_next_image.S
new file mode 100644
index 0000000..0b3554e
--- /dev/null
+++ b/bl2/aarch32/bl2_run_next_image.S
@@ -0,0 +1,46 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include <arch.h>
+#include <asm_macros.S>
+#include <common/bl_common.h>
+
+ .globl bl2_run_next_image
+
+
+func bl2_run_next_image
+ mov r8,r0
+
+ /*
+ * MMU needs to be disabled because both BL2 and BL32 execute
+ * in PL1, and therefore share the same address space.
+ * BL32 will initialize the address space according to its
+ * own requirement.
+ */
+ bl disable_mmu_icache_secure
+ stcopr r0, TLBIALL
+ dsb sy
+ isb
+ mov r0, r8
+ bl bl2_el3_plat_prepare_exit
+
+ /*
+ * Extract PC and SPSR based on struct `entry_point_info_t`
+ * and load it in LR and SPSR registers respectively.
+ */
+ ldr lr, [r8, #ENTRY_POINT_INFO_PC_OFFSET]
+ ldr r1, [r8, #(ENTRY_POINT_INFO_PC_OFFSET + 4)]
+ msr spsr_xc, r1
+
+ /* Some BL32 stages expect lr_svc to provide the BL33 entry address */
+ cps #MODE32_svc
+ ldr lr, [r8, #ENTRY_POINT_INFO_LR_SVC_OFFSET]
+ cps #MODE32_mon
+
+ add r8, r8, #ENTRY_POINT_INFO_ARGS_OFFSET
+ ldm r8, {r0, r1, r2, r3}
+ exception_return
+endfunc bl2_run_next_image
diff --git a/bl2/aarch64/bl2_el3_entrypoint.S b/bl2/aarch64/bl2_el3_entrypoint.S
index 4eab39c..45bac7d 100644
--- a/bl2/aarch64/bl2_el3_entrypoint.S
+++ b/bl2/aarch64/bl2_el3_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2017-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2017-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -12,8 +12,6 @@
#include <el3_common_macros.S>
.globl bl2_entrypoint
- .globl bl2_el3_run_image
- .globl bl2_run_next_image
#if BL2_IN_XIP_MEM
#define FIXUP_SIZE 0
@@ -72,36 +70,3 @@
*/
no_ret plat_panic_handler
endfunc bl2_entrypoint
-
-func bl2_run_next_image
- mov x20,x0
- /* ---------------------------------------------
- * MMU needs to be disabled because both BL2 and BL31 execute
- * in EL3, and therefore share the same address space.
- * BL31 will initialize the address space according to its
- * own requirement.
- * ---------------------------------------------
- */
- bl disable_mmu_icache_el3
- tlbi alle3
- bl bl2_el3_plat_prepare_exit
-
-#if ENABLE_PAUTH
- /* ---------------------------------------------
- * Disable pointer authentication before jumping
- * to next boot image.
- * ---------------------------------------------
- */
- bl pauth_disable_el3
-#endif /* ENABLE_PAUTH */
-
- ldp x0, x1, [x20, #ENTRY_POINT_INFO_PC_OFFSET]
- msr elr_el3, x0
- msr spsr_el3, x1
-
- ldp x6, x7, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x30)]
- ldp x4, x5, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x20)]
- ldp x2, x3, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x10)]
- ldp x0, x1, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x0)]
- exception_return
-endfunc bl2_run_next_image
diff --git a/bl2/aarch64/bl2_rme_entrypoint.S b/bl2/aarch64/bl2_rme_entrypoint.S
new file mode 100644
index 0000000..076e326
--- /dev/null
+++ b/bl2/aarch64/bl2_rme_entrypoint.S
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include <platform_def.h>
+
+#include <arch.h>
+#include <asm_macros.S>
+#include <common/bl_common.h>
+#include <el3_common_macros.S>
+
+ .globl bl2_entrypoint
+
+
+func bl2_entrypoint
+ /* Save arguments x0-x3 from previous Boot loader */
+ mov x20, x0
+ mov x21, x1
+ mov x22, x2
+ mov x23, x3
+
+ el3_entrypoint_common \
+ _init_sctlr=0 \
+ _warm_boot_mailbox=0 \
+ _secondary_cold_boot=0 \
+ _init_memory=0 \
+ _init_c_runtime=1 \
+ _exception_vectors=bl2_el3_exceptions \
+ _pie_fixup_size=0
+
+ /* ---------------------------------------------
+ * Restore parameters of boot rom
+ * ---------------------------------------------
+ */
+ mov x0, x20
+ mov x1, x21
+ mov x2, x22
+ mov x3, x23
+
+ /* ---------------------------------------------
+ * Perform BL2 setup
+ * ---------------------------------------------
+ */
+ bl bl2_setup
+
+#if ENABLE_PAUTH
+ /* ---------------------------------------------
+ * Program APIAKey_EL1 and enable pointer authentication.
+ * ---------------------------------------------
+ */
+ bl pauth_init_enable_el3
+#endif /* ENABLE_PAUTH */
+
+ /* ---------------------------------------------
+ * Jump to main function.
+ * ---------------------------------------------
+ */
+ bl bl2_main
+
+ /* ---------------------------------------------
+ * Should never reach this point.
+ * ---------------------------------------------
+ */
+ no_ret plat_panic_handler
+endfunc bl2_entrypoint
diff --git a/bl2/aarch64/bl2_run_next_image.S b/bl2/aarch64/bl2_run_next_image.S
new file mode 100644
index 0000000..f0a8be8
--- /dev/null
+++ b/bl2/aarch64/bl2_run_next_image.S
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include <arch.h>
+#include <asm_macros.S>
+#include <common/bl_common.h>
+
+ .globl bl2_run_next_image
+
+
+func bl2_run_next_image
+ mov x20,x0
+ /* ---------------------------------------------
+ * MMU needs to be disabled because both BL2 and BL31 execute
+ * in EL3, and therefore share the same address space.
+ * BL31 will initialize the address space according to its
+ * own requirement.
+ * ---------------------------------------------
+ */
+ bl disable_mmu_icache_el3
+ tlbi alle3
+ bl bl2_el3_plat_prepare_exit
+
+#if ENABLE_PAUTH
+ /* ---------------------------------------------
+ * Disable pointer authentication before jumping
+ * to next boot image.
+ * ---------------------------------------------
+ */
+ bl pauth_disable_el3
+#endif /* ENABLE_PAUTH */
+
+ ldp x0, x1, [x20, #ENTRY_POINT_INFO_PC_OFFSET]
+ msr elr_el3, x0
+ msr spsr_el3, x1
+
+ ldp x6, x7, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x30)]
+ ldp x4, x5, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x20)]
+ ldp x2, x3, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x10)]
+ ldp x0, x1, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x0)]
+ exception_return
+endfunc bl2_run_next_image
diff --git a/bl2/bl2.ld.S b/bl2/bl2.ld.S
index 37849c3..d332ec0 100644
--- a/bl2/bl2.ld.S
+++ b/bl2/bl2.ld.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -25,7 +25,11 @@
#if SEPARATE_CODE_AND_RODATA
.text . : {
__TEXT_START__ = .;
+#if ENABLE_RME
+ *bl2_rme_entrypoint.o(.text*)
+#else /* ENABLE_RME */
*bl2_entrypoint.o(.text*)
+#endif /* ENABLE_RME */
*(SORT_BY_ALIGNMENT(.text*))
*(.vectors)
. = ALIGN(PAGE_SIZE);
diff --git a/bl2/bl2.mk b/bl2/bl2.mk
index 6dc0f18..7a973e5 100644
--- a/bl2/bl2.mk
+++ b/bl2/bl2.mk
@@ -1,5 +1,5 @@
#
-# Copyright (c) 2013-2019, ARM Limited and Contributors. All rights reserved.
+# Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -15,16 +15,33 @@
BL2_SOURCES += common/aarch64/early_exceptions.S
endif
-ifeq (${BL2_AT_EL3},0)
+ifeq (${ENABLE_RME},1)
+# Using RME, run BL2 at EL3
+include lib/gpt_rme/gpt_rme.mk
+
+BL2_SOURCES += bl2/${ARCH}/bl2_rme_entrypoint.S \
+ bl2/${ARCH}/bl2_el3_exceptions.S \
+ bl2/${ARCH}/bl2_run_next_image.S \
+ ${GPT_LIB_SRCS}
+BL2_LINKERFILE := bl2/bl2.ld.S
+
+else ifeq (${BL2_AT_EL3},0)
+# Normal operation, no RME, no BL2 at EL3
BL2_SOURCES += bl2/${ARCH}/bl2_entrypoint.S
BL2_LINKERFILE := bl2/bl2.ld.S
else
+# BL2 at EL3, no RME
BL2_SOURCES += bl2/${ARCH}/bl2_el3_entrypoint.S \
bl2/${ARCH}/bl2_el3_exceptions.S \
+ bl2/${ARCH}/bl2_run_next_image.S \
lib/cpus/${ARCH}/cpu_helpers.S \
lib/cpus/errata_report.c
+ifeq (${DISABLE_MTPMU},1)
+BL2_SOURCES += lib/extensions/mtpmu/${ARCH}/mtpmu.S
+endif
+
ifeq (${ARCH},aarch64)
BL2_SOURCES += lib/cpus/aarch64/dsu_helpers.S
endif
diff --git a/bl2/bl2_main.c b/bl2/bl2_main.c
index 203e1d4..90fe39b 100644
--- a/bl2/bl2_main.c
+++ b/bl2/bl2_main.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -14,9 +14,7 @@
#include <common/debug.h>
#include <drivers/auth/auth_mod.h>
#include <drivers/console.h>
-#if MEASURED_BOOT
-#include <drivers/measured_boot/measured_boot.h>
-#endif
+#include <drivers/fwu/fwu.h>
#include <lib/extensions/pauth.h>
#include <plat/common/platform.h>
@@ -28,31 +26,9 @@
#define NEXT_IMAGE "BL32"
#endif
-#if !BL2_AT_EL3
+#if BL2_AT_EL3
/*******************************************************************************
- * Setup function for BL2.
- ******************************************************************************/
-void bl2_setup(u_register_t arg0, u_register_t arg1, u_register_t arg2,
- u_register_t arg3)
-{
- /* Perform early platform-specific setup */
- bl2_early_platform_setup2(arg0, arg1, arg2, arg3);
-
- /* Perform late platform-specific setup */
- bl2_plat_arch_setup();
-
-#if CTX_INCLUDE_PAUTH_REGS
- /*
- * Assert that the ARMv8.3-PAuth registers are present or an access
- * fault will be triggered when they are being saved or restored.
- */
- assert(is_armv8_3_pauth_present());
-#endif /* CTX_INCLUDE_PAUTH_REGS */
-}
-
-#else /* if BL2_AT_EL3 */
-/*******************************************************************************
- * Setup function for BL2 when BL2_AT_EL3=1.
+ * Setup function for BL2 when BL2_AT_EL3=1
******************************************************************************/
void bl2_el3_setup(u_register_t arg0, u_register_t arg1, u_register_t arg2,
u_register_t arg3)
@@ -71,6 +47,27 @@
assert(is_armv8_3_pauth_present());
#endif /* CTX_INCLUDE_PAUTH_REGS */
}
+#else /* BL2_AT_EL3 */
+/*******************************************************************************
+ * Setup function for BL2 when BL2_AT_EL3=0
+ ******************************************************************************/
+void bl2_setup(u_register_t arg0, u_register_t arg1, u_register_t arg2,
+ u_register_t arg3)
+{
+ /* Perform early platform-specific setup */
+ bl2_early_platform_setup2(arg0, arg1, arg2, arg3);
+
+ /* Perform late platform-specific setup */
+ bl2_plat_arch_setup();
+
+#if CTX_INCLUDE_PAUTH_REGS
+ /*
+ * Assert that the ARMv8.3-PAuth registers are present or an access
+ * fault will be triggered when they are being saved or restored.
+ */
+ assert(is_armv8_3_pauth_present());
+#endif /* CTX_INCLUDE_PAUTH_REGS */
+}
#endif /* BL2_AT_EL3 */
/*******************************************************************************
@@ -88,29 +85,28 @@
/* Perform remaining generic architectural setup in S-EL1 */
bl2_arch_setup();
+#if PSA_FWU_SUPPORT
+ fwu_init();
+#endif /* PSA_FWU_SUPPORT */
+
#if TRUSTED_BOARD_BOOT
/* Initialize authentication module */
auth_mod_init();
-
-#if MEASURED_BOOT
- /* Initialize measured boot module */
- measured_boot_init();
-
-#endif /* MEASURED_BOOT */
#endif /* TRUSTED_BOARD_BOOT */
+ /* Initialize the Measured Boot backend */
+ bl2_plat_mboot_init();
+
/* Initialize boot source */
bl2_plat_preload_setup();
/* Load the subsequent bootloader images. */
next_bl_ep_info = bl2_load_images();
-#if MEASURED_BOOT
- /* Finalize measured boot */
- measured_boot_finish();
-#endif /* MEASURED_BOOT */
+ /* Teardown the Measured Boot backend */
+ bl2_plat_mboot_finish();
-#if !BL2_AT_EL3
+#if !BL2_AT_EL3 && !ENABLE_RME
#ifndef __aarch64__
/*
* For AArch32 state BL1 and BL2 share the MMU setup.
@@ -135,7 +131,7 @@
* be passed to next BL image as an argument.
*/
smc(BL1_SMC_RUN_IMAGE, (unsigned long)next_bl_ep_info, 0, 0, 0, 0, 0, 0);
-#else /* if BL2_AT_EL3 */
+#else /* if BL2_AT_EL3 || ENABLE_RME */
NOTICE("BL2: Booting " NEXT_IMAGE "\n");
print_entry_point_info(next_bl_ep_info);
console_flush();
@@ -148,5 +144,5 @@
#endif /* ENABLE_PAUTH */
bl2_run_next_image(next_bl_ep_info);
-#endif /* BL2_AT_EL3 */
+#endif /* BL2_AT_EL3 && ENABLE_RME */
}
diff --git a/bl2u/aarch32/bl2u_entrypoint.S b/bl2u/aarch32/bl2u_entrypoint.S
index 6391f53..e4dd03d 100644
--- a/bl2u/aarch32/bl2u_entrypoint.S
+++ b/bl2u/aarch32/bl2u_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2016-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2016-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -79,7 +79,8 @@
* ---------------------------------------------
*/
ldr r0, =__BSS_START__
- ldr r1, =__BSS_SIZE__
+ ldr r1, =__BSS_END__
+ sub r1, r1, r0
bl zeromem
/* --------------------------------------------
diff --git a/bl2u/aarch64/bl2u_entrypoint.S b/bl2u/aarch64/bl2u_entrypoint.S
index 3e37b44..15978b6 100644
--- a/bl2u/aarch64/bl2u_entrypoint.S
+++ b/bl2u/aarch64/bl2u_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2015-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -69,8 +69,11 @@
* - the coherent memory section.
* ---------------------------------------------
*/
- ldr x0, =__BSS_START__
- ldr x1, =__BSS_SIZE__
+ adrp x0, __BSS_START__
+ add x0, x0, :lo12:__BSS_START__
+ adrp x1, __BSS_END__
+ add x1, x1, :lo12:__BSS_END__
+ sub x1, x1, x0
bl zeromem
/* --------------------------------------------
diff --git a/bl31/aarch64/bl31_entrypoint.S b/bl31/aarch64/bl31_entrypoint.S
index 2d672dd..ed05864 100644
--- a/bl31/aarch64/bl31_entrypoint.S
+++ b/bl31/aarch64/bl31_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -195,6 +195,19 @@
#endif
bl bl31_plat_enable_mmu
+#if ENABLE_RME
+ /*
+ * At warm boot GPT data structures have already been initialized in RAM
+ * but the sysregs for this CPU need to be initialized. Note that the GPT
+ * accesses are controlled attributes in GPCCR and do not depend on the
+ * SCR_EL3.C bit.
+ */
+ bl gpt_enable
+ cbz x0, 1f
+ no_ret plat_panic_handler
+1:
+#endif
+
#if ENABLE_PAUTH
/* --------------------------------------------------------------------
* Program APIAKey_EL1 and enable pointer authentication
diff --git a/bl31/aarch64/ea_delegate.S b/bl31/aarch64/ea_delegate.S
index 1d28d5e..f9c789f 100644
--- a/bl31/aarch64/ea_delegate.S
+++ b/bl31/aarch64/ea_delegate.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2018-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2018-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -15,6 +15,7 @@
#include <context.h>
.globl handle_lower_el_ea_esb
+ .globl handle_lower_el_async_ea
.globl enter_lower_el_sync_ea
.globl enter_lower_el_async_ea
@@ -133,6 +134,7 @@
*/
str x30, [sp, #CTX_GPREGS_OFFSET + CTX_GPREG_LR]
+handle_lower_el_async_ea:
/*
* Save general purpose and ARMv8.3-PAuth registers (if enabled).
* If Secure Cycle Counter is not disabled in MDCR_EL3 when
diff --git a/bl31/aarch64/runtime_exceptions.S b/bl31/aarch64/runtime_exceptions.S
index bfe13f3..0d0a12d 100644
--- a/bl31/aarch64/runtime_exceptions.S
+++ b/bl31/aarch64/runtime_exceptions.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -45,8 +45,9 @@
* instruction. When an error is thus synchronized, the handling is
* delegated to platform EA handler.
*
- * Without RAS_EXTENSION, this macro just saves x30, and unmasks
- * Asynchronous External Aborts.
+ * Without RAS_EXTENSION, this macro synchronizes pending errors using
+ * a DSB, unmasks Asynchronous External Aborts and saves X30 before
+ * setting the flag CTX_IS_IN_EL3.
*/
.macro check_and_unmask_ea
#if RAS_EXTENSION
@@ -79,13 +80,89 @@
bl restore_gp_pmcr_pauth_regs
1:
#else
+ /*
+ * For SoCs which do not implement RAS, use DSB as a barrier to
+ * synchronize pending external aborts.
+ */
+ dsb sy
+
/* Unmask the SError interrupt */
msr daifclr, #DAIF_ABT_BIT
+ /* Use ISB for the above unmask operation to take effect immediately */
+ isb
+
+ /*
+ * Refer Note 1. No need to restore X30 as both handle_sync_exception
+ * and handle_interrupt_exception macro which follow this macro modify
+ * X30 anyway.
+ */
str x30, [sp, #CTX_GPREGS_OFFSET + CTX_GPREG_LR]
+ mov x30, #1
+ str x30, [sp, #CTX_EL3STATE_OFFSET + CTX_IS_IN_EL3]
+ dmb sy
#endif
.endm
+#if !RAS_EXTENSION
+ /*
+ * Note 1: The explicit DSB at the entry of various exception vectors
+ * for handling exceptions from lower ELs can inadvertently trigger an
+ * SError exception in EL3 due to pending asynchronous aborts in lower
+ * ELs. This will end up being handled by serror_sp_elx which will
+ * ultimately panic and die.
+ * The way to workaround is to update a flag to indicate if the exception
+ * truly came from EL3. This flag is allocated in the cpu_context
+ * structure and located at offset "CTX_EL3STATE_OFFSET + CTX_IS_IN_EL3"
+ * This is not a bullet proof solution to the problem at hand because
+ * we assume the instructions following "isb" that help to update the
+ * flag execute without causing further exceptions.
+ */
+
+ /* ---------------------------------------------------------------------
+ * This macro handles Asynchronous External Aborts.
+ * ---------------------------------------------------------------------
+ */
+ .macro handle_async_ea
+ /*
+ * Use a barrier to synchronize pending external aborts.
+ */
+ dsb sy
+
+ /* Unmask the SError interrupt */
+ msr daifclr, #DAIF_ABT_BIT
+
+ /* Use ISB for the above unmask operation to take effect immediately */
+ isb
+
+ /* Refer Note 1 */
+ str x30, [sp, #CTX_GPREGS_OFFSET + CTX_GPREG_LR]
+ mov x30, #1
+ str x30, [sp, #CTX_EL3STATE_OFFSET + CTX_IS_IN_EL3]
+ dmb sy
+
+ b handle_lower_el_async_ea
+ .endm
+
+ /*
+ * This macro checks if the exception was taken due to SError in EL3 or
+ * because of pending asynchronous external aborts from lower EL that got
+ * triggered due to explicit synchronization in EL3. Refer Note 1.
+ */
+ .macro check_if_serror_from_EL3
+ /* Assumes SP_EL3 on entry */
+ str x30, [sp, #CTX_GPREGS_OFFSET + CTX_GPREG_LR]
+ ldr x30, [sp, #CTX_EL3STATE_OFFSET + CTX_IS_IN_EL3]
+ cbnz x30, exp_from_EL3
+
+ /* Handle asynchronous external abort from lower EL */
+ b handle_lower_el_async_ea
+
+exp_from_EL3:
+ /* Jump to plat_handle_el3_ea which does not return */
+ .endm
+#endif
+
/* ---------------------------------------------------------------------
* This macro handles Synchronous exceptions.
* Only SMC exceptions are supported.
@@ -272,6 +349,9 @@
end_vector_entry fiq_sp_elx
vector_entry serror_sp_elx
+#if !RAS_EXTENSION
+ check_if_serror_from_EL3
+#endif
no_ret plat_handle_el3_ea
end_vector_entry serror_sp_elx
@@ -305,8 +385,12 @@
vector_entry serror_aarch64
apply_at_speculative_wa
+#if RAS_EXTENSION
msr daifclr, #DAIF_ABT_BIT
b enter_lower_el_async_ea
+#else
+ handle_async_ea
+#endif
end_vector_entry serror_aarch64
/* ---------------------------------------------------------------------
@@ -339,8 +423,12 @@
vector_entry serror_aarch32
apply_at_speculative_wa
+#if RAS_EXTENSION
msr daifclr, #DAIF_ABT_BIT
b enter_lower_el_async_ea
+#else
+ handle_async_ea
+#endif
end_vector_entry serror_aarch32
#ifdef MONITOR_TRAPS
@@ -412,6 +500,21 @@
stp x16, x17, [x6, #CTX_EL3STATE_OFFSET + CTX_SPSR_EL3]
str x18, [x6, #CTX_EL3STATE_OFFSET + CTX_SCR_EL3]
+ /* Clear flag register */
+ mov x7, xzr
+
+#if ENABLE_RME
+ /* Copy SCR_EL3.NSE bit to the flag to indicate caller's security */
+ ubfx x7, x18, #SCR_NSE_SHIFT, 1
+
+ /*
+ * Shift copied SCR_EL3.NSE bit by 5 to create space for
+ * SCR_EL3.NS bit. Bit 5 of the flag correspondes to
+ * the SCR_EL3.NSE bit.
+ */
+ lsl x7, x7, #5
+#endif /* ENABLE_RME */
+
/* Copy SCR_EL3.NS bit to the flag to indicate caller's security */
bfi x7, x18, #0, #1
diff --git a/bl31/bl31.mk b/bl31/bl31.mk
index cd6549b..e751824 100644
--- a/bl31/bl31.mk
+++ b/bl31/bl31.mk
@@ -1,5 +1,5 @@
#
-# Copyright (c) 2013-2019, ARM Limited and Contributors. All rights reserved.
+# Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -22,6 +22,8 @@
endif
endif
+include lib/extensions/amu/amu.mk
+include lib/mpmm/mpmm.mk
include lib/psci/psci_lib.mk
BL31_SOURCES += bl31/bl31_main.c \
@@ -40,6 +42,9 @@
${SPMD_SOURCES} \
${SPM_SOURCES}
+ifeq (${DISABLE_MTPMU},1)
+BL31_SOURCES += lib/extensions/mtpmu/aarch64/mtpmu.S
+endif
ifeq (${ENABLE_PMF}, 1)
BL31_SOURCES += lib/pmf/pmf_main.c
@@ -65,28 +70,64 @@
services/std_svc/sdei/sdei_state.c
endif
+ifeq (${TRNG_SUPPORT},1)
+BL31_SOURCES += services/std_svc/trng/trng_main.c \
+ services/std_svc/trng/trng_entropy_pool.c
+endif
+
ifeq (${ENABLE_SPE_FOR_LOWER_ELS},1)
BL31_SOURCES += lib/extensions/spe/spe.c
endif
ifeq (${ENABLE_AMU},1)
-BL31_SOURCES += lib/extensions/amu/aarch64/amu.c \
- lib/extensions/amu/aarch64/amu_helpers.S
+BL31_SOURCES += ${AMU_SOURCES}
endif
+ifeq (${ENABLE_MPMM},1)
+BL31_SOURCES += ${MPMM_SOURCES}
+endif
+
+ifeq (${ENABLE_SME_FOR_NS},1)
+BL31_SOURCES += lib/extensions/sme/sme.c
+BL31_SOURCES += lib/extensions/sve/sve.c
+else
ifeq (${ENABLE_SVE_FOR_NS},1)
BL31_SOURCES += lib/extensions/sve/sve.c
endif
+endif
ifeq (${ENABLE_MPAM_FOR_LOWER_ELS},1)
BL31_SOURCES += lib/extensions/mpam/mpam.c
endif
+ifeq (${ENABLE_TRBE_FOR_NS},1)
+BL31_SOURCES += lib/extensions/trbe/trbe.c
+endif
+
+ifeq (${ENABLE_SYS_REG_TRACE_FOR_NS},1)
+BL31_SOURCES += lib/extensions/sys_reg_trace/aarch64/sys_reg_trace.c
+endif
+
+ifeq (${ENABLE_TRF_FOR_NS},1)
+BL31_SOURCES += lib/extensions/trf/aarch64/trf.c
+endif
+
ifeq (${WORKAROUND_CVE_2017_5715},1)
BL31_SOURCES += lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S \
lib/cpus/aarch64/wa_cve_2017_5715_mmu.S
endif
+ifeq ($(SMC_PCI_SUPPORT),1)
+BL31_SOURCES += services/std_svc/pci_svc.c
+endif
+
+ifeq (${ENABLE_RME},1)
+include lib/gpt_rme/gpt_rme.mk
+
+BL31_SOURCES += ${GPT_LIB_SRCS} \
+ ${RMMD_SOURCES}
+endif
+
BL31_LINKERFILE := bl31/bl31.ld.S
# Flag used to indicate if Crash reporting via console should be included
diff --git a/bl31/bl31_context_mgmt.c b/bl31/bl31_context_mgmt.c
index 9175ee3..34f69ad 100644
--- a/bl31/bl31_context_mgmt.c
+++ b/bl31/bl31_context_mgmt.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -19,9 +19,9 @@
******************************************************************************/
void *cm_get_context(uint32_t security_state)
{
- assert(security_state <= NON_SECURE);
+ assert(sec_state_is_valid(security_state));
- return get_cpu_data(cpu_context[security_state]);
+ return get_cpu_data(cpu_context[get_cpu_context_index(security_state)]);
}
/*******************************************************************************
@@ -30,9 +30,10 @@
******************************************************************************/
void cm_set_context(void *context, uint32_t security_state)
{
- assert(security_state <= NON_SECURE);
+ assert(sec_state_is_valid(security_state));
- set_cpu_data(cpu_context[security_state], context);
+ set_cpu_data(cpu_context[get_cpu_context_index(security_state)],
+ context);
}
/*******************************************************************************
@@ -46,7 +47,8 @@
{
assert(sec_state_is_valid(security_state));
- return get_cpu_data_by_index(cpu_idx, cpu_context[security_state]);
+ return get_cpu_data_by_index(cpu_idx,
+ cpu_context[get_cpu_context_index(security_state)]);
}
/*******************************************************************************
@@ -58,5 +60,7 @@
{
assert(sec_state_is_valid(security_state));
- set_cpu_data_by_index(cpu_idx, cpu_context[security_state], context);
+ set_cpu_data_by_index(cpu_idx,
+ cpu_context[get_cpu_context_index(security_state)],
+ context);
}
diff --git a/bl31/bl31_main.c b/bl31/bl31_main.c
index 44bf32c..9ac10e2 100644
--- a/bl31/bl31_main.c
+++ b/bl31/bl31_main.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -35,6 +35,13 @@
******************************************************************************/
static int32_t (*bl32_init)(void);
+/*****************************************************************************
+ * Function used to initialise RMM if RME is enabled
+ *****************************************************************************/
+#if ENABLE_RME
+static int32_t (*rmm_init)(void);
+#endif
+
/*******************************************************************************
* Variable to indicate whether next image to execute after BL31 is BL33
* (non-secure & default) or BL32 (secure).
@@ -85,6 +92,15 @@
/* Perform late platform-specific setup */
bl31_plat_arch_setup();
+#if ENABLE_FEAT_HCX
+ /*
+ * Assert that FEAT_HCX is supported on this system, without this check
+ * an exception would occur during context save/restore if enabled but
+ * not supported.
+ */
+ assert(is_feat_hcx_present());
+#endif /* ENABLE_FEAT_HCX */
+
#if CTX_INCLUDE_PAUTH_REGS
/*
* Assert that the ARMv8.3-PAuth registers are present or an access
@@ -130,12 +146,15 @@
/*
* All the cold boot actions on the primary cpu are done. We now need to
- * decide which is the next image (BL32 or BL33) and how to execute it.
+ * decide which is the next image and how to execute it.
* If the SPD runtime service is present, it would want to pass control
* to BL32 first in S-EL1. In that case, SPD would have registered a
* function to initialize bl32 where it takes responsibility of entering
- * S-EL1 and returning control back to bl31_main. Once this is done we
- * can prepare entry into BL33 as normal.
+ * S-EL1 and returning control back to bl31_main. Similarly, if RME is
+ * enabled and a function is registered to initialize RMM, control is
+ * transferred to RMM in R-EL2. After RMM initialization, control is
+ * returned back to bl31_main. Once this is done we can prepare entry
+ * into BL33 as normal.
*/
/*
@@ -146,9 +165,27 @@
int32_t rc = (*bl32_init)();
- if (rc == 0)
+ if (rc == 0) {
WARN("BL31: BL32 initialization failed\n");
+ }
}
+
+ /*
+ * If RME is enabled and init hook is registered, initialize RMM
+ * in R-EL2.
+ */
+#if ENABLE_RME
+ if (rmm_init != NULL) {
+ INFO("BL31: Initializing RMM\n");
+
+ int32_t rc = (*rmm_init)();
+
+ if (rc == 0) {
+ WARN("BL31: RMM initialization failed\n");
+ }
+ }
+#endif
+
/*
* We are ready to enter the next EL. Prepare entry into the image
* corresponding to the desired security state after the next ERET.
@@ -227,3 +264,14 @@
{
bl32_init = func;
}
+
+#if ENABLE_RME
+/*******************************************************************************
+ * This function initializes the pointer to RMM init function. This is expected
+ * to be called by the RMMD after it finishes all its initialization
+ ******************************************************************************/
+void bl31_register_rmm_init(int32_t (*func)(void))
+{
+ rmm_init = func;
+}
+#endif
diff --git a/bl32/sp_min/aarch32/entrypoint.S b/bl32/sp_min/aarch32/entrypoint.S
index f3a1e44..39f1065 100644
--- a/bl32/sp_min/aarch32/entrypoint.S
+++ b/bl32/sp_min/aarch32/entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2016-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2016-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -23,6 +23,8 @@
.globl sp_min_handle_smc
.globl sp_min_handle_fiq
+#define FIXUP_SIZE ((BL32_LIMIT) - (BL32_BASE))
+
.macro route_fiq_to_sp_min reg
/* -----------------------------------------------------
* FIQs are secure interrupts trapped by Monitor and non
@@ -87,7 +89,8 @@
_secondary_cold_boot=0 \
_init_memory=0 \
_init_c_runtime=1 \
- _exception_vectors=sp_min_vector_table
+ _exception_vectors=sp_min_vector_table \
+ _pie_fixup_size=FIXUP_SIZE
/* ---------------------------------------------------------------------
* Relay the previous bootloader's arguments to the platform layer
@@ -106,7 +109,8 @@
_secondary_cold_boot=!COLD_BOOT_SINGLE_CPU \
_init_memory=1 \
_init_c_runtime=1 \
- _exception_vectors=sp_min_vector_table
+ _exception_vectors=sp_min_vector_table \
+ _pie_fixup_size=FIXUP_SIZE
/* ---------------------------------------------------------------------
* For RESET_TO_SP_MIN systems, BL32 (SP_MIN) is the first bootloader
@@ -306,7 +310,8 @@
_secondary_cold_boot=0 \
_init_memory=0 \
_init_c_runtime=0 \
- _exception_vectors=sp_min_vector_table
+ _exception_vectors=sp_min_vector_table \
+ _pie_fixup_size=0
/*
* We're about to enable MMU and participate in PSCI state coordination.
diff --git a/bl32/sp_min/sp_min.ld.S b/bl32/sp_min/sp_min.ld.S
index f202c7a..475affa 100644
--- a/bl32/sp_min/sp_min.ld.S
+++ b/bl32/sp_min/sp_min.ld.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2016-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2016-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -92,6 +92,7 @@
__RW_START__ = . ;
DATA_SECTION >RAM
+ RELA_SECTION >RAM
#ifdef BL32_PROGBITS_LIMIT
ASSERT(. <= BL32_PROGBITS_LIMIT, "BL32 progbits has exceeded its limit.")
@@ -141,5 +142,9 @@
__BL32_END__ = .;
+ /DISCARD/ : {
+ *(.dynsym .dynstr .hash .gnu.hash)
+ }
+
ASSERT(. <= BL32_LIMIT, "BL32 image has exceeded its limit.")
}
diff --git a/bl32/sp_min/sp_min.mk b/bl32/sp_min/sp_min.mk
index 6233299..590b032 100644
--- a/bl32/sp_min/sp_min.mk
+++ b/bl32/sp_min/sp_min.mk
@@ -1,5 +1,5 @@
#
-# Copyright (c) 2016-2018, ARM Limited and Contributors. All rights reserved.
+# Copyright (c) 2016-2021, ARM Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -8,6 +8,7 @@
$(error SP_MIN is only supported on AArch32 platforms)
endif
+include lib/extensions/amu/amu.mk
include lib/psci/psci_lib.mk
INCLUDES += -Iinclude/bl32/sp_min
@@ -19,13 +20,16 @@
services/std_svc/std_svc_setup.c \
${PSCI_LIB_SOURCES}
+ifeq (${DISABLE_MTPMU},1)
+BL32_SOURCES += lib/extensions/mtpmu/aarch32/mtpmu.S
+endif
+
ifeq (${ENABLE_PMF}, 1)
BL32_SOURCES += lib/pmf/pmf_main.c
endif
-ifeq (${ENABLE_AMU}, 1)
-BL32_SOURCES += lib/extensions/amu/aarch32/amu.c\
- lib/extensions/amu/aarch32/amu_helpers.S
+ifeq (${ENABLE_AMU},1)
+BL32_SOURCES += ${AMU_SOURCES}
endif
ifeq (${WORKAROUND_CVE_2017_5715},1)
@@ -33,6 +37,19 @@
bl32/sp_min/wa_cve_2017_5715_icache_inv.S
endif
+ifeq (${TRNG_SUPPORT},1)
+BL32_SOURCES += services/std_svc/trng/trng_main.c \
+ services/std_svc/trng/trng_entropy_pool.c
+endif
+
+ifeq (${ENABLE_SYS_REG_TRACE_FOR_NS},1)
+BL32_SOURCES += lib/extensions/sys_reg_trace/aarch32/sys_reg_trace.c
+endif
+
+ifeq (${ENABLE_TRF_FOR_NS},1)
+BL32_SOURCES += lib/extensions/trf/aarch32/trf.c
+endif
+
BL32_LINKERFILE := bl32/sp_min/sp_min.ld.S
# Include the platform-specific SP_MIN Makefile
diff --git a/bl32/tsp/aarch64/tsp_entrypoint.S b/bl32/tsp/aarch64/tsp_entrypoint.S
index a007bab..7d77f47 100644
--- a/bl32/tsp/aarch64/tsp_entrypoint.S
+++ b/bl32/tsp/aarch64/tsp_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -100,11 +100,27 @@
* sections. This is done to safeguard against
* possible corruption of this memory by dirty
* cache lines in a system cache as a result of
- * use by an earlier boot loader stage.
+ * use by an earlier boot loader stage. If PIE
+ * is enabled however, RO sections including the
+ * GOT may be modified during pie fixup.
+ * Therefore, to be on the safe side, invalidate
+ * the entire image region if PIE is enabled.
* ---------------------------------------------
*/
- adr x0, __RW_START__
- adr x1, __RW_END__
+#if ENABLE_PIE
+#if SEPARATE_CODE_AND_RODATA
+ adrp x0, __TEXT_START__
+ add x0, x0, :lo12:__TEXT_START__
+#else
+ adrp x0, __RO_START__
+ add x0, x0, :lo12:__RO_START__
+#endif /* SEPARATE_CODE_AND_RODATA */
+#else
+ adrp x0, __RW_START__
+ add x0, x0, :lo12:__RW_START__
+#endif /* ENABLE_PIE */
+ adrp x1, __RW_END__
+ add x1, x1, :lo12:__RW_END__
sub x1, x1, x0
bl inv_dcache_range
@@ -114,13 +130,19 @@
* - the coherent memory section.
* ---------------------------------------------
*/
- ldr x0, =__BSS_START__
- ldr x1, =__BSS_SIZE__
+ adrp x0, __BSS_START__
+ add x0, x0, :lo12:__BSS_START__
+ adrp x1, __BSS_END__
+ add x1, x1, :lo12:__BSS_END__
+ sub x1, x1, x0
bl zeromem
#if USE_COHERENT_MEM
- ldr x0, =__COHERENT_RAM_START__
- ldr x1, =__COHERENT_RAM_UNALIGNED_SIZE__
+ adrp x0, __COHERENT_RAM_START__
+ add x0, x0, :lo12:__COHERENT_RAM_START__
+ adrp x1, __COHERENT_RAM_END_UNALIGNED__
+ add x1, x1, :lo12:__COHERENT_RAM_END_UNALIGNED__
+ sub x1, x1, x0
bl zeromem
#endif
diff --git a/bl32/tsp/aarch64/tsp_request.S b/bl32/tsp/aarch64/tsp_request.S
index 5ad16da..6e238ea 100644
--- a/bl32/tsp/aarch64/tsp_request.S
+++ b/bl32/tsp/aarch64/tsp_request.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -9,28 +9,19 @@
.globl tsp_get_magic
-
/*
* This function raises an SMC to retrieve arguments from secure
* monitor/dispatcher, saves the returned arguments the array received in x0,
* and then returns to the caller
*/
func tsp_get_magic
- /* Save address to stack */
- stp x0, xzr, [sp, #-16]!
-
/* Load arguments */
ldr w0, _tsp_fid_get_magic
/* Raise SMC */
smc #0
- /* Restore address from stack */
- ldp x4, xzr, [sp], #16
-
- /* Store returned arguments to the array */
- stp x0, x1, [x4, #0]
-
+ /* Return arguments in x1:x0 */
ret
endfunc tsp_get_magic
diff --git a/bl32/tsp/tsp_interrupt.c b/bl32/tsp/tsp_interrupt.c
index 4e500b3..430b5dd 100644
--- a/bl32/tsp/tsp_interrupt.c
+++ b/bl32/tsp/tsp_interrupt.c
@@ -5,6 +5,7 @@
*/
#include <assert.h>
+#include <inttypes.h>
#include <platform_def.h>
@@ -36,7 +37,7 @@
#if LOG_LEVEL >= LOG_LEVEL_VERBOSE
spin_lock(&console_lock);
- VERBOSE("TSP: cpu 0x%lx sync s-el1 interrupt request from 0x%llx\n",
+ VERBOSE("TSP: cpu 0x%lx sync s-el1 interrupt request from 0x%" PRIx64 "\n",
read_mpidr(), elr_el3);
VERBOSE("TSP: cpu 0x%lx: %d sync s-el1 interrupt requests,"
" %d sync s-el1 interrupt returns\n",
diff --git a/bl32/tsp/tsp_main.c b/bl32/tsp/tsp_main.c
index e947838..55e1532 100644
--- a/bl32/tsp/tsp_main.c
+++ b/bl32/tsp/tsp_main.c
@@ -1,10 +1,12 @@
/*
- * Copyright (c) 2013-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
#include <assert.h>
+#include <inttypes.h>
+#include <stdint.h>
#include <arch_features.h>
#include <arch_helpers.h>
@@ -271,7 +273,7 @@
#if LOG_LEVEL >= LOG_LEVEL_INFO
spin_lock(&console_lock);
- INFO("TSP: cpu 0x%lx resumed. maximum off power level %lld\n",
+ INFO("TSP: cpu 0x%lx resumed. maximum off power level %" PRId64 "\n",
read_mpidr(), max_off_pwrlvl);
INFO("TSP: cpu 0x%lx: %d smcs, %d erets %d cpu resume requests\n",
read_mpidr(),
@@ -363,8 +365,10 @@
uint64_t arg6,
uint64_t arg7)
{
+ uint128_t service_args;
+ uint64_t service_arg0;
+ uint64_t service_arg1;
uint64_t results[2];
- uint64_t service_args[2];
uint32_t linear_id = plat_my_core_pos();
/* Update this cpu's statistics */
@@ -373,7 +377,7 @@
#if LOG_LEVEL >= LOG_LEVEL_INFO
spin_lock(&console_lock);
- INFO("TSP: cpu 0x%lx received %s smc 0x%llx\n", read_mpidr(),
+ INFO("TSP: cpu 0x%lx received %s smc 0x%" PRIx64 "\n", read_mpidr(),
((func >> 31) & 1) == 1 ? "fast" : "yielding",
func);
INFO("TSP: cpu 0x%lx: %d smcs, %d erets\n", read_mpidr(),
@@ -387,10 +391,12 @@
results[1] = arg2;
/*
- * Request a service back from dispatcher/secure monitor. This call
- * return and thereafter resume execution
+ * Request a service back from dispatcher/secure monitor.
+ * This call returns and thereafter resumes execution.
*/
- tsp_get_magic(service_args);
+ service_args = tsp_get_magic();
+ service_arg0 = (uint64_t)service_args;
+ service_arg1 = (uint64_t)(service_args >> 64U);
#if CTX_INCLUDE_MTE_REGS
/*
@@ -403,20 +409,20 @@
/* Determine the function to perform based on the function ID */
switch (TSP_BARE_FID(func)) {
case TSP_ADD:
- results[0] += service_args[0];
- results[1] += service_args[1];
+ results[0] += service_arg0;
+ results[1] += service_arg1;
break;
case TSP_SUB:
- results[0] -= service_args[0];
- results[1] -= service_args[1];
+ results[0] -= service_arg0;
+ results[1] -= service_arg1;
break;
case TSP_MUL:
- results[0] *= service_args[0];
- results[1] *= service_args[1];
+ results[0] *= service_arg0;
+ results[1] *= service_arg1;
break;
case TSP_DIV:
- results[0] /= service_args[0] ? service_args[0] : 1;
- results[1] /= service_args[1] ? service_args[1] : 1;
+ results[0] /= service_arg0 ? service_arg0 : 1;
+ results[1] /= service_arg1 ? service_arg1 : 1;
break;
default:
break;
diff --git a/bl32/tsp/tsp_private.h b/bl32/tsp/tsp_private.h
index cbd527f..38d9732 100644
--- a/bl32/tsp/tsp_private.h
+++ b/bl32/tsp/tsp_private.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2014-2020, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -61,7 +61,7 @@
*/
CASSERT(TSP_ARGS_SIZE == sizeof(tsp_args_t), assert_sp_args_size_mismatch);
-void tsp_get_magic(uint64_t args[4]);
+uint128_t tsp_get_magic(void);
tsp_args_t *tsp_cpu_resume_main(uint64_t max_off_pwrlvl,
uint64_t arg1,
diff --git a/commitlint.config.js b/commitlint.config.js
new file mode 100644
index 0000000..94cad8f
--- /dev/null
+++ b/commitlint.config.js
@@ -0,0 +1,14 @@
+/* eslint-env node */
+
+"use strict";
+
+const config = require("./.cz.json");
+
+module.exports = {
+ extends: ["@commitlint/config-conventional"],
+ rules: {
+ "header-max-length": [1, "always", config.maxHeaderWidth], /* Warning */
+ "body-max-line-length": [1, "always", config.maxLineWidth], /* Warning */
+ "signed-off-by": [0, "always", "Signed-off-by:"] /* Disabled - buggy */
+ }
+};
diff --git a/common/aarch64/debug.S b/common/aarch64/debug.S
index ad6acd9..d105d08 100644
--- a/common/aarch64/debug.S
+++ b/common/aarch64/debug.S
@@ -208,6 +208,9 @@
sub x4, x4, #4
bl asm_print_hex
+ /* Print new line */
+ bl asm_print_newline
+
bl plat_crash_console_flush
_panic_handler:
diff --git a/common/bl_common.c b/common/bl_common.c
index f17afcb..eb2352a 100644
--- a/common/bl_common.c
+++ b/common/bl_common.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -202,12 +202,26 @@
return -EAUTH;
}
- /*
- * Flush the image to main memory so that it can be executed later by
- * any CPU, regardless of cache and MMU state. This is only needed for
- * child images, not for the parents (certificates).
- */
if (is_parent_image == 0) {
+ /*
+ * Measure the image.
+ * We do not measure its parents because these only play a role
+ * in authentication, which is orthogonal to measured boot.
+ *
+ * TODO: Change this code if we change our minds about measuring
+ * certificates.
+ */
+ rc = plat_mboot_measure_image(image_id, image_data);
+ if (rc != 0) {
+ return rc;
+ }
+
+ /*
+ * Flush the image to main memory so that it can be executed
+ * later by any CPU, regardless of cache and MMU state. This
+ * is only needed for child images, not for the parents
+ * (certificates).
+ */
flush_dcache_range(image_data->image_base,
image_data->image_size);
}
@@ -239,9 +253,18 @@
{
int err;
+/*
+ * All firmware banks should be part of the same non-volatile storage as per
+ * PSA FWU specification, hence don't check for any alternate boot source
+ * when PSA FWU is enabled.
+ */
+#if PSA_FWU_SUPPORT
+ err = load_auth_image_internal(image_id, image_data);
+#else
do {
err = load_auth_image_internal(image_id, image_data);
} while ((err != 0) && (plat_try_next_boot_source() != 0));
+#endif /* PSA_FWU_SUPPORT */
return err;
}
diff --git a/common/fdt_fixup.c b/common/fdt_fixup.c
index e88a550..de02b46 100644
--- a/common/fdt_fixup.c
+++ b/common/fdt_fixup.c
@@ -188,6 +188,8 @@
*
* See reserved-memory/reserved-memory.txt in the (Linux kernel) DT binding
* documentation for details.
+ * According to this binding, the address-cells and size-cells must match
+ * those of the root node.
*
* Return: 0 on success, a negative error value otherwise.
******************************************************************************/
@@ -195,23 +197,37 @@
uintptr_t base, size_t size)
{
int offs = fdt_path_offset(dtb, "/reserved-memory");
- uint32_t addresses[3];
+ uint32_t addresses[4];
+ int ac, sc;
+ unsigned int idx = 0;
+ ac = fdt_address_cells(dtb, 0);
+ sc = fdt_size_cells(dtb, 0);
if (offs < 0) { /* create if not existing yet */
offs = fdt_add_subnode(dtb, 0, "reserved-memory");
- if (offs < 0)
+ if (offs < 0) {
return offs;
- fdt_setprop_u32(dtb, offs, "#address-cells", 2);
- fdt_setprop_u32(dtb, offs, "#size-cells", 1);
+ }
+ fdt_setprop_u32(dtb, offs, "#address-cells", ac);
+ fdt_setprop_u32(dtb, offs, "#size-cells", sc);
fdt_setprop(dtb, offs, "ranges", NULL, 0);
}
- addresses[0] = cpu_to_fdt32(HIGH_BITS(base));
- addresses[1] = cpu_to_fdt32(base & 0xffffffff);
- addresses[2] = cpu_to_fdt32(size & 0xffffffff);
+ if (ac > 1) {
+ addresses[idx] = cpu_to_fdt32(HIGH_BITS(base));
+ idx++;
+ }
+ addresses[idx] = cpu_to_fdt32(base & 0xffffffff);
+ idx++;
+ if (sc > 1) {
+ addresses[idx] = cpu_to_fdt32(HIGH_BITS(size));
+ idx++;
+ }
+ addresses[idx] = cpu_to_fdt32(size & 0xffffffff);
+ idx++;
offs = fdt_add_subnode(dtb, offs, node_name);
fdt_setprop(dtb, offs, "no-map", NULL, 0);
- fdt_setprop(dtb, offs, "reg", addresses, 12);
+ fdt_setprop(dtb, offs, "reg", addresses, idx * sizeof(uint32_t));
return 0;
}
@@ -382,6 +398,7 @@
* fdt_adjust_gic_redist() - Adjust GICv3 redistributor size
* @dtb: Pointer to the DT blob in memory
* @nr_cores: Number of CPU cores on this system.
+ * @gicr_base: Base address of the first GICR frame, or ~0 if unchanged
* @gicr_frame_size: Size of the GICR frame per core
*
* On a GICv3 compatible interrupt controller, the redistributor provides
@@ -394,17 +411,19 @@
* A GICv4 compatible redistributor uses four 64K pages per core, whereas GICs
* without support for direct injection of virtual interrupts use two 64K pages.
* The @gicr_frame_size parameter should be 262144 and 131072, respectively.
+ * Also optionally allow adjusting the GICR frame base address, when this is
+ * different due to ITS frames between distributor and redistributor.
*
* Return: 0 on success, negative error value otherwise.
*/
int fdt_adjust_gic_redist(void *dtb, unsigned int nr_cores,
- unsigned int gicr_frame_size)
+ uintptr_t gicr_base, unsigned int gicr_frame_size)
{
int offset = fdt_node_offset_by_compatible(dtb, 0, "arm,gic-v3");
- uint64_t redist_size_64;
- uint32_t redist_size_32;
+ uint64_t reg_64;
+ uint32_t reg_32;
void *val;
- int parent;
+ int parent, ret;
int ac, sc;
if (offset < 0) {
@@ -421,13 +440,34 @@
return -EINVAL;
}
+ if (gicr_base != INVALID_BASE_ADDR) {
+ if (ac == 1) {
+ reg_32 = cpu_to_fdt32(gicr_base);
+ val = ®_32;
+ } else {
+ reg_64 = cpu_to_fdt64(gicr_base);
+ val = ®_64;
+ }
+ /*
+ * The redistributor base address is the second address in
+ * the "reg" entry, so we have to skip one address and one
+ * size cell.
+ */
+ ret = fdt_setprop_inplace_namelen_partial(dtb, offset,
+ "reg", 3,
+ (ac + sc) * 4,
+ val, ac * 4);
+ if (ret < 0) {
+ return ret;
+ }
+ }
+
if (sc == 1) {
- redist_size_32 = cpu_to_fdt32(nr_cores * gicr_frame_size);
- val = &redist_size_32;
+ reg_32 = cpu_to_fdt32(nr_cores * gicr_frame_size);
+ val = ®_32;
} else {
- redist_size_64 = cpu_to_fdt64(nr_cores *
- (uint64_t)gicr_frame_size);
- val = &redist_size_64;
+ reg_64 = cpu_to_fdt64(nr_cores * (uint64_t)gicr_frame_size);
+ val = ®_64;
}
/*
diff --git a/common/fdt_wrappers.c b/common/fdt_wrappers.c
index 5aad14e..2a9673f 100644
--- a/common/fdt_wrappers.c
+++ b/common/fdt_wrappers.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2018-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2018-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -7,12 +7,16 @@
/* Helper functions to offer easier navigation of Device Tree Blob */
#include <assert.h>
+#include <errno.h>
+#include <inttypes.h>
+#include <stdint.h>
#include <string.h>
#include <libfdt.h>
#include <common/debug.h>
#include <common/fdt_wrappers.h>
+#include <common/uuid.h>
/*
* Read cells from a given property of the given node. Any number of 32-bit
@@ -33,7 +37,7 @@
/* Access property and obtain its length (in bytes) */
prop = fdt_getprop(dtb, node, prop_name, &value_len);
if (prop == NULL) {
- WARN("Couldn't find property %s in dtb\n", prop_name);
+ VERBOSE("Couldn't find property %s in dtb\n", prop_name);
return -FDT_ERR_NOTFOUND;
}
@@ -152,6 +156,39 @@
}
/*
+ * Read UUID from a given property of the given node. Returns 0 on success,
+ * and a negative value upon error.
+ */
+int fdtw_read_uuid(const void *dtb, int node, const char *prop,
+ unsigned int length, uint8_t *uuid)
+{
+ /* Buffer for UUID string (plus NUL terminator) */
+ char uuid_string[UUID_STRING_LENGTH + 1U];
+ int err;
+
+ assert(dtb != NULL);
+ assert(prop != NULL);
+ assert(uuid != NULL);
+ assert(node >= 0);
+
+ if (length < UUID_BYTES_LENGTH) {
+ return -EINVAL;
+ }
+
+ err = fdtw_read_string(dtb, node, prop, uuid_string,
+ UUID_STRING_LENGTH + 1U);
+ if (err != 0) {
+ return err;
+ }
+
+ if (read_uuid(uuid, uuid_string) != 0) {
+ return -FDT_ERR_BADVALUE;
+ }
+
+ return 0;
+}
+
+/*
* Write cells in place to a given property of the given node. At most 2 cells
* of the property are written. Returns 0 on success, and -1 upon error.
*/
@@ -367,7 +404,7 @@
addr_range = fdt_read_prop_cells(value + child_addr_size +
parent_addr_size,
range_size);
- VERBOSE("DT: Address %llx mapped to %llx with range %llx\n",
+ VERBOSE("DT: Address %" PRIx64 " mapped to %" PRIx64 " with range %" PRIx64 "\n",
local_address, parent_address, addr_range);
/* Perform range check */
@@ -378,8 +415,8 @@
/* Found hit for the addr range that needs to be translated */
*translated_addr = parent_address + (base_address - local_address);
- VERBOSE("DT: child address %llx mapped to %llx in parent bus\n",
- local_address, parent_address);
+ VERBOSE("DT: child address %" PRIx64 "mapped to %" PRIx64 " in parent bus\n",
+ local_address, parent_address);
return true;
}
@@ -435,8 +472,8 @@
next_entry = next_entry + ncells_xlat;
}
- INFO("DT: No translation found for address %llx in node %s\n",
- base_address, fdt_get_name(dtb, local_bus, NULL));
+ INFO("DT: No translation found for address %" PRIx64 " in node %s\n",
+ base_address, fdt_get_name(dtb, local_bus, NULL));
return ILLEGAL_ADDR;
}
@@ -537,3 +574,47 @@
/* Translate the local device address recursively */
return fdtw_translate_address(dtb, local_bus_node, global_address);
}
+
+/*
+ * For every CPU node (`/cpus/cpu@n`) in an FDT, execute a callback passing a
+ * pointer to the FDT and the offset of the CPU node. If the return value of the
+ * callback is negative, it is treated as an error and the loop is aborted. In
+ * this situation, the value of the callback is returned from the function.
+ *
+ * Returns `0` on success, or a negative integer representing an error code.
+ */
+int fdtw_for_each_cpu(const void *dtb,
+ int (*callback)(const void *dtb, int node, uintptr_t mpidr))
+{
+ int ret = 0;
+ int parent, node = 0;
+
+ parent = fdt_path_offset(dtb, "/cpus");
+ if (parent < 0) {
+ return parent;
+ }
+
+ fdt_for_each_subnode(node, dtb, parent) {
+ const char *name;
+ int len;
+
+ uintptr_t mpidr = 0U;
+
+ name = fdt_get_name(dtb, node, &len);
+ if (strncmp(name, "cpu@", 4) != 0) {
+ continue;
+ }
+
+ ret = fdt_get_reg_props_by_index(dtb, node, 0, &mpidr, NULL);
+ if (ret < 0) {
+ break;
+ }
+
+ ret = callback(dtb, node, mpidr);
+ if (ret < 0) {
+ break;
+ }
+ }
+
+ return ret;
+}
diff --git a/common/fdt_wrappers.mk b/common/fdt_wrappers.mk
new file mode 100644
index 0000000..62b8c6e
--- /dev/null
+++ b/common/fdt_wrappers.mk
@@ -0,0 +1,7 @@
+#
+# Copyright (c) 2021, Arm Limited. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-3-Clause
+#
+
+FDT_WRAPPERS_SOURCES := common/fdt_wrappers.c
diff --git a/common/tf_crc32.c b/common/tf_crc32.c
new file mode 100644
index 0000000..b33d36e
--- /dev/null
+++ b/common/tf_crc32.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include <stdarg.h>
+#include <assert.h>
+
+#include <arm_acle.h>
+#include <common/debug.h>
+#include <common/tf_crc32.h>
+
+/* compute CRC using Arm intrinsic function
+ *
+ * This function is useful for the platforms with the CPU ARMv8.0
+ * (with CRC instructions supported), and onwards.
+ * Platforms with CPU ARMv8.0 should make sure to add a compile switch
+ * '-march=armv8-a+crc" for successful compilation of this file.
+ *
+ * @crc: previous accumulated CRC
+ * @buf: buffer base address
+ * @size: the size of the buffer
+ *
+ * Return calculated CRC value
+ */
+uint32_t tf_crc32(uint32_t crc, const unsigned char *buf, size_t size)
+{
+ assert(buf != NULL);
+
+ uint32_t calc_crc = ~crc;
+ const unsigned char *local_buf = buf;
+ size_t local_size = size;
+
+ /*
+ * calculate CRC over byte data
+ */
+ while (local_size != 0UL) {
+ calc_crc = __crc32b(calc_crc, *local_buf);
+ local_buf++;
+ local_size--;
+ }
+
+ return ~calc_crc;
+}
diff --git a/common/tf_log.c b/common/tf_log.c
index 08d3cf4..68f1be4 100644
--- a/common/tf_log.c
+++ b/common/tf_log.c
@@ -49,6 +49,20 @@
va_end(args);
}
+void tf_log_newline(const char log_fmt[2])
+{
+ unsigned int log_level = log_fmt[0];
+
+ /* Verify that log_level is one of LOG_MARKER_* macro defined in debug.h */
+ assert((log_level > 0U) && (log_level <= LOG_LEVEL_VERBOSE));
+ assert((log_level % 10U) == 0U);
+
+ if (log_level > max_log_level)
+ return;
+
+ putchar('\n');
+}
+
/*
* The helper function to set the log level dynamically by platform. The
* maximum log level is determined by `LOG_LEVEL` build flag at compile time
diff --git a/common/uuid.c b/common/uuid.c
new file mode 100644
index 0000000..ac6db50
--- /dev/null
+++ b/common/uuid.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright (c) 2021, Arm Limited and Contributors. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include <assert.h>
+#include <errno.h>
+#include <stdint.h>
+#include <string.h>
+
+#include <common/debug.h>
+#include <common/uuid.h>
+
+/* Return the hex nibble value of a char */
+static int8_t hex_val(char hex)
+{
+ int8_t val = 0;
+
+ if ((hex >= '0') && (hex <= '9')) {
+ val = (int8_t)(hex - '0');
+ } else if ((hex >= 'a') && (hex <= 'f')) {
+ val = (int8_t)(hex - 'a' + 0xa);
+ } else if ((hex >= 'A') && (hex <= 'F')) {
+ val = (int8_t)(hex - 'A' + 0xa);
+ } else {
+ val = -1;
+ }
+
+ return val;
+}
+
+/*
+ * Read hex_src_len hex characters from hex_src, convert to bytes and
+ * store in buffer pointed to by dest
+ */
+static int read_hex(uint8_t *dest, char *hex_src, unsigned int hex_src_len)
+{
+ int8_t nibble;
+ uint8_t byte;
+
+ /*
+ * The string length must be a multiple of 2 to represent an
+ * exact number of bytes.
+ */
+ assert((hex_src_len % 2U) == 0U);
+
+ for (unsigned int i = 0U; i < (hex_src_len / 2U); i++) {
+ nibble = 0;
+ byte = 0U;
+
+ nibble = hex_val(hex_src[2U * i]);
+ if (nibble < 0) {
+ return -1;
+ }
+ byte = (uint8_t)nibble;
+ byte <<= 4U;
+
+ nibble = hex_val(hex_src[(2U * i) + 1U]);
+ if (nibble < 0) {
+ return -1;
+ }
+ byte |= (uint8_t)nibble;
+
+ *dest = byte;
+ dest++;
+ }
+
+ return 0;
+}
+
+/* Parse UUIDs of the form aabbccdd-eeff-4099-8877-665544332211 */
+int read_uuid(uint8_t *dest, char *uuid)
+{
+ int err;
+ uint8_t *dest_start = dest;
+
+ /* Check that we have enough characters */
+ if (strnlen(uuid, UUID_STRING_LENGTH) != UUID_STRING_LENGTH) {
+ WARN("UUID string is too short\n");
+ return -EINVAL;
+ }
+
+ /* aabbccdd */
+ err = read_hex(dest, uuid, 8);
+ uuid += 8;
+ dest += 4;
+
+ /* Check for '-' */
+ err |= ((*uuid == '-') ? 0 : -1);
+ uuid++;
+
+ /* eeff */
+ err |= read_hex(dest, uuid, 4);
+ uuid += 4;
+ dest += 2;
+
+ /* Check for '-' */
+ err |= ((*uuid == '-') ? 0 : -1);
+ uuid++;
+
+ /* 4099 */
+ err |= read_hex(dest, uuid, 4);
+ uuid += 4;
+ dest += 2;
+
+ /* Check for '-' */
+ err |= ((*uuid == '-') ? 0 : -1);
+ uuid++;
+
+ /* 8877 */
+ err |= read_hex(dest, uuid, 4);
+ uuid += 4;
+ dest += 2;
+
+ /* Check for '-' */
+ err |= ((*uuid == '-') ? 0 : -1);
+ uuid++;
+
+ /* 665544332211 */
+ err |= read_hex(dest, uuid, 12);
+ uuid += 12;
+ dest += 6;
+
+ if (err < 0) {
+ WARN("Error parsing UUID\n");
+ /* Clear the buffer on error */
+ memset((void *)dest_start, '\0', UUID_BYTES_LENGTH * sizeof(uint8_t));
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
diff --git a/docs/_static/css/custom.css b/docs/_static/css/custom.css
new file mode 100644
index 0000000..f6f5fa0
--- /dev/null
+++ b/docs/_static/css/custom.css
@@ -0,0 +1,15 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/*
+ * Set the white-space property of tables to normal.
+ * With this setting sequences of whitespace inside
+ * a table will collapse into a single whitespace,
+ * and text will wrap when necessary.
+ */
+.wy-table-responsive table td {
+white-space: normal;
+}
diff --git a/docs/about/features.rst b/docs/about/features.rst
index 964cb25..4b7fbe5 100644
--- a/docs/about/features.rst
+++ b/docs/about/features.rst
@@ -74,7 +74,7 @@
loading of a hardware configuration (for example, a kernel device tree)
as part of the FIP, to be passed through the firmware stages.
This feature is now incorporated inside the firmware configuration framework
- (fconf), which is still flagged as experimental.
+ (fconf).
- Support for alternative boot flows, for example to support platforms where
the EL3 Runtime Software is loaded using other firmware or a separate
@@ -94,9 +94,7 @@
- Support for ARMv8.3 pointer authentication in the normal and secure worlds.
The use of pointer authentication in the normal world is enabled whenever
architectural support is available, without the need for additional build
- flags. Use of pointer authentication in the secure world remains an
- experimental configuration at this time and requires the
- ``BRANCH_PROTECTION`` option to be set to non-zero.
+ flags.
- Position-Independent Executable (PIE) support. Currently for BL2, BL31, and
TSP, with further support to be added in a future release.
@@ -108,7 +106,7 @@
- Refinements to Position Independent Executable (PIE) support.
-- Continued support for the PSA FF-A v1.0 (formally known as SPCI) specification, to enable the
+- Continued support for the FF-A v1.0 (formally known as SPCI) specification, to enable the
use of secure partition management in the secure world.
- Documentation enhancements.
@@ -126,4 +124,4 @@
--------------
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
diff --git a/docs/about/maintainers.rst b/docs/about/maintainers.rst
index ab2d3f9..7a48601 100644
--- a/docs/about/maintainers.rst
+++ b/docs/about/maintainers.rst
@@ -9,42 +9,45 @@
More details may be found in the `Project Maintenance Process`_ document.
+.. |M| replace:: **Mail**
+.. |G| replace:: **GitHub ID**
+.. |F| replace:: **Files**
.. _maintainers:
Maintainers
-----------
-:M: Dan Handley <dan.handley@arm.com>
-:G: `danh-arm`_
-:M: Soby Mathew <soby.mathew@arm.com>
-:G: `soby-mathew`_
-:M: Sandrine Bailleux <sandrine.bailleux@arm.com>
-:G: `sandrine-bailleux-arm`_
-:M: Alexei Fedorov <Alexei.Fedorov@arm.com>
-:G: `AlexeiFedorov`_
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:M: Mark Dykes <mark.dykes@arm.com>
-:G: `mardyk01`_
-:M: Olivier Deprez <olivier.deprez@arm.com>
-:G: `odeprez`_
-:M: Bipin Ravi <bipin.ravi@arm.com>
-:G: `bipinravi-arm`_
-:M: Joanna Farley <joanna.farley@arm.com>
-:G: `joannafarley-arm`_
-:M: Julius Werner <jwerner@chromium.org>
-:G: `jwerner-chromium`_
-:M: Varun Wadekar <vwadekar@nvidia.com>
-:G: `vwadekar`_
-:M: Andre Przywara <andre.przywara@arm.com>
-:G: `Andre-ARM`_
-:M: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
-:G: `laurenw-arm`_
-:M: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
-:G: `madhukar-Arm`_
-:M: Raghu Krishnamurthy <raghu.ncstate@icloud.com>
-:G: `raghuncstate`_
+:|M|: Dan Handley <dan.handley@arm.com>
+:|G|: `danh-arm`_
+:|M|: Soby Mathew <soby.mathew@arm.com>
+:|G|: `soby-mathew`_
+:|M|: Sandrine Bailleux <sandrine.bailleux@arm.com>
+:|G|: `sandrine-bailleux-arm`_
+:|M|: Alexei Fedorov <Alexei.Fedorov@arm.com>
+:|G|: `AlexeiFedorov`_
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|M|: Mark Dykes <mark.dykes@arm.com>
+:|G|: `mardyk01`_
+:|M|: Olivier Deprez <olivier.deprez@arm.com>
+:|G|: `odeprez`_
+:|M|: Bipin Ravi <bipin.ravi@arm.com>
+:|G|: `bipinravi-arm`_
+:|M|: Joanna Farley <joanna.farley@arm.com>
+:|G|: `joannafarley-arm`_
+:|M|: Julius Werner <jwerner@chromium.org>
+:|G|: `jwerner-chromium`_
+:|M|: Varun Wadekar <vwadekar@nvidia.com>
+:|G|: `vwadekar`_
+:|M|: Andre Przywara <andre.przywara@arm.com>
+:|G|: `Andre-ARM`_
+:|M|: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
+:|G|: `laurenw-arm`_
+:|M|: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
+:|G|: `madhukar-Arm`_
+:|M|: Raghu Krishnamurthy <raghu.ncstate@icloud.com>
+:|G|: `raghuncstate`_
.. _code owners:
@@ -52,487 +55,621 @@
Code owners
-----------
-Core Code
-~~~~~~~~~
+Common Code
+~~~~~~~~~~~
Armv7-A architecture port
^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Etienne Carriere <etienne.carriere@linaro.org>
-:G: `etienne-lms`_
+:|M|: Etienne Carriere <etienne.carriere@linaro.org>
+:|G|: `etienne-lms`_
Build Definitions for CMake Build System
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
-:G: `javieralso-arm`_
-:M: Chris Kay <chris.kay@arm.com>
-:G: `CJkay`_
-:F: /
+:|M|: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
+:|G|: `javieralso-arm`_
+:|M|: Chris Kay <chris.kay@arm.com>
+:|G|: `CJKay`_
+:|F|: /
Software Delegated Exception Interface (SDEI)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Mark Dykes <mark.dykes@arm.com>
-:G: `mardyk01`_
-:M: John Powell <John.Powell@arm.com>
-:G: `john-powell-arm`_
-:F: services/std_svc/sdei/
+:|M|: Mark Dykes <mark.dykes@arm.com>
+:|G|: `mardyk01`_
+:|M|: John Powell <john.powell@arm.com>
+:|G|: `john-powell-arm`_
+:|F|: services/std_svc/sdei/
Trusted Boot
^^^^^^^^^^^^
-:M: Sandrine Bailleux <sandrine.bailleux@arm.com>
-:G: `sandrine-bailleux-arm`_
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:M: Manish Badarkhe <manish.badarkhe@arm.com>
-:G: `ManishVB-Arm`_
-:F: drivers/auth/
+:|M|: Sandrine Bailleux <sandrine.bailleux@arm.com>
+:|G|: `sandrine-bailleux-arm`_
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|M|: Manish Badarkhe <manish.badarkhe@arm.com>
+:|G|: `ManishVB-Arm`_
+:|F|: drivers/auth/
Secure Partition Manager (SPM)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Olivier Deprez <olivier.deprez@arm.com>
-:G: `odeprez`_
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:M: Maksims Svecovs <maksims.svecovs@arm.com>
-:G: `max-shvetsov`_
-:M: Joao Alves <Joao.Alves@arm.com>
-:G: `J-Alves`_
-:F: services/std_svc/spm\*
+:|M|: Olivier Deprez <olivier.deprez@arm.com>
+:|G|: `odeprez`_
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|M|: Maksims Svecovs <maksims.svecovs@arm.com>
+:|G|: `max-shvetsov`_
+:|M|: Joao Alves <Joao.Alves@arm.com>
+:|G|: `J-Alves`_
+:|F|: services/std_svc/spm\*
Exception Handling Framework (EHF)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Manish Badarkhe <manish.badarkhe@arm.com>
-:G: `ManishVB-Arm`_
-:M: John Powell <John.Powell@arm.com>
-:G: `john-powell-arm`_
-:F: bl31/ehf.c
+:|M|: Manish Badarkhe <manish.badarkhe@arm.com>
+:|G|: `ManishVB-Arm`_
+:|M|: John Powell <john.powell@arm.com>
+:|G|: `john-powell-arm`_
+:|F|: bl31/ehf.c
+Realm Management Extension (RME)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Bipin Ravi <bipin.ravi@arm.com>
+:|G|: `bipinravi-arm`_
+:|M|: Mark Dykes <mark.dykes@arm.com>
+:|G|: `mardyk01`_
+:|M|: John Powell <john.powell@arm.com>
+:|G|: `john-powell-arm`_
+:|M|: Zelalem Aweke <Zelalem.Aweke@arm.com>
+:|G|: `zelalem-aweke`_
Drivers, Libraries and Framework Code
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Console API framework
^^^^^^^^^^^^^^^^^^^^^
-:M: Julius Werner <jwerner@chromium.org>
-:G: `jwerner-chromium`_
-:F: drivers/console/
-:F: include/drivers/console.h
-:F: plat/common/aarch64/crash_console_helpers.S
+:|M|: Julius Werner <jwerner@chromium.org>
+:|G|: `jwerner-chromium`_
+:|F|: drivers/console/
+:|F|: include/drivers/console.h
+:|F|: plat/common/aarch64/crash_console_helpers.S
coreboot support libraries
^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Julius Werner <jwerner@chromium.org>
-:G: `jwerner-chromium`_
-:F: drivers/coreboot/
-:F: include/drivers/coreboot/
-:F: include/lib/coreboot.h
-:F: lib/coreboot/
+:|M|: Julius Werner <jwerner@chromium.org>
+:|G|: `jwerner-chromium`_
+:|F|: drivers/coreboot/
+:|F|: include/drivers/coreboot/
+:|F|: include/lib/coreboot.h
+:|F|: lib/coreboot/
eMMC/UFS drivers
^^^^^^^^^^^^^^^^
-:M: Haojian Zhuang <haojian.zhuang@linaro.org>
-:G: `hzhuang1`_
-:F: drivers/partition/
-:F: drivers/synopsys/emmc/
-:F: drivers/synopsys/ufs/
-:F: drivers/ufs/
-:F: include/drivers/dw_ufs.h
-:F: include/drivers/ufs.h
-:F: include/drivers/synopsys/dw_mmc.h
+:|M|: Haojian Zhuang <haojian.zhuang@linaro.org>
+:|G|: `hzhuang1`_
+:|F|: drivers/partition/
+:|F|: drivers/synopsys/emmc/
+:|F|: drivers/synopsys/ufs/
+:|F|: drivers/ufs/
+:|F|: include/drivers/dw_ufs.h
+:|F|: include/drivers/ufs.h
+:|F|: include/drivers/synopsys/dw_mmc.h
+
+JTAG DCC console driver
+^^^^^^^^^^^^^^^^^^^^^^^
+:M: Michal Simek <michal.simek@xilinx.com>
+:G: `michalsimek`_
+:M: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
+:G: `venkatesh`_
+:F: drivers/arm/dcc/
+:F: include/drivers/arm/dcc.h
Power State Coordination Interface (PSCI)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
-:G: `javieralso-arm`_
-:M: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
-:G: `madhukar-Arm`_
-:M: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
-:G: `laurenw-arm`_
-:M: Zelalem Aweke <Zelalem.Aweke@arm.com>
-:G: `zelalem-aweke`_
-:F: lib/psci/
+:|M|: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
+:|G|: `javieralso-arm`_
+:|M|: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
+:|G|: `madhukar-Arm`_
+:|M|: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
+:|G|: `laurenw-arm`_
+:|M|: Zelalem Aweke <Zelalem.Aweke@arm.com>
+:|G|: `zelalem-aweke`_
+:|F|: lib/psci/
DebugFS
^^^^^^^
-:M: Olivier Deprez <olivier.deprez@arm.com>
-:G: `odeprez`_
-:F: lib/debugfs/
+:|M|: Olivier Deprez <olivier.deprez@arm.com>
+:|G|: `odeprez`_
+:|F|: lib/debugfs/
Firmware Configuration Framework (FCONF)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
-:G: `madhukar-Arm`_
-:M: Manish Badarkhe <manish.badarkhe@arm.com>
-:G: `ManishVB-Arm`_
-:M: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
-:G: `laurenw-arm`_
-:F: lib/fconf/
+:|M|: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
+:|G|: `madhukar-Arm`_
+:|M|: Manish Badarkhe <manish.badarkhe@arm.com>
+:|G|: `ManishVB-Arm`_
+:|M|: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
+:|G|: `laurenw-arm`_
+:|F|: lib/fconf/
Performance Measurement Framework (PMF)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Joao Alves <Joao.Alves@arm.com>
-:G: `J-Alves`_
-:M: Jimmy Brisson <Jimmy.Brisson@arm.com>
-:G: `theotherjimmy`_
-:F: lib/pmf/
+:|M|: Joao Alves <Joao.Alves@arm.com>
+:|G|: `J-Alves`_
+:|M|: Jimmy Brisson <Jimmy.Brisson@arm.com>
+:|G|: `theotherjimmy`_
+:|F|: lib/pmf/
Arm CPU libraries
^^^^^^^^^^^^^^^^^
-:M: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
-:G: `laurenw-arm`_
-:M: John Powell <John.Powell@arm.com>
-:G: `john-powell-arm`_
-:F: lib/cpus/
+:|M|: Lauren Wehrmeister <Lauren.Wehrmeister@arm.com>
+:|G|: `laurenw-arm`_
+:|M|: John Powell <john.powell@arm.com>
+:|G|: `john-powell-arm`_
+:|F|: lib/cpus/
Reliability Availability Serviceabilty (RAS) framework
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Olivier Deprez <olivier.deprez@arm.com>
-:G: `odeprez`_
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:F: lib/extensions/ras/
+:|M|: Olivier Deprez <olivier.deprez@arm.com>
+:|G|: `odeprez`_
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|F|: lib/extensions/ras/
Activity Monitors Unit (AMU) extensions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Alexei Fedorov <Alexei.Fedorov@arm.com>
-:G: `AlexeiFedorov`_
-:F: lib/extensions/amu/
+:|M|: Alexei Fedorov <Alexei.Fedorov@arm.com>
+:|G|: `AlexeiFedorov`_
+:|M|: Chris Kay <chris.kay@arm.com>
+:|G|: `CJKay`_
+:|F|: lib/extensions/amu/
Memory Partitioning And Monitoring (MPAM) extensions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Zelalem Aweke <Zelalem.Aweke@arm.com>
-:G: `zelalem-aweke`_
-:M: Jimmy Brisson <Jimmy.Brisson@arm.com>
-:G: `theotherjimmy`_
-:F: lib/extensions/mpam/
+:|M|: Zelalem Aweke <Zelalem.Aweke@arm.com>
+:|G|: `zelalem-aweke`_
+:|M|: Jimmy Brisson <Jimmy.Brisson@arm.com>
+:|G|: `theotherjimmy`_
+:|F|: lib/extensions/mpam/
Pointer Authentication (PAuth) and Branch Target Identification (BTI) extensions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Alexei Fedorov <Alexei.Fedorov@arm.com>
-:G: `AlexeiFedorov`_
-:M: Zelalem Aweke <Zelalem.Aweke@arm.com>
-:G: `zelalem-aweke`_
-:F: lib/extensions/pauth/
+:|M|: Alexei Fedorov <Alexei.Fedorov@arm.com>
+:|G|: `AlexeiFedorov`_
+:|M|: Zelalem Aweke <Zelalem.Aweke@arm.com>
+:|G|: `zelalem-aweke`_
+:|F|: lib/extensions/pauth/
Statistical Profiling Extension (SPE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Zelalem Aweke <Zelalem.Aweke@arm.com>
-:G: `zelalem-aweke`_
-:M: Jimmy Brisson <Jimmy.Brisson@arm.com>
-:G: `theotherjimmy`_
-:F: lib/extensions/spe/
+:|M|: Zelalem Aweke <Zelalem.Aweke@arm.com>
+:|G|: `zelalem-aweke`_
+:|M|: Jimmy Brisson <Jimmy.Brisson@arm.com>
+:|G|: `theotherjimmy`_
+:|F|: lib/extensions/spe/
Scalable Vector Extension (SVE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Jimmy Brisson <Jimmy.Brisson@arm.com>
-:G: `theotherjimmy`_
-:F: lib/extensions/sve/
+:|M|: Jimmy Brisson <Jimmy.Brisson@arm.com>
+:|G|: `theotherjimmy`_
+:|F|: lib/extensions/sve/
Standard C library
^^^^^^^^^^^^^^^^^^
-:M: Alexei Fedorov <Alexei.Fedorov@arm.com>
-:G: `AlexeiFedorov`_
-:M: John Powell <John.Powell@arm.com>
-:G: `john-powell-arm`_
-:F: lib/libc/
+:|M|: Alexei Fedorov <Alexei.Fedorov@arm.com>
+:|G|: `AlexeiFedorov`_
+:|M|: John Powell <john.powell@arm.com>
+:|G|: `john-powell-arm`_
+:|F|: lib/libc/
Library At ROM (ROMlib)
^^^^^^^^^^^^^^^^^^^^^^^
-:M: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
-:G: `madhukar-Arm`_
-:F: lib/romlib/
+:|M|: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
+:|G|: `madhukar-Arm`_
+:|F|: lib/romlib/
Translation tables (``xlat_tables``) library
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
-:G: `javieralso-arm`_
-:M: Joao Alves <Joao.Alves@arm.com>
-:G: `J-Alves`_
-:F: lib/xlat\_tables_\*/
+:|M|: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
+:|G|: `javieralso-arm`_
+:|M|: Joao Alves <Joao.Alves@arm.com>
+:|G|: `J-Alves`_
+:|F|: lib/xlat\_tables_\*/
IO abstraction layer
^^^^^^^^^^^^^^^^^^^^
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:M: Olivier Deprez <olivier.deprez@arm.com>
-:G: `odeprez`_
-:F: drivers/io/
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|M|: Olivier Deprez <olivier.deprez@arm.com>
+:|G|: `odeprez`_
+:|F|: drivers/io/
GIC driver
^^^^^^^^^^
-:M: Alexei Fedorov <Alexei.Fedorov@arm.com>
-:G: `AlexeiFedorov`_
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:M: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
-:G: `madhukar-Arm`_
-:M: Olivier Deprez <olivier.deprez@arm.com>
-:G: `odeprez`_
-:F: drivers/arm/gic/
+:|M|: Alexei Fedorov <Alexei.Fedorov@arm.com>
+:|G|: `AlexeiFedorov`_
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|M|: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
+:|G|: `madhukar-Arm`_
+:|M|: Olivier Deprez <olivier.deprez@arm.com>
+:|G|: `odeprez`_
+:|F|: drivers/arm/gic/
Libfdt wrappers
^^^^^^^^^^^^^^^
-:M: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
-:G: `madhukar-Arm`_
-:M: Manish Badarkhe <manish.badarkhe@arm.com>
-:G: `ManishVB-Arm`_
-:F: common/fdt_wrappers.c
+:|M|: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
+:|G|: `madhukar-Arm`_
+:|M|: Manish Badarkhe <manish.badarkhe@arm.com>
+:|G|: `ManishVB-Arm`_
+:|F|: common/fdt_wrappers.c
Firmware Encryption Framework
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Sumit Garg <sumit.garg@linaro.org>
-:G: `b49020`_
-:F: drivers/io/io_encrypted.c
-:F: include/drivers/io/io_encrypted.h
-:F: include/tools_share/firmware_encrypted.h
+:|M|: Sumit Garg <sumit.garg@linaro.org>
+:|G|: `b49020`_
+:|F|: drivers/io/io_encrypted.c
+:|F|: include/drivers/io/io_encrypted.h
+:|F|: include/tools_share/firmware_encrypted.h
Measured Boot
^^^^^^^^^^^^^
-:M: Alexei Fedorov <Alexei.Fedorov@arm.com>
-:G: `AlexeiFedorov`_
-:M: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
-:G: `javieralso-arm`_
-:F: drivers/measured_boot
-:F: include/drivers/measured_boot
-:F: plat/arm/board/fvp/fvp_measured_boot.c
+:|M|: Alexei Fedorov <Alexei.Fedorov@arm.com>
+:|G|: `AlexeiFedorov`_
+:|M|: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
+:|G|: `javieralso-arm`_
+:|F|: drivers/measured_boot
+:|F|: include/drivers/measured_boot
+:|F|: plat/arm/board/fvp/fvp_measured_boot.c
+
+System Control and Management Interface (SCMI) Server
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Etienne Carriere <etienne.carriere@st.com>
+:|G|: `etienne-lms`_
+:|M|: Peng Fan <peng.fan@nxp.com>
+:|G|: `MrVan`_
+:|F|: drivers/scmi-msg
+:|F|: include/drivers/scmi\*
+
+Max Power Mitigation Mechanism (MPMM)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Chris Kay <chris.kay@arm.com>
+:|G|: `CJKay`_
+:|F|: include/lib/mpmm/
+:|F|: lib/mpmm/
+
+Granule Protection Tables Library (GPT-RME)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Mark Dykes <mark.dykes@arm.com>
+:|G|: `mardyk01`_
+:|M|: John Powell <john.powell@arm.com>
+:|G|: `john-powell-arm`_
+:|F|: lib/gpt_rme
+:|F|: include/lib/gpt_rme
Platform Ports
~~~~~~~~~~~~~~
Allwinner ARMv8 platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Andre Przywara <andre.przywara@arm.com>
-:G: `Andre-ARM`_
-:M: Samuel Holland <samuel@sholland.org>
-:G: `smaeul`_
-:F: docs/plat/allwinner.rst
-:F: plat/allwinner/
-:F: drivers/allwinner/
+:|M|: Andre Przywara <andre.przywara@arm.com>
+:|G|: `Andre-ARM`_
+:|M|: Samuel Holland <samuel@sholland.org>
+:|G|: `smaeul`_
+:|F|: docs/plat/allwinner.rst
+:|F|: plat/allwinner/
+:|F|: drivers/allwinner/
Amlogic Meson S905 (GXBB) platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Andre Przywara <andre.przywara@arm.com>
-:G: `Andre-ARM`_
-:F: docs/plat/meson-gxbb.rst
-:F: drivers/amlogic/
-:F: plat/amlogic/gxbb/
+:|M|: Andre Przywara <andre.przywara@arm.com>
+:|G|: `Andre-ARM`_
+:|F|: docs/plat/meson-gxbb.rst
+:|F|: drivers/amlogic/
+:|F|: plat/amlogic/gxbb/
Amlogic Meson S905x (GXL) platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Remi Pommarel <repk@triplefau.lt>
-:G: `remi-triplefault`_
-:F: docs/plat/meson-gxl.rst
-:F: plat/amlogic/gxl/
+:|M|: Remi Pommarel <repk@triplefau.lt>
+:|G|: `remi-triplefault`_
+:|F|: docs/plat/meson-gxl.rst
+:|F|: plat/amlogic/gxl/
Amlogic Meson S905X2 (G12A) platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Carlo Caione <ccaione@baylibre.com>
-:G: `carlocaione`_
-:F: docs/plat/meson-g12a.rst
-:F: plat/amlogic/g12a/
+:|M|: Carlo Caione <ccaione@baylibre.com>
+:|G|: `carlocaione`_
+:|F|: docs/plat/meson-g12a.rst
+:|F|: plat/amlogic/g12a/
Amlogic Meson A113D (AXG) platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Carlo Caione <ccaione@baylibre.com>
-:G: `carlocaione`_
-:F: docs/plat/meson-axg.rst
-:F: plat/amlogic/axg/
+:|M|: Carlo Caione <ccaione@baylibre.com>
+:|G|: `carlocaione`_
+:|F|: docs/plat/meson-axg.rst
+:|F|: plat/amlogic/axg/
Arm FPGA platform port
^^^^^^^^^^^^^^^^^^^^^^
-:M: Andre Przywara <andre.przywara@arm.com>
-:G: `Andre-ARM`_
-:M: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
-:G: `javieralso-arm`_
-:F: plat/arm/board/arm_fpga
+:|M|: Andre Przywara <andre.przywara@arm.com>
+:|G|: `Andre-ARM`_
+:|M|: Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>
+:|G|: `javieralso-arm`_
+:|F|: plat/arm/board/arm_fpga
-Arm System Guidance for Infrastructure / Mobile FVP platforms
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Nariman Poushin <nariman.poushin@linaro.org>
-:G: `npoushin`_
-:M: Thomas Abraham <thomas.abraham@arm.com>
-:G: `thomas-arm`_
-:F: plat/arm/css/sgi/
-:F: plat/arm/css/sgm/
-:F: plat/arm/board/sgi575/
-:F: plat/arm/board/sgm775/
+Arm FVP Platform port
+^^^^^^^^^^^^^^^^^^^^^
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|M|: Madhukar Pappireddy <Madhukar.Pappireddy@arm.com>
+:|G|: `madhukar-Arm`_
+:|F|: plat/arm/board/fvp
+
+Arm Juno Platform port
+^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|M|: Chris Kay <chris.kay@arm.com>
+:|G|: `CJKay`_
+:|F|: plat/arm/board/juno
+
+Arm Morello and N1SDP Platform ports
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Manoj Kumar <manoj.kumar3@arm.com>
+:|G|: `manojkumar-arm`_
+:|M|: Chandni Cherukuri <chandni.cherukuri@arm.com>
+:|G|: `chandnich`_
+:|F|: plat/arm/board/morello
+:|F|: plat/arm/board/n1sdp
+
+Arm Rich IoT Platform ports
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
+:|G|: `abdellatif-elkhlifi`_
+:|M|: Vishnu Banavath <vishnu.banavath@arm.com>
+:|G|: `vishnu-banavath`_
+:|F|: plat/arm/board/corstone700
+:|F|: plat/arm/board/a5ds
+:|F|: plat/arm/board/diphda
+
+Arm Reference Design platform ports
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Thomas Abraham <thomas.abraham@arm.com>
+:|G|: `thomas-arm`_
+:|M|: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
+:|G|: `vijayenthiran-arm`_
+:|F|: plat/arm/css/sgi/
+:|F|: plat/arm/board/rde1edge/
+:|F|: plat/arm/board/rdn1edge/
+:|F|: plat/arm/board/rdn2/
+:|F|: plat/arm/board/rdv1/
+:|F|: plat/arm/board/rdv1mc/
+:|F|: plat/arm/board/sgi575/
+
+Arm Total Compute platform port
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
+:|G|: `arugan02`_
+:|M|: Usama Arif <usama.arif@arm.com>
+:|G|: `uarif1`_
+:|F|: plat/arm/board/tc
HiSilicon HiKey and HiKey960 platform ports
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Haojian Zhuang <haojian.zhuang@linaro.org>
-:G: `hzhuang1`_
-:F: docs/plat/hikey.rst
-:F: docs/plat/hikey960.rst
-:F: plat/hisilicon/hikey/
-:F: plat/hisilicon/hikey960/
+:|M|: Haojian Zhuang <haojian.zhuang@linaro.org>
+:|G|: `hzhuang1`_
+:|F|: docs/plat/hikey.rst
+:|F|: docs/plat/hikey960.rst
+:|F|: plat/hisilicon/hikey/
+:|F|: plat/hisilicon/hikey960/
HiSilicon Poplar platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Shawn Guo <shawn.guo@linaro.org>
-:G: `shawnguo2`_
-:F: docs/plat/poplar.rst
-:F: plat/hisilicon/poplar/
+:|M|: Shawn Guo <shawn.guo@linaro.org>
+:|G|: `shawnguo2`_
+:|F|: docs/plat/poplar.rst
+:|F|: plat/hisilicon/poplar/
Intel SocFPGA platform ports
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Tien Hock Loh <tien.hock.loh@intel.com>
-:G: `thloh85-intel`_
-:M: Hadi Asyrafi <muhammad.hadi.asyrafi.abdul.halim@intel.com>
-:G: mabdulha
-:F: plat/intel/soc
-:F: drivers/intel/soc/
+:|M|: Tien Hock Loh <tien.hock.loh@intel.com>
+:|G|: `thloh85-intel`_
+:|M|: Hadi Asyrafi <muhammad.hadi.asyrafi.abdul.halim@intel.com>
+:|G|: mabdulha
+:|F|: plat/intel/soc
+:|F|: drivers/intel/soc/
MediaTek platform ports
^^^^^^^^^^^^^^^^^^^^^^^
-:M: Yidi Lin (林以廸) <yidi.lin@mediatek.com>
-:G: `mtk09422`_
-:F: plat/mediatek/
+:|M|: Rex-BC Chen <rex-bc.chen@mediatek.com>
+:|G|: `mtk-rex-bc-chen`_
+:|F|: plat/mediatek/
Marvell platform ports and SoC drivers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Konstantin Porotchkin <kostap@marvell.com>
-:G: `kostapr`_
-:F: docs/plat/marvell/
-:F: plat/marvell/
-:F: drivers/marvell/
-:F: tools/marvell/
+:|M|: Konstantin Porotchkin <kostap@marvell.com>
+:|G|: `kostapr`_
+:|F|: docs/plat/marvell/
+:|F|: plat/marvell/
+:|F|: drivers/marvell/
+:|F|: tools/marvell/
NVidia platform ports
^^^^^^^^^^^^^^^^^^^^^
-:M: Varun Wadekar <vwadekar@nvidia.com>
-:G: `vwadekar`_
-:F: docs/plat/nvidia-tegra.rst
-:F: include/lib/cpus/aarch64/denver.h
-:F: lib/cpus/aarch64/denver.S
-:F: plat/nvidia/
+:|M|: Varun Wadekar <vwadekar@nvidia.com>
+:|G|: `vwadekar`_
+:|F|: docs/plat/nvidia-tegra.rst
+:|F|: include/lib/cpus/aarch64/denver.h
+:|F|: lib/cpus/aarch64/denver.S
+:|F|: plat/nvidia/
NXP QorIQ Layerscape platform ports
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Jiafei Pan <jiafei.pan@nxp.com>
-:G: `qoriq-open-source`_
-:F: docs/plat/ls1043a.rst
-:F: plat/layerscape/
+:|M|: Jiafei Pan <jiafei.pan@nxp.com>
+:|G|: `qoriq-open-source`_
+:|F|: docs/plat/ls1043a.rst
+:|F|: plat/layerscape/
NXP i.MX 7 WaRP7 platform port and SoC drivers
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
-:G: `bryanodonoghue`_
-:M: Jun Nie <jun.nie@linaro.org>
-:G: `niej`_
-:F: docs/plat/warp7.rst
-:F: plat/imx/common/
-:F: plat/imx/imx7/
-:F: drivers/imx/timer/
-:F: drivers/imx/uart/
-:F: drivers/imx/usdhc/
+:|M|: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+:|G|: `bryanodonoghue`_
+:|M|: Jun Nie <jun.nie@linaro.org>
+:|G|: `niej`_
+:|F|: docs/plat/warp7.rst
+:|F|: plat/imx/common/
+:|F|: plat/imx/imx7/
+:|F|: drivers/imx/timer/
+:|F|: drivers/imx/uart/
+:|F|: drivers/imx/usdhc/
NXP i.MX 8 platform port
^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Anson Huang <Anson.Huang@nxp.com>
-:G: `Anson-Huang`_
-:F: docs/plat/imx8.rst
-:F: plat/imx/
+:|M|: Peng Fan <peng.fan@nxp.com>
+:|G|: `MrVan`_
+:|F|: docs/plat/imx8.rst
+:|F|: plat/imx/
NXP i.MX8M platform port
^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Jacky Bai <ping.bai@nxp.com>
-:G: `JackyBai`_
-:F: docs/plat/imx8m.rst
-:F: plat/imx/imx8m/
+:|M|: Jacky Bai <ping.bai@nxp.com>
+:|G|: `JackyBai`_
+:|F|: docs/plat/imx8m.rst
+:|F|: plat/imx/imx8m/
+
+NXP QorIQ Layerscape common code for platform ports
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Pankaj Gupta <pankaj.gupta@nxp.com>
+:|G|: `pangupta`_
+:|F|: docs/plat/nxp/
+:|F|: plat/nxp/
+:|F|: drivers/nxp/
+:|F|: tools/nxp/
+
+NXP SoC Part LX2160A and its platform port
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Pankaj Gupta <pankaj.gupta@nxp.com>
+:|G|: `pangupta`_
+:|F|: plat/nxp/soc-lx2160a
+:|F|: plat/nxp/soc-lx2160a/lx2162aqds
+:|F|: plat/nxp/soc-lx2160a/lx2160aqds
+:|F|: plat/nxp/soc-lx2160a/lx2160ardb
QEMU platform port
^^^^^^^^^^^^^^^^^^
-:M: Jens Wiklander <jens.wiklander@linaro.org>
-:G: `jenswi-linaro`_
-:F: docs/plat/qemu.rst
-:F: plat/qemu/
+:|M|: Jens Wiklander <jens.wiklander@linaro.org>
+:|G|: `jenswi-linaro`_
+:|F|: docs/plat/qemu.rst
+:|F|: plat/qemu/
QTI platform port
^^^^^^^^^^^^^^^^^
-:M: Saurabh Gorecha <sgorecha@codeaurora.org>
-:G: `sgorecha`_
-:M: Debasish Mandal <dmandal@codeaurora.org>
-:M: QTI TF Maintainers <qti.trustedfirmware.maintainers@codeaurora.org>
-:F: docs/plat/qti.rst
-:F: plat/qti/
+:|M|: Saurabh Gorecha <sgorecha@codeaurora.org>
+:|G|: `sgorecha`_
+:|M|: Lachit Patel <lpatel@codeaurora.org>
+:|G|: `lachitp`_
+:|M|: Sreevyshanavi Kare <skare@codeaurora.org>
+:|G|: `sreekare`_
+:|M|: QTI TF Maintainers <qti.trustedfirmware.maintainers@codeaurora.org>
+:|F|: docs/plat/qti.rst
+:|F|: plat/qti/
Raspberry Pi 3 platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
-:G: `grandpaul`_
-:F: docs/plat/rpi3.rst
-:F: plat/rpi/rpi3/
-:F: plat/rpi/common/
-:F: drivers/rpi3/
-:F: include/drivers/rpi3/
+:|M|: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org>
+:|G|: `grandpaul`_
+:|F|: docs/plat/rpi3.rst
+:|F|: plat/rpi/rpi3/
+:|F|: plat/rpi/common/
+:|F|: drivers/rpi3/
+:|F|: include/drivers/rpi3/
Raspberry Pi 4 platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Andre Przywara <andre.przywara@arm.com>
-:G: `Andre-ARM`_
-:F: docs/plat/rpi4.rst
-:F: plat/rpi/rpi4/
-:F: plat/rpi/common/
-:F: drivers/rpi3/
-:F: include/drivers/rpi3/
+:|M|: Andre Przywara <andre.przywara@arm.com>
+:|G|: `Andre-ARM`_
+:|F|: docs/plat/rpi4.rst
+:|F|: plat/rpi/rpi4/
+:|F|: plat/rpi/common/
+:|F|: drivers/rpi3/
+:|F|: include/drivers/rpi3/
Renesas rcar-gen3 platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
-:G: `ldts`_
-:M: Marek Vasut <marek.vasut@gmail.com>
-:G: `marex`_
-:F: docs/plat/rcar-gen3.rst
-:F: plat/renesas/rcar
-:F: drivers/renesas/rcar
-:F: tools/renesas/rcar_layout_create
+:|M|: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
+:|G|: `ldts`_
+:|M|: Marek Vasut <marek.vasut@gmail.com>
+:|G|: `marex`_
+:|F|: docs/plat/rcar-gen3.rst
+:|F|: plat/renesas/common
+:|F|: plat/renesas/rcar
+:|F|: drivers/renesas/common
+:|F|: drivers/renesas/rcar
+:|F|: tools/renesas/rcar_layout_create
+
+Renesas RZ/G2 platform port
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+:|M|: Biju Das <biju.das.jz@bp.renesas.com>
+:|G|: `bijucdas`_
+:|M|: Marek Vasut <marek.vasut@gmail.com>
+:|G|: `marex`_
+:|M|: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
+:|G|: `prabhakarlad`_
+:|F|: docs/plat/rz-g2.rst
+:|F|: plat/renesas/common
+:|F|: plat/renesas/rzg
+:|F|: drivers/renesas/common
+:|F|: drivers/renesas/rzg
+:|F|: tools/renesas/rzg_layout_create
RockChip platform port
^^^^^^^^^^^^^^^^^^^^^^
-:M: Tony Xie <tony.xie@rock-chips.com>
-:G: `TonyXie06`_
-:G: `rockchip-linux`_
-:M: Heiko Stuebner <heiko@sntech.de>
-:G: `mmind`_
-:F: plat/rockchip/
+:|M|: Tony Xie <tony.xie@rock-chips.com>
+:|G|: `TonyXie06`_
+:|G|: `rockchip-linux`_
+:|M|: Heiko Stuebner <heiko@sntech.de>
+:|G|: `mmind`_
+:|M|: Julius Werner <jwerner@chromium.org>
+:|G|: `jwerner-chromium`_
+:|F|: plat/rockchip/
STM32MP1 platform port
^^^^^^^^^^^^^^^^^^^^^^
-:M: Yann Gautier <yann.gautier@st.com>
-:G: `Yann-lms`_
-:F: docs/plat/stm32mp1.rst
-:F: drivers/st/
-:F: fdts/stm32\*
-:F: include/drivers/st/
-:F: include/dt-bindings/\*/stm32\*
-:F: plat/st/
-:F: tools/stm32image/
+:|M|: Yann Gautier <yann.gautier@st.com>
+:|G|: `Yann-lms`_
+:|F|: docs/plat/stm32mp1.rst
+:|F|: drivers/st/
+:|F|: fdts/stm32\*
+:|F|: include/drivers/st/
+:|F|: include/dt-bindings/\*/stm32\*
+:|F|: plat/st/
+:|F|: tools/stm32image/
Synquacer platform port
^^^^^^^^^^^^^^^^^^^^^^^
-:M: Sumit Garg <sumit.garg@linaro.org>
-:G: `b49020`_
-:F: docs/plat/synquacer.rst
-:F: plat/socionext/synquacer/
+:|M|: Sumit Garg <sumit.garg@linaro.org>
+:|G|: `b49020`_
+:|F|: docs/plat/synquacer.rst
+:|F|: plat/socionext/synquacer/
Texas Instruments platform port
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Andrew F. Davis <afd@ti.com>
-:G: `glneo`_
-:F: docs/plat/ti-k3.rst
-:F: plat/ti/
+:|M|: Nishanth Menon <nm@ti.com>
+:|G|: `nmenon`_
+:|F|: docs/plat/ti-k3.rst
+:|F|: plat/ti/
UniPhier platform port
^^^^^^^^^^^^^^^^^^^^^^
-:M: Orphan
-:F: docs/plat/socionext-uniphier.rst
-:F: plat/socionext/uniphier/
+:|M|: Orphan
+:|F|: docs/plat/socionext-uniphier.rst
+:|F|: plat/socionext/uniphier/
Xilinx platform port
^^^^^^^^^^^^^^^^^^^^
-:M: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
-:G: `sivadur`_
-:F: docs/plat/xilinx-zynqmp.rst
-:F: plat/xilinx/
+:|M|: Michal Simek <michal.simek@xilinx.com>
+:|G|: `michalsimek`_
+:|M|: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
+:|G|: `venkatesh`_
+:|F|: docs/plat/xilinx-zynqmp.rst
+:|F|: plat/xilinx/
Secure Payloads and Dispatchers
@@ -540,65 +677,80 @@
OP-TEE dispatcher
^^^^^^^^^^^^^^^^^
-:M: Jens Wiklander <jens.wiklander@linaro.org>
-:G: `jenswi-linaro`_
-:F: docs/components/spd/optee-dispatcher.rst
-:F: services/spd/opteed/
+:|M|: Jens Wiklander <jens.wiklander@linaro.org>
+:|G|: `jenswi-linaro`_
+:|F|: docs/components/spd/optee-dispatcher.rst
+:|F|: services/spd/opteed/
TLK/Trusty secure payloads
^^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Varun Wadekar <vwadekar@nvidia.com>
-:G: `vwadekar`_
-:F: docs/components/spd/tlk-dispatcher.rst
-:F: docs/components/spd/trusty-dispatcher.rst
-:F: include/bl32/payloads/tlk.h
-:F: services/spd/tlkd/
-:F: services/spd/trusty/
+:|M|: Varun Wadekar <vwadekar@nvidia.com>
+:|G|: `vwadekar`_
+:|F|: docs/components/spd/tlk-dispatcher.rst
+:|F|: docs/components/spd/trusty-dispatcher.rst
+:|F|: include/bl32/payloads/tlk.h
+:|F|: services/spd/tlkd/
+:|F|: services/spd/trusty/
Test Secure Payload (TSP)
^^^^^^^^^^^^^^^^^^^^^^^^^
-:M: Manish Badarkhe <manish.badarkhe@arm.com>
-:G: `ManishVB-Arm`_
-:F: bl32/tsp/
-:F: services/spd/tspd/
+:|M|: Manish Badarkhe <manish.badarkhe@arm.com>
+:|G|: `ManishVB-Arm`_
+:|F|: bl32/tsp/
+:|F|: services/spd/tspd/
Tools
~~~~~
Fiptool
^^^^^^^
-:M: Joao Alves <Joao.Alves@arm.com>
-:G: `J-Alves`_
-:F: tools/fiptool/
+:|M|: Joao Alves <Joao.Alves@arm.com>
+:|G|: `J-Alves`_
+:|F|: tools/fiptool/
Cert_create tool
^^^^^^^^^^^^^^^^
-:M: Sandrine Bailleux <sandrine.bailleux@arm.com>
-:G: `sandrine-bailleux-arm`_
-:F: tools/cert_create/
+:|M|: Sandrine Bailleux <sandrine.bailleux@arm.com>
+:|G|: `sandrine-bailleux-arm`_
+:|F|: tools/cert_create/
Encrypt_fw tool
^^^^^^^^^^^^^^^
-:M: Sumit Garg <sumit.garg@linaro.org>
-:G: `b49020`_
-:F: tools/encrypt_fw/
+:|M|: Sumit Garg <sumit.garg@linaro.org>
+:|G|: `b49020`_
+:|F|: tools/encrypt_fw/
Sptool
^^^^^^
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:F: tools/sptool/
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|F|: tools/sptool/
Build system
^^^^^^^^^^^^
-:M: Manish Pandey <manish.pandey2@arm.com>
-:G: `manish-pandey-arm`_
-:F: Makefile
-:F: make_helpers/
+:|M|: Manish Pandey <manish.pandey2@arm.com>
+:|G|: `manish-pandey-arm`_
+:|F|: Makefile
+:|F|: make_helpers/
+
+Threat Model
+~~~~~~~~~~~~~
+:|M|: Zelalem Aweke <Zelalem.Aweke@arm.com>
+:|G|: `zelalem-aweke`_
+:|M|: Sandrine Bailleux <sandrine.bailleux@arm.com>
+:|G|: `sandrine-bailleux-arm`_
+:|M|: Joanna Farley <joanna.farley@arm.com>
+:|G|: `joannafarley-arm`_
+:|M|: Raghu Krishnamurthy <raghu.ncstate@icloud.com>
+:|G|: `raghuncstate`_
+:|M|: Varun Wadekar <vwadekar@nvidia.com>
+:|G|: `vwadekar`_
+:|F|: docs/threat_model/
.. _AlexeiFedorov: https://github.com/AlexeiFedorov
.. _Andre-ARM: https://github.com/Andre-ARM
.. _Anson-Huang: https://github.com/Anson-Huang
+.. _bijucdas: https://github.com/bijucdas
.. _bryanodonoghue: https://github.com/bryanodonoghue
.. _b49020: https://github.com/b49020
.. _carlocaione: https://github.com/carlocaione
@@ -611,26 +763,31 @@
.. _jenswi-linaro: https://github.com/jenswi-linaro
.. _jwerner-chromium: https://github.com/jwerner-chromium
.. _kostapr: https://github.com/kostapr
+.. _lachitp: https://github.com/lachitp
.. _ldts: https://github.com/ldts
.. _marex: https://github.com/marex
.. _masahir0y: https://github.com/masahir0y
+.. _michalsimek: https://github.com/michalsimek
.. _mmind: https://github.com/mmind
-.. _mtk09422: https://github.com/mtk09422
+.. _MrVan: https://github.com/MrVan
+.. _mtk-rex-bc-chen: https://github.com/mtk-rex-bc-chen
.. _niej: https://github.com/niej
.. _npoushin: https://github.com/npoushin
+.. _prabhakarlad: https://github.com/prabhakarlad
.. _qoriq-open-source: https://github.com/qoriq-open-source
.. _remi-triplefault: https://github.com/repk
.. _rockchip-linux: https://github.com/rockchip-linux
.. _sandrine-bailleux-arm: https://github.com/sandrine-bailleux-arm
.. _sgorecha: https://github.com/sgorecha
.. _shawnguo2: https://github.com/shawnguo2
-.. _sivadur: https://github.com/sivadur
.. _smaeul: https://github.com/smaeul
.. _soby-mathew: https://github.com/soby-mathew
+.. _sreekare: https://github.com/sreekare
.. _thloh85-intel: https://github.com/thloh85-intel
.. _thomas-arm: https://github.com/thomas-arm
.. _TonyXie06: https://github.com/TonyXie06
.. _vwadekar: https://github.com/vwadekar
+.. _venkatesh: https://github.com/vabbarap
.. _Yann-lms: https://github.com/Yann-lms
.. _manish-pandey-arm: https://github.com/manish-pandey-arm
.. _mardyk01: https://github.com/mardyk01
@@ -648,5 +805,14 @@
.. _john-powell-arm: https://github.com/john-powell-arm
.. _raghuncstate: https://github.com/raghuncstate
.. _CJKay: https://github.com/cjkay
+.. _nmenon: https://github.com/nmenon
+.. _manojkumar-arm: https://github.com/manojkumar-arm
+.. _chandnich: https://github.com/chandnich
+.. _abdellatif-elkhlifi: https://github.com/abdellatif-elkhlifi
+.. _vishnu-banavath: https://github.com/vishnu-banavath
+.. _vijayenthiran-arm: https://github.com/vijayenthiran-arm
+.. _arugan02: https://github.com/arugan02
+.. _uarif1: https://github.com/uarif1
+.. _pangupta: https://github.com/pangupta
.. _Project Maintenance Process: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-process/
diff --git a/docs/about/release-information.rst b/docs/about/release-information.rst
index 55c8bda..b65571d 100644
--- a/docs/about/release-information.rst
+++ b/docs/about/release-information.rst
@@ -44,7 +44,9 @@
+-----------------+---------------------------+------------------------------+
| v2.4 | 2nd week of Nov '20 | 4th week of Oct '20 |
+-----------------+---------------------------+------------------------------+
-| v2.5 | 2nd week of May '21 | 4th week of Apr '21 |
+| v2.5 | 3rd week of May '21 | 5th week of Apr '21 |
++-----------------+---------------------------+------------------------------+
+| v2.6 | 4th week of Nov '21 | 2nd week of Nov '21 |
+-----------------+---------------------------+------------------------------+
Removal of Deprecated Interfaces
@@ -64,4 +66,4 @@
--------------
-*Copyright (c) 2018-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2018-2021, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/change-log-upcoming.rst b/docs/change-log-upcoming.rst
deleted file mode 100644
index 03806d9..0000000
--- a/docs/change-log-upcoming.rst
+++ /dev/null
@@ -1,149 +0,0 @@
-Change Log for Upcoming Release
-===============================
-
-This document contains a summary of the new features, changes, fixes and known
-issues to be included in the upcoming release of Trusted Firmware-A. The contents
-of this file will be moved to the collective change-log.rst file at the time of
-release code freeze.
-
-
-Upcoming Release Version 2.4
-----------------------------
-
-**Trusted Firmware-A Contributors,
-Please log all relevant new features, changes, fixes, and known issues for the
-upcoming release. For the CPU support, drivers, and tools sections please preface
-the log description with the relevant key word, example: "<CPU>: <CPU Support
-addition>". Use the RST format convention already used in the Change Log.**
-
-New Features
-^^^^^^^^^^^^
-
-- Arm Architecture
- - Example: "Add support for Branch Target Identification (BTI)"
-
-- BL-specific
- - Example: "Enhanced BL2 bootloader flow to load secure partitions based
- on firmware configuration data (fconf)."
-
-- Build System
- - Example: "Modify FVP makefile for CPUs that support both AArch64/32"
-
-- CPU Support
- - Example: "cortex-a55: Workaround for erratum 1221012"
-
-- Drivers
- - Example: "console: Allow the console to register multiple times"
-
-- Libraries
- - Example: "Introduce BTI support in Library at ROM (romlib)"
-
-- New Platforms Support
- - Example: "qemu/qemu_sbsa: New platform support added for QEMU SBSA platform"
-
-- Platforms
- - Example: "arm/common: Introduce wrapper functions to setup secure watchdog"
-
-- PSCI
- - Example: "Adding new optional PSCI hook ``pwr_domain_on_finish_late``"
-
-- Security
- - Example: "UBSAN support and handlers"
-
-- Tools
- - Example: "fiptool: Add support to build fiptool on Windows."
-
-
-Changed
-^^^^^^^
-
-- Arm Architecture
- - Example: "Refactor ARMv8.3 Pointer Authentication support code"
-
-- BL-Specific
- - Example: "BL2: Invalidate dcache build option for BL2 entry at EL3"
-
-- Boot Flow
- - Example: "Add helper to parse BL31 parameters (both versions)"
-
-- Drivers
- - Example: "gicv3: Prevent pending G1S interrupt from becoming G0 interrupt"
-
-- Platforms
- - Example: "arm/common: Shorten the Firmware Update (FWU) process"
-
-- PSCI
- - Example: "PSCI: Lookup list of parent nodes to lock only once"
-
-- Secure Partition Manager (SPM)
- - Example: "Move shim layer to TTBR1_EL1"
-
-- Security
- - Example: "Refactor SPSR initialisation code"
-
-- Tools
- - Example: "cert_create: Remove RSA PKCS#1 v1.5 support"
-
-
-Resolved Issues
-^^^^^^^^^^^^^^^
-
-- Arm Architecture
- - Example: "Fix restoration of PAuth context"
-
-- BL-Specific
- - Example: "Fix BL31 crash reporting on AArch64 only platforms"
-
-- Build System
- - Example: "Remove several warnings reported with W=2 and W=1"
-
-- Code Quality
- - Example: "Unify type of "cpu_idx" across PSCI module"
-
-- CPU Support
- - Example: "cortex-a12: Fix MIDR mask"
-
-- Drivers
- - Example: "scmi: Fix wrong payload length"
-
-- Library Code
- - Example: "libc: Fix memchr implementation"
-
-- Platforms
- - Example: "rpi: rpi3: Fix compilation error when stack protector is enabled"
-
-- Security
- - Example: "AArch32: Disable Secure Cycle Counter"
-
-Deprecations
-^^^^^^^^^^^^
-
-- Common Code
- - Example: "Remove MULTI_CONSOLE_API flag and references to it"
-
-- Drivers
- - Example: "console: Remove deprecated finish_console_register"
-
-- Secure Partition Manager (SPM):
- - Example: "Prototype SPCI-based SPM (services/std_svc/spm) will be replaced
- with alternative methods of secure partitioning support."
-
-Known Issues
-^^^^^^^^^^^^
-
-- Build System
- - dtb: DTB creation not supported when building on a Windows host.
-
- This step in the build process is skipped when running on a Windows host. A
- known issue from the 1.6 release.
-
-- Platforms
- - arm/juno: System suspend from Linux does not function as documented in the
- user guide
-
- Following the instructions provided in the user guide document does not
- result in the platform entering system suspend state as expected. A message
- relating to the hdlcd driver failing to suspend will be emitted on the
- Linux terminal.
-
- - mediatek/mt6795: This platform does not build in this release
diff --git a/docs/change-log.rst b/docs/change-log.rst
index 3b8f836..9c47568 100644
--- a/docs/change-log.rst
+++ b/docs/change-log.rst
@@ -4,6 +4,675 @@
This document contains a summary of the new features, changes, fixes and known
issues in each release of Trusted Firmware-A.
+Version 2.5
+-----------
+
+New Features
+^^^^^^^^^^^^
+
+- Architecture support
+ - Added support for speculation barrier(``FEAT_SB``) for non-Armv8.5
+ platforms starting from Armv8.0
+ - Added support for Activity Monitors Extension version 1.1(``FEAT_AMUv1p1``)
+ - Added helper functions for Random number generator(``FEAT_RNG``) registers
+ - Added support for Armv8.6 Multi-threaded PMU extensions (``FEAT_MTPMU``)
+ - Added support for MTE Asymmetric Fault Handling extensions(``FEAT_MTE3``)
+ - Added support for Privileged Access Never extensions(``FEAT_PANx``)
+
+- Bootloader images
+ - Added PIE support for AArch32 builds
+ - Enable Trusted Random Number Generator service for BL32(sp_min)
+
+- Build System
+ - Added build option for Arm Feature Modifiers
+
+- Drivers
+ - Added support for interrupts in TZC-400 driver
+
+ - Broadcom
+ - Added support for I2C, MDIO and USB drivers
+
+ - Marvell
+ - Added support for secure read/write of dfc register-set
+ - Added support for thermal sensor driver
+ - Implement a3700_core_getc API in console driver
+ - Added rx training on 10G port
+
+ - Marvell Mochi
+ - Added support for cn913x in PCIe mode
+
+ - Marvell Armada A8K
+ - Added support for TRNG-IP-76 driver and accessing RNG register
+
+ - Mediatek MT8192
+ - Added support for following drivers
+ - MPU configuration for SCP/PCIe
+ - SPM suspend
+ - Vcore DVFS
+ - LPM
+ - PTP3
+ - UART save and restore
+ - Power-off
+ - PMIC
+ - CPU hotplug and MCDI support
+ - SPMC
+ - MPU
+
+ - Mediatek MT8195
+ - Added support for following drivers
+ - GPIO, NCDI, SPMC drivers
+ - Power-off
+ - CPU hotplug, reboot and MCDI
+ - Delay timer and sys timer
+ - GIC
+
+ - NXP
+ - Added support for
+ - non-volatile storage API
+ - chain of trust and trusted board boot using two modes: MBEDTLS and CSF
+ - fip-handler necessary for DDR initialization
+ - SMMU and console drivers
+ - crypto hardware accelerator driver
+ - following drivers: SD, EMMC, QSPI, FLEXSPI, GPIO, GIC, CSU, PMU, DDR
+ - NXP Security Monitor and SFP driver
+ - interconnect config APIs using ARM CCN-CCI driver
+ - TZC APIs to configure DDR region
+ - generic timer driver
+ - Device configuration driver
+
+ - IMX
+ - Added support for image loading and io-storage driver for TBBR fip booting
+
+ - Renesas
+ - Added support for PFC and EMMC driver
+
+ - RZ Family:
+ - G2N, G2E and G2H SoCs
+ - Added support for watchdog, QoS, PFC and DRAM initialization
+
+ - RZG Family:
+ - G2M
+ - Added support for QoS and DRAM initialization
+
+ - Xilinx
+ - Added JTAG DCC support for Versal and ZynqMP SoC family.
+
+- Libraries
+ - C standard library
+ - Added support to print ``%`` in ``snprintf()`` and ``printf()`` APIs
+ - Added support for strtoull, strtoll, strtoul, strtol APIs from FreeBSD project
+
+ - CPU support
+ - Added support for
+ - Cortex_A78C CPU
+ - Makalu ELP CPU
+ - Makalu CPU
+ - Matterhorn ELP CPU
+ - Neoverse-N2 CPU
+
+ - CPU Errata
+ - Arm Cortex-A76: Added workaround for erratum 1946160
+
+ - Arm Cortex-A77: Added workaround for erratum 1946167
+
+ - Arm Cortex-A78: Added workaround for erratum 1941498 and 1951500
+
+ - Arm Neoverse-N1: Added workaround for erratum 1946160
+
+ - Flattened device tree(libfdt)
+ - Added support for wrapper function to read UUIDs in string format from dtb
+
+- Platforms
+ - Added support for MediaTek MT8195
+ - Added support for Arm RD-N2 board
+
+ - Allwinner
+ - Added support for H616 SoC
+
+ - Arm
+ - Added support for GPT parser
+ - Protect GICR frames for fused/unused cores
+
+ - Arm Morello
+ - Added VirtIO network device to Morello FVP fdts
+
+ - Arm RD-N2
+ - Added support for variant 1 of RD-N2 platform
+ - Enable AMU support
+
+ - Arm RD-V1
+ - Enable AMU support
+
+ - Arm SGI
+ - Added support for platform variant build option
+
+ - Arm TC0
+ - Added Matterhorn ELP CPU support
+ - Added support for opteed
+
+ - Arm Juno
+ - Added support to use hw_config in BL31
+ - Use TRNG entropy source for SMCCC TRNG interface
+ - Condition Juno entropy source with CRC instructions
+
+ - Marvell Mochi
+ - Added support for detection of secure mode
+
+ - Marvell ARMADA
+ - Added support for new compile option A3720_DB_PM_WAKEUP_SRC
+ - Added support doing system reset via CM3 secure coprocessor
+ - Made several makefile enhancements required to build WTMI_MULTI_IMG and TIMDDRTOOL
+ - Added support for building DOIMAGETOOL tool
+ - Added new target mrvl_bootimage
+
+ - Mediatek MT8192
+ - Added support for rtc power off sequence
+
+ - Mediatek MT8195
+ - Added support for SiP service
+
+ - STM32MP1
+ - Added support for
+ - Seeed ODYSSEY SoM and board
+ - SDMMC2 and I2C2 pins in pinctrl
+ - I2C2 peripheral in DTS
+ - PIE for BL32
+ - TZC-400 interrupt managament
+ - Linux Automation MC-1 board
+
+ - Renesas RZG
+ - Added support for identifying EK874 RZ/G2E board
+ - Added support for identifying HopeRun HiHope RZ/G2H and RZ/G2H boards
+
+ - Rockchip
+ - Added support for stack protector
+
+ - QEMU
+ - Added support for ``max`` CPU
+ - Added Cortex-A72 support to ``virt`` platform
+ - Enabled trigger reboot from secure pl061
+
+ - QEMU SBSA
+ - Added support for sbsa-ref Embedded Controller
+
+ - NXP
+ - Added support for warm reset to retain ddr content
+ - Added support for image loader necessary for loading fip image
+
+ - lx2160a SoC Family
+ - Added support for
+ - new platform lx2160a-aqds
+ - new platform lx2160a-rdb
+ - new platform lx2162a-aqds
+ - errata handling
+
+ - IMX imx8mm
+ - Added support for trusted board boot
+
+ - TI K3
+ - Added support for lite device board
+ - Enabled Cortex-A72 erratum 1319367
+ - Enabled Cortex-A53 erratum 1530924
+
+ - Xilinx ZynqMP
+ - Added support for PS and system reset on WDT restart
+ - Added support for error management
+ - Enable support for log messages necessary for debug
+ - Added support for PM API SMC call for efuse and register access
+
+- Processes
+ - Introduced process for platform deprecation
+ - Added documentation for TF-A threat model
+ - Provided a copy of the MIT license to comply with the license
+ requirements of the arm-gic.h source file (originating from the Linux
+ kernel project and re-distributed in TF-A).
+
+- Services
+ - Added support for TRNG firmware interface service
+
+ - Arm
+ - Added SiP service to configure Ethos-N NPU
+
+ - SPMC
+ - Added documentation for SPM(Hafnium) SMMUv3 driver
+
+ - SPMD
+ - Added support for
+ - FFA_INTERRUPT forwading ABI
+ - FFA_SECONDARY_EP_REGISTER ABI
+ - FF-A v1.0 boot time power management, SPMC secondary core boot and
+ early run-time power management
+
+- Tools
+
+ - FIPTool
+ - Added mechanism to allow platform specific image UUID
+
+ - git hooks
+ - Added support for conventional commits through commitlint hook,
+ commitizen hook and husky configuration files.
+
+ - NXP tool
+ - Added support for a tool that creates pbl file from BL2
+
+ - Renesas RZ/G2
+ - Added tool support for creating bootparam and cert_header images
+
+ - CertCreate
+ - Added support for platform-defined certificates, keys, and extensions using
+ the platform's makefile
+
+ - shared tools
+ - Added EFI_GUID representation to uuid helper data structure
+
+Changed
+^^^^^^^
+
+- Common components
+ - Print newline after hex address in aarch64 el3_panic function
+ - Use proper ``#address-cells`` and ``#size-cells`` for reserved-memory in dtbs
+
+- Drivers
+
+ - Move SCMI driver from ST platform directory and make it common to all platforms
+
+ - Arm GICv3
+ - Shift eSPI register offset in GICD_OFFSET_64()
+ - Use mpidr to probe GICR for current CPU
+
+ - Arm TZC-400
+ - Adjust filter tag if it set to FILTER_BIT_ALL
+
+ - Cadence
+ - Enhance UART driver APIs to put characters to fifo
+
+ - Mediatek MT8192
+ - Move timer driver to common folder
+ - Enhanced sys_cirq driver to add more IC services
+
+ - Renesas
+ - Move ddr and delay driver to common directory
+
+ - Renesas rcar
+ - Treat log as device memory in console driver
+
+ - Renesas RZ Family:
+ - G2N and G2H SoCs
+ - Select MMC_CH1 for eMMC channel
+
+ - Marvell
+ - Added support for checking if TRNG unit is present
+
+ - Marvell A3K
+ - Set TXDCLK_2X_SEL bit during PCIe initialization
+ - Set mask parameter for every reg_set call
+
+ - Marvell Mochi
+ - Added missing stream IDs configurations
+
+ - MbedTLS
+ - Migrated to Mbed TLS v2.26.0
+
+ - IMX imx8mp
+ - Change the bl31 physical load address
+
+ - QEMU SBSA
+ - Enable secure variable storage
+
+ - SCMI
+ - Update power domain protocol version to 2.0
+
+ - STM32
+ - Remove dead code from nand FMC driver
+
+- Libraries
+ - C Standard Library
+ - Use macros to reduce duplicated code between snprintf and printf
+
+ - CPU support
+ - Sanity check pointers before use in AArch32 builds
+
+ - Arm Cortex-A78
+ - Remove rainier cpu workaround for errata 1542319
+
+ - Arm Makalu ELP
+ - Added "_arm" suffix to Makalu ELP CPU lib
+
+
+- Miscellaneous
+ - Editorconfig
+ - set max line length to 100
+
+- Platforms
+ - Allwinner
+ - Added reserved-memory node to DT
+ - Express memmap more dynamically
+ - Move SEPARATE_NOBITS_REGION to platforms
+ - Limit FDT checks to reduce code size
+ - Use CPUIDLE hardware when available
+ - Allow conditional compilation of SCPI and native PSCI ops
+ - Always use a 3MHz RSB bus clock
+ - Enable workaround for Cortex-A53 erratum 1530924
+ - Fixed non-default PRELOADED_BL33_BASE
+ - Leave CPU power alone during BL31 setup
+ - Added several psci hooks enhancements to improve system shutdown/reset
+ sequence
+ - Return the PMIC to I2C mode after use
+ - Separate code to power off self and other CPUs
+ - Split native and SCPI-based PSCI implementations
+
+ - Allwinner H6
+ - Added R_PRCM security setup for H6 board
+ - Added SPC security setup for H6 board
+ - Use RSB for the PMIC connection on H6
+
+ - Arm
+ - Store UUID as a string, rather than ints
+ - Replace FIP base and size macro with a generic name
+ - Move compile time switch from source to dt file
+ - Don't provide NT_FW_CONFIG when booting hafnium
+ - Do not setup 'disabled' regulator
+ - Increase SP max size
+ - Remove false dependency of ARM_LINUX_KERNEL_AS_BL33 on RESET_TO_BL31
+ and allow it to be enabled independently
+
+ - Arm FVP
+ - Do not map GIC region in BL1 and BL2
+
+ - Arm Juno
+ - Refactor juno_getentropy() to return 64 bits on each call
+
+ - Arm Morello
+ - Remove "virtio-rng" from Morello FVP
+ - Enable virtIO P9 device for Morello fvp
+
+ - Arm RDV1
+ - Allow all PSCI callbacks on RD-V1
+ - Rename rddaniel to rdv1
+
+ - Arm RDV1MC
+ - Rename rddanielxlr to rdv1mc
+ - Initialize TZC-400 controllers
+
+ - Arm TC0
+ - Updated GICR base address
+ - Use scmi_dvfs clock index 1 for cores 4-7 through fdt
+ - Added reserved-memory node for OP-TEE fdts
+ - Enabled Theodul DSU in TC platform
+ - OP-TEE as S-EL1 SP with SPMC at S-EL2
+ - Update Matterhorm ELP DVFS clock index
+
+ - Arm SGI
+ - Allow access to TZC controller on all chips
+ - Define memory regions for multi-chip platforms
+ - Allow access to nor2 flash and system registers from S-EL0
+ - Define default list of memory regions for DMC-620 TZC
+ - Improve macros defining cper buffer memory region
+ - Refactor DMC-620 error handling SMC function id
+ - Refactor SDEI specific macros
+ - Added platform id value for RDN2 platform
+ - Refactored header file inclusions and inclusion of memory mapping
+
+ - Arm RDN2
+ - Allow usage of secure partitions on RDN2 platform
+ - Update GIC redistributor and TZC base address
+
+ - Arm SGM775
+ - Deprecate Arm sgm775 FVP platform
+
+ - Marvell
+ - Increase TX FIFO EMPTY timeout from 2ms to 3ms
+ - Update delay code to be compatible with 1200 MHz CPU
+
+ - Marvell ARMADA
+ - Postpone MSS CPU startup to BL31 stage
+ - Allow builds without MSS support
+ - Use MSS SRAM in secure mode
+ - Added missing FORCE, .PHONY and clean targets
+ - Cleanup MSS SRAM if used for copy
+ - Move definition of mrvl_flash target to common marvell_common.mk file
+ - Show informative build messages and blank lines
+
+ - Marvell ARMADA A3K
+ - Added a new target mrvl_uart which builds UART image
+ - Added checks that WTP, MV_DDR_PATH and CRYPTOPP_PATH are correctly defined
+ - Allow use of the system Crypto++ library
+ - Build $(WTMI_ENC_IMG) in $(BUILD_PLAT) directory
+ - Build intermediate files in $(BUILD_PLAT) directory
+ - Build UART image files directly in $(BUILD_UART) subdirectory
+ - Correctly set DDR_TOPOLOGY and CLOCKSPRESET for WTMI
+ - Do not use 'echo -e' in Makefile
+ - Improve 4GB DRAM usage from 3.375 GB to 3.75 GB
+ - Remove unused variable WTMI_SYSINIT_IMG from Makefile
+ - Simplify check if WTP variable is defined
+ - Split building $(WTMI_MULTI_IMG) and $(TIMDDRTOOL)
+
+ - Marvell ARMADA A8K
+ - Allow CP1/CP2 mapping at BLE stage
+
+ - Mediatek MT8183
+ - Added timer V20 compensation
+
+ - Nvidia Tegra
+ - Rename SMC API
+
+ - TI K3
+ - Make plat_get_syscnt_freq2 helper check CNT_FID0 register
+ - Fill non-message data fields in sec_proxy with 0x0
+ - Update ti_sci_msg_req_reboot ABI to include domain
+ - Enable USE_COHERENT_MEM only for the generic board
+ - Explicitly map SEC_SRAM_BASE to 0x0
+ - Use BL31_SIZE instead of computing
+ - Define the correct number of max table entries and increase SRAM size
+ to account for additional table
+
+ - Raspberry Pi4
+ - Switch to gicv2.mk and GICV2_SOURCES
+
+ - Renesas
+ - Move headers and assembly files to common folder
+
+ - Renesas rzg
+ - Added device tree memory node enhancements
+
+ - Rockchip
+ - Switch to using common gicv3.mk
+
+ - STM32MP1
+ - Set BL sizes regardless of flags
+
+ - QEMU
+ - Include gicv2.mk for compiling GICv2 source files
+ - Change DEVICE2 definition for MMU
+ - Added helper to calculate the position shift from MPIDR
+
+ - QEMU SBSA
+ - Include libraries for Cortex-A72
+ - Increase SHARED_RAM_SIZE
+ - Addes support in spm_mm for upto 512 cores
+ - Added support for topology handling
+
+ - QTI
+ - Mandate SMC implementation
+
+ - Xilinx
+ - Rename the IPI CRC checksum macro
+ - Use fno-jump-tables flag in CPPFLAGS
+
+ - Xilinx versal
+ - Added the IPI CRC checksum macro support
+ - Mark IPI calls secure/non-secure
+ - Enable sgi to communicate with linux using IPI
+ - Remove Cortex-A53 compilation
+
+ - Xilinx ZynqMP
+ - Configure counter frequency during initialization
+ - Filter errors related to clock gate permissions
+ - Implement pinctrl request/release EEMI API
+ - Reimplement pinctrl get/set config parameter EEMI API calls
+ - Reimplement pinctrl set/get function EEMI API
+ - Update error codes to match Linux and PMU Firmware
+ - Update PM version and support PM version check
+ - Update return type in query functions
+ - Added missing ids for 43/46/47dr devices
+ - Checked for DLL status before doing reset
+ - Disable ITAPDLYENA bit for zero ITAP delay
+ - Include GICv2 makefile
+ - Remove the custom crash implementation
+
+- Services
+
+ - SPMD
+ - Lock the g_spmd_pm structure
+ - Declare third cactus instance as UP SP
+ - Provide number of vCPUs and VM size for first SP
+ - Remove ``chosen`` node from SPMC manifests
+ - Move OP-TEE SP manifest DTS to FVP platform
+ - Update OP-TEE SP manifest with device-regions node
+ - Remove device-memory node from SPMC manifests
+
+ - SPM_MM
+ - Use sp_boot_info to set SP context
+
+ - SDEI
+ - Updata the affinity of shared event
+
+- Tools
+ - FIPtool
+ - Do not print duplicate verbose lines about building fiptool
+
+ - CertCreate
+ - Updated tool for platform defined certs, keys & extensions
+ - Create only requested certificates
+ - Avoid duplicates in extension stack
+
+Resolved Issues
+^^^^^^^^^^^^^^^
+- Several fixes for typos and mis-spellings in documentation
+
+- Build system
+ - Fixed ${FIP_NAME} to be rebuilt only when needed in Makefile
+ - Do not mark file targets as .PHONY target in Makefile
+
+- Drivers
+ - Authorization
+ - Avoid NV counter upgrade without certificate validation
+
+ - Arm GICv3
+ - Fixed logical issue for num_eints
+ - Limit SPI ID to avoid misjudgement in GICD_OFFSET()
+ - Fixed potential GICD context override with ESPI enabled
+
+ - Marvell A3700
+ - Fixed configuring polarity invert bits
+
+ - Arm TZC-400
+ - Correct FAIL_CONTROL Privileged bit
+ - Fixed logical error in FILTER_BIT definitions
+
+ - Renesas rcar
+ - Fixed several coding style violations reported by checkpatch
+
+- Libraries
+ - Arch helpers
+ - Fixed assertions in processing dynamic relocations for AArch64 builds
+
+ - C standard library
+ - Fixed MISRA issues in memset() ABI
+
+ - RAS
+ - Fixed bug of binary search in RAS interrupt handler
+
+- Platforms
+
+ - Arm
+ - Fixed missing copyrights in arm-gic.h file
+ - Fixed the order of header files in several dts files
+ - Fixed error message printing in board makefile
+ - Fixed bug of overriding the last node in image load helper API
+ - Fixed stdout-path in fdts files of TC0 and N1SDP platforms
+ - Turn ON/OFF redistributor in sync with GIC CPU interface ON/OFF for css platforms
+
+ - Arm FVP
+ - Fixed Generic Timer interrupt types in platform dts files
+
+ - Arm Juno
+ - Fixed parallel build issue for romlib config
+
+ - Arm SGI
+ - Fixed bug in SDEI receive event of RAS handler
+
+ - Intel Agilex
+ - Fixed PLAT_MAX_PWR_LVL value
+
+ - Marvell
+ - Fixed SPD handling in dram port
+
+ - Marvell ARMADA
+ - Fixed TRNG return SMC handling
+ - Fixed the logic used for LD selector mask
+ - Fixed MSS firmware loader for A8K family
+
+ - ST
+ - Fixed few violations reported by coverity static checks
+
+ - STM32MP1
+ - Fixed SELFREF_TO_X32 mask in ddr driver
+ - Do not keep mmc_device_info in stack
+ - Correct plat_crash_console_flush()
+
+ - QEMU SBSA
+ - Fixed memory type of secure NOR flash
+
+ - QTI
+ - Fixed NUM_APID and REG_APID_MAP() argument in SPMI driver
+
+ - Intel
+ - Do not keep mmc_device_info in stack
+
+ - Hisilicon
+ - Do not keep mmc_device_info in stack
+
+
+- Services
+
+ - EL3 runtime
+ - Fixed the EL2 context save/restore routine by removing EL2 generic
+ timer system registers
+ - Added fix for exception handler in BL31 by synchronizing pending EA
+ using DSB barrier
+
+ - SPMD
+ - Fixed error codes to use int32_t type
+
+ - TSPD
+ - Added bug fix in tspd interrupt handling when TSP_NS_INTR_ASYNC_PREEMPT is enabled
+
+ - TRNG
+ - Fixed compilation errors with -O0 compile option
+
+ - DebugFS
+ - Checked channel index before calling clone function
+
+ - PSCI
+ - Fixed limit of 256 CPUs caused by cast to unsigned char
+
+ - TSP
+ - Fixed compilation erros when built with GCC 11.0.0 toolchain
+
+- Tools
+ - FIPtool
+ - Do not call ``make clean`` for ``all`` target
+
+ - CertCreate
+ - Fixed bug to avoid cleaning when building the binary
+ - Used preallocated parts of the HASH struct to avoid leaking HASH struct fields
+ - Free arguments copied with strdup
+ - Free keys after use
+ - Free X509_EXTENSION structures on stack to avoid leaking them
+ - Optimized the code to avoid unnecessary attempts to create non-requested
+ certificates
+
Version 2.4
-----------
@@ -89,7 +758,7 @@
- Added workaround for erratum 1800714
- Added workaround for erratum 1925769
- - Arm Neoverse N1
+ - Arm Neoverse-N1
- Added workaround for erratum 1868343
- EL3 Runtime
@@ -689,10 +1358,10 @@
- arm/common: Allow boards to specify second DRAM Base address
and to define PLAT_ARM_TZC_FILTERS
- - arm/cornstone700: Add support for mhuv2 and stack protector
+ - arm/corstone700: Add support for mhuv2 and stack protector
- arm/fvp: Add support for fconf in BL31 and SP_MIN. Populate power
- domain desciptor dynamically by leveraging fconf APIs.
+ domain descriptor dynamically by leveraging fconf APIs.
- arm/fvp: Add Cactus/Ivy Secure Partition information and use two
instances of Cactus at S-EL1
- arm/fvp: Add support to run BL32 in TDRAM and BL31 in secure DRAM
@@ -967,7 +1636,7 @@
cpu clock, Move versal_def.h and versal_private to include directory
- Tools
- - sptool: Updated sptool to accomodate building secure partition packages.
+ - sptool: Updated sptool to accommodate building secure partition packages.
Resolved Issues
^^^^^^^^^^^^^^^
diff --git a/docs/components/activity-monitors.rst b/docs/components/activity-monitors.rst
new file mode 100644
index 0000000..dd45c43
--- /dev/null
+++ b/docs/components/activity-monitors.rst
@@ -0,0 +1,34 @@
+Activity Monitors
+=================
+
+FEAT_AMUv1 of the Armv8-A architecture introduces the Activity Monitors
+extension. This extension describes the architecture for the Activity Monitor
+Unit (|AMU|), an optional non-invasive component for monitoring core events
+through a set of 64-bit counters.
+
+When the ``ENABLE_AMU=1`` build option is provided, Trusted Firmware-A sets up
+the |AMU| prior to its exit from EL3, and will save and restore architected
+|AMU| counters as necessary upon suspend and resume.
+
+.. _Activity Monitor Auxiliary Counters:
+
+Auxiliary counters
+------------------
+
+FEAT_AMUv1 describes a set of implementation-defined auxiliary counters (also
+known as group 1 counters), controlled by the ``ENABLE_AMU_AUXILIARY_COUNTERS``
+build option.
+
+As a security precaution, Trusted Firmware-A does not enable these by default.
+Instead, platforms may configure their auxiliary counters through one of two
+possible mechanisms:
+
+- |FCONF|, controlled by the ``ENABLE_AMU_FCONF`` build option.
+- A platform implementation of the ``plat_amu_topology`` function (the default).
+
+See :ref:`Activity Monitor Unit (AMU) Bindings` for documentation on the |FCONF|
+device tree bindings.
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
diff --git a/docs/components/fconf/amu-bindings.rst b/docs/components/fconf/amu-bindings.rst
new file mode 100644
index 0000000..047f75e
--- /dev/null
+++ b/docs/components/fconf/amu-bindings.rst
@@ -0,0 +1,142 @@
+Activity Monitor Unit (AMU) Bindings
+====================================
+
+To support platform-defined Activity Monitor Unit (|AMU|) auxiliary counters
+through FCONF, the ``HW_CONFIG`` device tree accepts several |AMU|-specific
+nodes and properties.
+
+Bindings
+^^^^^^^^
+
+.. contents::
+ :local:
+
+``/cpus/cpus/cpu*`` node properties
+"""""""""""""""""""""""""""""""""""
+
+The ``cpu`` node has been augmented to support a handle to an associated |AMU|
+view, which should describe the counters offered by the core.
+
++---------------+-------+---------------+-------------------------------------+
+| Property name | Usage | Value type | Description |
++===============+=======+===============+=====================================+
+| ``amu`` | O | ``<phandle>`` | If present, indicates that an |AMU| |
+| | | | is available and its counters are |
+| | | | described by the node provided. |
++---------------+-------+---------------+-------------------------------------+
+
+``/cpus/amus`` node properties
+""""""""""""""""""""""""""""""
+
+The ``amus`` node describes the |AMUs| implemented by the cores in the system.
+This node does not have any properties.
+
+``/cpus/amus/amu*`` node properties
+"""""""""""""""""""""""""""""""""""
+
+An ``amu`` node describes the layout and meaning of the auxiliary counter
+registers of one or more |AMUs|, and may be shared by multiple cores.
+
++--------------------+-------+------------+------------------------------------+
+| Property name | Usage | Value type | Description |
++====================+=======+============+====================================+
+| ``#address-cells`` | R | ``<u32>`` | Value shall be 1. Specifies that |
+| | | | the ``reg`` property array of |
+| | | | children of this node uses a |
+| | | | single cell. |
++--------------------+-------+------------+------------------------------------+
+| ``#size-cells`` | R | ``<u32>`` | Value shall be 0. Specifies that |
+| | | | no size is required in the ``reg`` |
+| | | | property in children of this node. |
++--------------------+-------+------------+------------------------------------+
+
+``/cpus/amus/amu*/counter*`` node properties
+""""""""""""""""""""""""""""""""""""""""""""
+
+A ``counter`` node describes an auxiliary counter belonging to the parent |AMU|
+view.
+
++-------------------+-------+-------------+------------------------------------+
+| Property name | Usage | Value type | Description |
++===================+=======+=============+====================================+
+| ``reg`` | R | array | Represents the counter register |
+| | | | index, and must be a single cell. |
++-------------------+-------+-------------+------------------------------------+
+| ``enable-at-el3`` | O | ``<empty>`` | The presence of this property |
+| | | | indicates that this counter should |
+| | | | be enabled prior to EL3 exit. |
++-------------------+-------+-------------+------------------------------------+
+
+Example
+^^^^^^^
+
+An example system offering four cores made up of two clusters, where the cores
+of each cluster share different |AMUs|, may use something like the following:
+
+.. code-block::
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ amus {
+ amu0: amu-0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ counterX: counter@0 {
+ reg = <0>;
+
+ enable-at-el3;
+ };
+
+ counterY: counter@1 {
+ reg = <1>;
+
+ enable-at-el3;
+ };
+ };
+
+ amu1: amu-1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ counterZ: counter@0 {
+ reg = <0>;
+
+ enable-at-el3;
+ };
+ };
+ };
+
+ cpu0@00000 {
+ ...
+
+ amu = <&amu0>;
+ };
+
+ cpu1@00100 {
+ ...
+
+ amu = <&amu0>;
+ };
+
+ cpu2@10000 {
+ ...
+
+ amu = <&amu1>;
+ };
+
+ cpu3@10100 {
+ ...
+
+ amu = <&amu1>;
+ };
+ }
+
+In this situation, ``cpu0`` and ``cpu1`` (the two cores in the first cluster),
+share the view of their AMUs defined by ``amu0``. Likewise, ``cpu2`` and
+``cpu3`` (the two cores in the second cluster), share the view of their |AMUs|
+defined by ``amu1``. This will cause ``counterX`` and ``counterY`` to be enabled
+for both ``cpu0`` and ``cpu1``, and ``counterZ`` to be enabled for both ``cpu2``
+and ``cpu3``.
diff --git a/docs/components/fconf/index.rst b/docs/components/fconf/index.rst
index 9020633..029f324 100644
--- a/docs/components/fconf/index.rst
+++ b/docs/components/fconf/index.rst
@@ -145,3 +145,5 @@
:maxdepth: 1
fconf_properties
+ amu-bindings
+ mpmm-bindings
diff --git a/docs/components/fconf/mpmm-bindings.rst b/docs/components/fconf/mpmm-bindings.rst
new file mode 100644
index 0000000..d3cc857
--- /dev/null
+++ b/docs/components/fconf/mpmm-bindings.rst
@@ -0,0 +1,48 @@
+Maximum Power Mitigation Mechanism (MPMM) Bindings
+==================================================
+
+|MPMM| support cannot be determined at runtime by the firmware. Instead, these
+DTB bindings allow the platform to communicate per-core support for |MPMM| via
+the ``HW_CONFIG`` device tree blob.
+
+Bindings
+^^^^^^^^
+
+.. contents::
+ :local:
+
+``/cpus/cpus/cpu*`` node properties
+"""""""""""""""""""""""""""""""""""
+
+The ``cpu`` node has been augmented to allow the platform to indicate support
+for |MPMM| on a given core.
+
++-------------------+-------+-------------+------------------------------------+
+| Property name | Usage | Value type | Description |
++===================+=======+=============+====================================+
+| ``supports-mpmm`` | O | ``<empty>`` | If present, indicates that |MPMM| |
+| | | | is available on this core. |
++-------------------+-------+-------------+------------------------------------+
+
+Example
+^^^^^^^
+
+An example system offering two cores, one with support for |MPMM| and one
+without, can be described as follows:
+
+.. code-block::
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu0@00000 {
+ ...
+
+ supports-mpmm;
+ };
+
+ cpu1@00100 {
+ ...
+ };
+ }
diff --git a/docs/components/ffa-manifest-binding.rst b/docs/components/ffa-manifest-binding.rst
new file mode 100644
index 0000000..df2985c
--- /dev/null
+++ b/docs/components/ffa-manifest-binding.rst
@@ -0,0 +1,252 @@
+FF-A manifest binding to device tree
+========================================
+
+This document defines the nodes and properties used to define a partition,
+according to the FF-A specification.
+
+Version 1.0
+-----------
+
+Partition Properties
+^^^^^^^^^^^^^^^^^^^^
+
+- compatible [mandatory]
+ - value type: <string>
+ - Must be the string "arm,ffa-manifest-X.Y" which specifies the major and
+ minor versions of the device tree binding for the FFA manifest represented
+ by this node. The minor number is incremented if the binding changes in a
+ backwards compatible manner.
+
+ - X is an integer representing the major version number of this document.
+ - Y is an integer representing the minor version number of this document.
+
+- ffa-version [mandatory]
+ - value type: <u32>
+ - Must be two 16 bits values (X, Y), concatenated as 31:16 -> X,
+ 15:0 -> Y, where:
+
+ - X is the major version of FF-A expected by the partition at the FFA
+ instance it will execute.
+ - Y is the minor version of FF-A expected by the partition at the FFA
+ instance it will execute.
+
+- uuid [mandatory]
+ - value type: <prop-encoded-array>
+ - An array consisting of 4 <u32> values, identifying the UUID of the service
+ implemented by this partition. The UUID format is described in RFC 4122.
+
+- id
+ - value type: <u32>
+ - Pre-allocated partition ID.
+
+- auxiliary-id
+ - value type: <u32>
+ - Pre-allocated ID that could be used in memory management transactions.
+
+- description
+ - value type: <string>
+ - Name of the partition e.g. for debugging purposes.
+
+- execution-ctx-count [mandatory]
+ - value type: <u32>
+ - Number of vCPUs that a VM or SP wants to instantiate.
+
+ - In the absence of virtualization, this is the number of execution
+ contexts that a partition implements.
+ - If value of this field = 1 and number of PEs > 1 then the partition is
+ treated as UP & migrate capable.
+ - If the value of this field > 1 then the partition is treated as a MP
+ capable partition irrespective of the number of PEs.
+
+- exception-level [mandatory]
+ - value type: <u32>
+ - The target exception level for the partition:
+
+ - 0x0: EL1
+ - 0x1: S_EL0
+ - 0x2: S_EL1
+
+- execution-state [mandatory]
+ - value type: <u32>
+ - The target execution state of the partition:
+
+ - 0: AArch64
+ - 1: AArch32
+
+- load-address
+ - value type: <u64>
+ - Physical base address of the partition in memory. Absence of this field
+ indicates that the partition is position independent and can be loaded at
+ any address chosen at boot time.
+
+- entrypoint-offset
+ - value type: <u64>
+ - Offset from the base of the partition's binary image to the entry point of
+ the partition. Absence of this field indicates that the entry point is at
+ offset 0x0 from the base of the partition's binary.
+
+- xlat-granule [mandatory]
+ - value type: <u32>
+ - Translation granule used with the partition:
+
+ - 0x0: 4k
+ - 0x1: 16k
+ - 0x2: 64k
+
+- boot-order
+ - value type: <u32>
+ - A unique number amongst all partitions that specifies if this partition
+ must be booted before others. The partition with the smaller number will be
+ booted first.
+
+- rx-tx-buffer
+ - value type: "memory-regions" node
+ - Specific "memory-regions" nodes that describe the RX/TX buffers expected
+ by the partition.
+ The "compatible" must be the string "arm,ffa-manifest-rx_tx-buffer".
+
+- messaging-method [mandatory]
+ - value type: <u8>
+ - Specifies which messaging methods are supported by the partition, set bit
+ means the feature is supported, clear bit - not supported:
+
+ - Bit[0]: partition can receive direct requests if set
+ - Bit[1]: partition can send direct requests if set
+ - Bit[2]: partition can send and receive indirect messages
+
+- managed-exit
+ - value type: <empty>
+ - Specifies if managed exit is supported.
+
+- has-primary-scheduler
+ - value type: <empty>
+ - Presence of this field indicates that the partition implements the primary
+ scheduler. If so, run-time EL must be EL1.
+
+- run-time-model
+ - value type: <u32>
+ - Run time model that the SPM must enforce for this SP:
+
+ - 0x0: Run to completion
+ - 0x1: Preemptible
+
+- time-slice-mem
+ - value type: <empty>
+ - Presence of this field indicates that the partition doesn't expect the
+ partition manager to time slice long running memory management functions.
+
+- gp-register-num
+ - value type: <u32>
+ - Presence of this field indicates that the partition expects the
+ ffa_init_info structure to be passed in via the specified general purpose
+ register.
+ The field specifies the general purpose register number but not its width.
+ The width is derived from the partition's execution state, as specified in
+ the partition properties. For example, if the number value is 1 then the
+ general-purpose register used will be x1 in AArch64 state and w1 in AArch32
+ state.
+
+- stream-endpoint-ids
+ - value type: <prop-encoded-array>
+ - List of <u32> tuples, identifying the IDs this partition is acting as
+ proxy for.
+
+Memory Regions
+--------------
+
+- compatible [mandatory]
+ - value type: <string>
+ - Must be the string "arm,ffa-manifest-memory-regions".
+
+- description
+ - value type: <string>
+ - Name of the memory region e.g. for debugging purposes.
+
+- pages-count [mandatory]
+ - value type: <u32>
+ - Count of pages of memory region as a multiple of the translation granule
+ size
+
+- attributes [mandatory]
+ - value type: <u32>
+ - Mapping modes: ORed to get required permission
+
+ - 0x1: Read
+ - 0x2: Write
+ - 0x4: Execute
+
+- base-address
+ - value type: <u64>
+ - Base address of the region. The address must be aligned to the translation
+ granule size.
+ The address given may be a Physical Address (PA), Virtual Address (VA), or
+ Intermediate Physical Address (IPA). Refer to the FFA specification for
+ more information on the restrictions around the address type.
+ If the base address is omitted then the partition manager must map a memory
+ region of the specified size into the partition's translation regime and
+ then communicate the region properties (including the base address chosen
+ by the partition manager) to the partition.
+
+Device Regions
+--------------
+
+- compatible [mandatory]
+ - value type: <string>
+ - Must be the string "arm,ffa-manifest-device-regions".
+
+- description
+ - value type: <string>
+ - Name of the device region e.g. for debugging purposes.
+
+- reg [mandatory]
+ - value type: <prop-encoded-array>
+ - A (address, num-pages) pair describing the device, where:
+
+ - address: The physical base address <u64> value of the device MMIO
+ region.
+ - num-pages: The <u32> number of pages of the region. The total size of
+ the region is this value multiplied by the translation granule size.
+
+- attributes [mandatory]
+ - value type: <u32>
+ - Mapping modes: ORed to get required permission
+
+ - 0x1: Read
+ - 0x2: Write
+ - 0x4: Execute
+
+- smmu-id
+ - value type: <u32>
+ - On systems with multiple System Memory Management Units (SMMUs) this
+ identifier is used to inform the partition manager which SMMU the device is
+ upstream of. If the field is omitted then it is assumed that the device is
+ not upstream of any SMMU.
+
+- stream-ids
+ - value type: <prop-encoded-array>
+ - A list of (id, mem-manage) pair, where:
+
+ - id: A unique <u32> value amongst all devices assigned to the partition.
+
+- interrupts [mandatory]
+ - value type: <prop-encoded-array>
+ - A list of (id, attributes) pair describing the device interrupts, where:
+
+ - id: The <u32> interrupt IDs.
+ - attributes: A <u32> value,
+ containing the attributes for each interrupt ID:
+
+ - Interrupt type: SPI, PPI, SGI
+ - Interrupt configuration: Edge triggered, Level triggered
+ - Interrupt security state: Secure, Non-secure
+ - Interrupt priority value
+ - Target execution context/vCPU for each SPI
+
+- exclusive-access
+ - value type: <empty>
+ - Presence of this field implies that this endpoint must be granted exclusive
+ access and ownership of this device's MMIO region.
+
+--------------
+
+*Copyright (c) 2019-2021, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/components/granule-protection-tables-design.rst b/docs/components/granule-protection-tables-design.rst
new file mode 100644
index 0000000..07637dd
--- /dev/null
+++ b/docs/components/granule-protection-tables-design.rst
@@ -0,0 +1,235 @@
+Granule Protection Tables Library
+=================================
+
+This document describes the design of the granule protection tables (GPT)
+library used by Trusted Firmware-A (TF-A). This library provides the APIs needed
+to initialize the GPTs based on a data structure containing information about
+the systems memory layout, configure the system registers to enable granule
+protection checks based on these tables, and transition granules between
+different PAS (physical address spaces) at runtime.
+
+Arm CCA adds two new security states for a total of four: root, realm, secure, and
+non-secure. In addition to new security states, corresponding physical address
+spaces have been added to control memory access for each state. The PAS access
+allowed to each security state can be seen in the table below.
+
+.. list-table:: Security states and PAS access rights
+ :widths: 25 25 25 25 25
+ :header-rows: 1
+
+ * -
+ - Root state
+ - Realm state
+ - Secure state
+ - Non-secure state
+ * - Root PAS
+ - yes
+ - no
+ - no
+ - no
+ * - Realm PAS
+ - yes
+ - yes
+ - no
+ - no
+ * - Secure PAS
+ - yes
+ - no
+ - yes
+ - no
+ * - Non-secure PAS
+ - yes
+ - yes
+ - yes
+ - yes
+
+The GPT can function as either a 1 level or 2 level lookup depending on how a
+PAS region is configured. The first step is the level 0 table, each entry in the
+level 0 table controls access to a relatively large region in memory (block
+descriptor), and the entire region can belong to a single PAS when a one step
+mapping is used, or a level 0 entry can link to a level 1 table where relatively
+small regions (granules) of memory can be assigned to different PAS with a 2
+step mapping. The type of mapping used for each PAS is determined by the user
+when setting up the configuration structure.
+
+Design Concepts and Interfaces
+------------------------------
+
+This section covers some important concepts and data structures used in the GPT
+library.
+
+There are three main parameters that determine how the tables are organized and
+function: the PPS (protected physical space) which is the total amount of
+protected physical address space in the system, PGS (physical granule size)
+which is how large each level 1 granule is, and L0GPTSZ (level 0 GPT size) which
+determines how much physical memory is governed by each level 0 entry. A granule
+is the smallest unit of memory that can be independently assigned to a PAS.
+
+L0GPTSZ is determined by the hardware and is read from the GPCCR_EL3 register.
+PPS and PGS are passed into the APIs at runtime and can be determined in
+whatever way is best for a given platform, either through some algorithm or hard
+coded in the firmware.
+
+GPT setup is split into two parts: table creation and runtime initialization. In
+the table creation step, a data structure containing information about the
+desired PAS regions is passed into the library which validates the mappings,
+creates the tables in memory, and enables granule protection checks. In the
+runtime initialization step, the runtime firmware locates the existing tables in
+memory using the GPT register configuration and saves important data to a
+structure used by the granule transition service which will be covered more
+below.
+
+In the reference implementation for FVP models, you can find an example of PAS
+region definitions in the file ``include/plat/arm/common/arm_pas_def.h``. Table
+creation API calls can be found in ``plat/arm/common/arm_bl2_setup.c`` and
+runtime initialization API calls can be seen in
+``plat/arm/common/arm_bl31_setup.c``.
+
+Defining PAS regions
+~~~~~~~~~~~~~~~~~~~~
+
+A ``pas_region_t`` structure is a way to represent a physical address space and
+its attributes that can be used by the GPT library to initialize the tables.
+
+This structure is composed of the following:
+
+#. The base physical address
+#. The region size
+#. The desired attributes of this memory region (mapping type, PAS type)
+
+See the ``pas_region_t`` type in ``include/lib/gpt_rme/gpt_rme.h``.
+
+The programmer should provide the API with an array containing ``pas_region_t``
+structures, then the library will check the desired memory access layout for
+validity and create tables to implement it.
+
+``pas_region_t`` is a public type, however it is recommended that the macros
+``GPT_MAP_REGION_BLOCK`` and ``GPT_MAP_REGION_GRANULE`` be used to populate
+these structures instead of doing it manually to reduce the risk of future
+compatibility issues. These macros take the base physical address, region size,
+and PAS type as arguments to generate the pas_region_t structure. As the names
+imply, ``GPT_MAP_REGION_BLOCK`` creates a region using only L0 mapping while
+``GPT_MAP_REGION_GRANULE`` creates a region using L0 and L1 mappings.
+
+Level 0 and Level 1 Tables
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The GPT initialization APIs require memory to be passed in for the tables to be
+constructed, ``gpt_init_l0_tables`` takes a memory address and size for building
+the level 0 tables and ``gpt_init_pas_l1_tables`` takes an address and size for
+building the level 1 tables which are linked from level 0 descriptors. The
+tables should have PAS type ``GPT_GPI_ROOT`` and a typical system might place
+its level 0 table in SRAM and its level 1 table(s) in DRAM.
+
+Granule Transition Service
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Granule Transition Service allows memory mapped with GPT_MAP_REGION_GRANULE
+ownership to be changed using SMC calls. Non-secure granules can be transitioned
+to either realm or secure space, and realm and secure granules can be
+transitioned back to non-secure. This library only allows memory mapped as
+granules to be transitioned, memory mapped as blocks have their GPIs fixed after
+table creation.
+
+Library APIs
+------------
+
+The public APIs and types can be found in ``include/lib/gpt_rme/gpt_rme.h`` and this
+section is intended to provide additional details and clarifications.
+
+To create the GPTs and enable granule protection checks the APIs need to be
+called in the correct order and at the correct time during the system boot
+process.
+
+#. Firmware must enable the MMU.
+#. Firmware must call ``gpt_init_l0_tables`` to initialize the level 0 tables to
+ a default state, that is, initializing all of the L0 descriptors to allow all
+ accesses to all memory. The PPS is provided to this function as an argument.
+#. DDR discovery and initialization by the system, the discovered DDR region(s)
+ are then added to the L1 PAS regions to be initialized in the next step and
+ used by the GTSI at runtime.
+#. Firmware must call ``gpt_init_pas_l1_tables`` with a pointer to an array of
+ ``pas_region_t`` structures containing the desired memory access layout. The
+ PGS is provided to this function as an argument.
+#. Firmware must call ``gpt_enable`` to enable granule protection checks by
+ setting the correct register values.
+#. In systems that make use of the granule transition service, runtime
+ firmware must call ``gpt_runtime_init`` to set up the data structures needed
+ by the GTSI to find the tables and transition granules between PAS types.
+
+API Constraints
+~~~~~~~~~~~~~~~
+
+The values allowed by the API for PPS and PGS are enumerated types
+defined in the file ``include/lib/gpt_rme/gpt_rme.h``.
+
+Allowable values for PPS along with their corresponding size.
+
+* ``GPCCR_PPS_4GB`` (4GB protected space, 0x100000000 bytes)
+* ``GPCCR_PPS_64GB`` (64GB protected space, 0x1000000000 bytes)
+* ``GPCCR_PPS_1TB`` (1TB protected space, 0x10000000000 bytes)
+* ``GPCCR_PPS_4TB`` (4TB protected space, 0x40000000000 bytes)
+* ``GPCCR_PPS_16TB`` (16TB protected space, 0x100000000000 bytes)
+* ``GPCCR_PPS_256TB`` (256TB protected space, 0x1000000000000 bytes)
+* ``GPCCR_PPS_4PB`` (4PB protected space, 0x10000000000000 bytes)
+
+Allowable values for PGS along with their corresponding size.
+
+* ``GPCCR_PGS_4K`` (4KB granules, 0x1000 bytes)
+* ``GPCCR_PGS_16K`` (16KB granules, 0x4000 bytes)
+* ``GPCCR_PGS_64K`` (64KB granules, 0x10000 bytes)
+
+Allowable values for L0GPTSZ along with the corresponding size.
+
+* ``GPCCR_L0GPTSZ_30BITS`` (1GB regions, 0x40000000 bytes)
+* ``GPCCR_L0GPTSZ_34BITS`` (16GB regions, 0x400000000 bytes)
+* ``GPCCR_L0GPTSZ_36BITS`` (64GB regions, 0x1000000000 bytes)
+* ``GPCCR_L0GPTSZ_39BITS`` (512GB regions, 0x8000000000 bytes)
+
+Note that the value of the PPS, PGS, and L0GPTSZ definitions is an encoded value
+corresponding to the size, not the size itself. The decoded hex representations
+of the sizes have been provided for convenience.
+
+The L0 table memory has some constraints that must be taken into account.
+
+* The L0 table must be aligned to either the table size or 4096 bytes, whichever
+ is greater. L0 table size is the total protected space (PPS) divided by the
+ size of each L0 region (L0GPTSZ) multiplied by the size of each L0 descriptor
+ (8 bytes). ((PPS / L0GPTSZ) * 8)
+* The L0 memory size must be greater than or equal to the table size.
+* The L0 memory must fall within a PAS of type GPT_GPI_ROOT.
+
+The L1 memory also has some constraints.
+
+* The L1 tables must be aligned to their size. The size of each L1 table is the
+ size of each L0 region (L0GPTSZ) divided by the granule size (PGS) divided by
+ the granules controlled in each byte (2). ((L0GPTSZ / PGS) / 2)
+* There must be enough L1 memory supplied to build all requested L1 tables.
+* The L1 memory must fall within a PAS of type GPT_GPI_ROOT.
+
+If an invalid combination of parameters is supplied, the APIs will print an
+error message and return a negative value. The return values of APIs should be
+checked to ensure successful configuration.
+
+Sample Calculation for L0 memory size and alignment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Let PPS=GPCCR_PPS_4GB and L0GPTSZ=GPCCR_L0GPTSZ_30BITS
+
+We can find the total L0 table size with ((PPS / L0GPTSZ) * 8)
+
+Substitute values to get this: ((0x100000000 / 0x40000000) * 8)
+
+And solve to get 32 bytes. In this case, 4096 is greater than 32, so the L0
+tables must be aligned to 4096 bytes.
+
+Sample calculation for L1 table size and alignment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Let PGS=GPCCR_PGS_4K and L0GPTSZ=GPCCR_L0GPTSZ_30BITS
+
+We can find the size of each L1 table with ((L0GPTSZ / PGS) / 2).
+
+Substitute values: ((0x40000000 / 0x1000) / 2)
+
+And solve to get 0x20000 bytes per L1 table.
diff --git a/docs/components/index.rst b/docs/components/index.rst
index ffeef80..95fe42c 100644
--- a/docs/components/index.rst
+++ b/docs/components/index.rst
@@ -7,18 +7,22 @@
:numbered:
spd/index
+ activity-monitors
arm-sip-service
debugfs-design
exception-handling
fconf/index
firmware-update
measured_boot/index
+ mpmm
platform-interrupt-controller-API
ras
romlib-design
sdei
secure-partition-manager
secure-partition-manager-mm
- psa-ffa-manifest-binding
+ ffa-manifest-binding
xlat-tables-lib-v2-design
cot-binding
+ realm-management-extension
+ granule-protection-tables-design
diff --git a/docs/components/measured_boot/event_log.rst b/docs/components/measured_boot/event_log.rst
index 5347dcc..0881248 100644
--- a/docs/components/measured_boot/event_log.rst
+++ b/docs/components/measured_boot/event_log.rst
@@ -9,7 +9,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Measured Boot driver expects a *tpm_event_log* node with the following field
-in 'nt_fw_config' and 'tsp_fw_config' DTS files:
+in 'tb_fw_config', 'nt_fw_config' and 'tsp_fw_config' DTS files:
- compatible [mandatory]
- value type: <string>
diff --git a/docs/components/mpmm.rst b/docs/components/mpmm.rst
new file mode 100644
index 0000000..1b1c6d8
--- /dev/null
+++ b/docs/components/mpmm.rst
@@ -0,0 +1,30 @@
+Maximum Power Mitigation Mechanism (MPMM)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+|MPMM| is an optional microarchitectural power management mechanism supported by
+some Arm Armv9-A cores, beginning with the Cortex-X2, Cortex-A710 and
+Cortex-A510 cores. This mechanism detects and limits high-activity events to
+assist in |SoC| processor power domain dynamic power budgeting and limit the
+triggering of whole-rail (i.e. clock chopping) responses to overcurrent
+conditions.
+
+|MPMM| is enabled on a per-core basis by the EL3 runtime firmware. The presence
+of |MPMM| cannot be determined at runtime by the firmware, and therefore the
+platform must expose this information through one of two possible mechanisms:
+
+- |FCONF|, controlled by the ``ENABLE_MPMM_FCONF`` build option.
+- A platform implementation of the ``plat_mpmm_topology`` function (the
+ default).
+
+See :ref:`Maximum Power Mitigation Mechanism (MPMM) Bindings` for documentation
+on the |FCONF| device tree bindings.
+
+.. warning::
+
+ |MPMM| exposes gear metrics through the auxiliary |AMU| counters. An
+ external power controller can use these metrics to budget SoC power by
+ limiting the number of cores that can execute higher-activity workloads or
+ switching to a different DVFS operating point. When this is the case, the
+ |AMU| counters that make up the |MPMM| gears must be enabled by the EL3
+ runtime firmware - please see :ref:`Activity Monitor Auxiliary Counters` for
+ documentation on enabling auxiliary |AMU| counters.
diff --git a/docs/components/psa-ffa-manifest-binding.rst b/docs/components/psa-ffa-manifest-binding.rst
deleted file mode 100644
index 09894ae..0000000
--- a/docs/components/psa-ffa-manifest-binding.rst
+++ /dev/null
@@ -1,247 +0,0 @@
-PSA FF-A manifest binding to device tree
-========================================
-
-This document defines the nodes and properties used to define a partition,
-according to the PSA FF-A specification.
-
-Version 1.0
------------
-
-Partition Properties
-^^^^^^^^^^^^^^^^^^^^
-
-- compatible [mandatory]
- - value type: <string>
- - Must be the string "arm,ffa-manifest-X.Y" which specifies the major and
- minor versions fo the device tree binding for the FFA manifest represented
- by this node. The minor number is incremented if the binding changes in a
- backwards compatible manner.
-
- - X is an integer representing the major version number of this document.
- - Y is an integer representing the minor version number of this document.
-
-- ffa-version [mandatory]
- - value type: <u32>
- - Must be two 16 bits values (X, Y), concatenated as 31:16 -> X,
- 15:0 -> Y, where:
-
- - X is the major version of PSA-FF-A expected by the partition at the FFA
- instance it will execute.
- - Y is the minor version of PSA-FF-A expected by the partition at the FFA
- instance it will execute.
-
-- uuid [mandatory]
- - value type: <prop-encoded-array>
- - An array consisting of 4 <u32> values, identifying the UUID of the service
- implemented by this partition. The UUID format is described in RFC 4122.
-
-- id
- - value type: <u32>
- - Pre-allocated partition ID.
-
-- auxiliary-id
- - value type: <u32>
- - Pre-allocated ID that could be used in memory management transactions.
-
-- description
- - value type: <string>
- - Name of the partition e.g. for debugging purposes.
-
-- execution-ctx-count [mandatory]
- - value type: <u32>
- - Number of vCPUs that a VM or SP wants to instantiate.
-
- - In the absence of virtualization, this is the number of execution
- contexts that a partition implements.
- - If value of this field = 1 and number of PEs > 1 then the partition is
- treated as UP & migrate capable.
- - If the value of this field > 1 then the partition is treated as a MP
- capable partition irrespective of the number of PEs.
-
-- exception-level [mandatory]
- - value type: <u32>
- - The target exception level for the partition:
-
- - 0x0: EL1
- - 0x1: S_EL0
- - 0x2: S_EL1
-
-- execution-state [mandatory]
- - value type: <u32>
- - The target execution state of the partition:
-
- - 0: AArch64
- - 1: AArch32
-
-- load-address
- - value type: <u64>
- - Physical base address of the partition in memory. Absence of this field
- indicates that the partition is position independent and can be loaded at
- any address chosen at boot time.
-
-- entrypoint-offset
- - value type: <u64>
- - Offset from the base of the partition's binary image to the entry point of
- the partition. Absence of this field indicates that the entry point is at
- offset 0x0 from the base of the partition's binary.
-
-- xlat-granule [mandatory]
- - value type: <u32>
- - Translation granule used with the partition:
-
- - 0x0: 4k
- - 0x1: 16k
- - 0x2: 64k
-
-- boot-order
- - value type: <u32>
- - A unique number amongst all partitions that specifies if this partition
- must be booted before others. The partition with the smaller number will be
- booted first.
-
-- rx-tx-buffer
- - value type: "memory-regions" node
- - Specific "memory-regions" nodes that describe the RX/TX buffers expected
- by the partition.
- The "compatible" must be the string "arm,ffa-manifest-rx_tx-buffer".
-
-- messaging-method [mandatory]
- - value type: <u32>
- - Specifies which messaging methods are supported by the partition:
-
- - 0x0: direct messaging method
- - 0x1: indirect messaging method
- - 0x2: both direct and indirect messaging methods
-
-- has-primary-scheduler
- - value type: <empty>
- - Presence of this field indicates that the partition implements the primary
- scheduler. If so, run-time EL must be EL1.
-
-- run-time-model
- - value type: <u32>
- - Run time model that the SPM must enforce for this SP:
-
- - 0x0: Run to completion
- - 0x1: Preemptible
-
-- time-slice-mem
- - value type: <empty>
- - Presence of this field indicates that the partition doesn't expect the
- partition manager to time slice long running memory management functions.
-
-- gp-register-num
- - value type: <u32>
- - Presence of this field indicates that the partition expects the
- ffa_init_info structure to be passed in via the specified general purpose
- register.
- The field specifies the general purpose register number but not its width.
- The width is derived from the partition's execution state, as specified in
- the partition properties. For example, if the number value is 1 then the
- general-purpose register used will be x1 in AArch64 state and w1 in AArch32
- state.
-
-- stream-endpoint-ids
- - value type: <prop-encoded-array>
- - List of <u32> tuples, identifying the IDs this partition is acting as
- proxy for.
-
-Memory Regions
---------------
-
-- compatible [mandatory]
- - value type: <string>
- - Must be the string "arm,ffa-manifest-memory-regions".
-
-- description
- - value type: <string>
- - Name of the memory region e.g. for debugging purposes.
-
-- pages-count [mandatory]
- - value type: <u32>
- - Count of pages of memory region as a multiple of the translation granule
- size
-
-- attributes [mandatory]
- - value type: <u32>
- - Mapping modes: ORed to get required permission
-
- - 0x1: Read
- - 0x2: Write
- - 0x4: Execute
-
-- base-address
- - value type: <u64>
- - Base address of the region. The address must be aligned to the translation
- granule size.
- The address given may be a Physical Address (PA), Virtual Address (VA), or
- Intermediate Physical Address (IPA). Refer to the FFA specification for
- more information on the restrictions around the address type.
- If the base address is omitted then the partition manager must map a memory
- region of the specified size into the partition's translation regime and
- then communicate the region properties (including the base address chosen
- by the partition manager) to the partition.
-
-Device Regions
---------------
-
-- compatible [mandatory]
- - value type: <string>
- - Must be the string "arm,ffa-manifest-device-regions".
-
-- description
- - value type: <string>
- - Name of the device region e.g. for debugging purposes.
-
-- reg [mandatory]
- - value type: <prop-encoded-array>
- - A (address, num-pages) pair describing the device, where:
-
- - address: The physical base address <u64> value of the device MMIO
- region.
- - num-pages: The <u32> number of pages of the region. The total size of
- the region is this value multiplied by the translation granule size.
-
-- attributes [mandatory]
- - value type: <u32>
- - Mapping modes: ORed to get required permission
-
- - 0x1: Read
- - 0x2: Write
- - 0x4: Execute
-
-- smmu-id
- - value type: <u32>
- - On systems with multiple System Memory Management Units (SMMUs) this
- identifier is used to inform the partition manager which SMMU the device is
- upstream of. If the field is omitted then it is assumed that the device is
- not upstream of any SMMU.
-
-- stream-ids
- - value type: <prop-encoded-array>
- - A list of (id, mem-manage) pair, where:
-
- - id: A unique <u32> value amongst all devices assigned to the partition.
-
-- interrupts [mandatory]
- - value type: <prop-encoded-array>
- - A list of (id, attributes) pair describing the device interrupts, where:
-
- - id: The <u32> interrupt IDs.
- - attributes: A <u32> value,
- containing the attributes for each interrupt ID:
-
- - Interrupt type: SPI, PPI, SGI
- - Interrupt configuration: Edge triggered, Level triggered
- - Interrupt security state: Secure, Non-secure
- - Interrupt priority value
- - Target execution context/vCPU for each SPI
-
-- exclusive-access
- - value type: <empty>
- - Presence of this field implies that this endpoint must be granted exclusive
- access and ownership of this devices's MMIO region.
-
---------------
-
-*Copyright (c) 2019-2020, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/components/realm-management-extension.rst b/docs/components/realm-management-extension.rst
new file mode 100644
index 0000000..2c4e0b8
--- /dev/null
+++ b/docs/components/realm-management-extension.rst
@@ -0,0 +1,263 @@
+
+Realm Management Extension (RME)
+====================================
+
+FEAT_RME (or RME for short) is an Armv9-A extension and is one component of the
+`Arm Confidential Compute Architecture (Arm CCA)`_. TF-A supports RME starting
+from version 2.6. This chapter discusses the changes to TF-A to support RME and
+provides instructions on how to build and run TF-A with RME.
+
+RME support in TF-A
+---------------------
+
+The following diagram shows an Arm CCA software architecture with TF-A as the
+EL3 firmware. In the Arm CCA architecture there are two additional security
+states and address spaces: ``Root`` and ``Realm``. TF-A firmware runs in the
+Root world. In the realm world, a Realm Management Monitor firmware (RMM)
+manages the execution of Realm VMs and their interaction with the hypervisor.
+
+.. image:: ../resources/diagrams/arm-cca-software-arch.png
+
+RME is the hardware extension to support Arm CCA. To support RME, various
+changes have been introduced to TF-A. We discuss those changes below.
+
+Changes to translation tables library
+***************************************
+RME adds Root and Realm Physical address spaces. To support this, two new
+memory type macros, ``MT_ROOT`` and ``MT_REALM``, have been added to the
+:ref:`Translation (XLAT) Tables Library`. These macros are used to configure
+memory regions as Root or Realm respectively.
+
+.. note::
+
+ Only version 2 of the translation tables library supports the new memory
+ types.
+
+Changes to context management
+*******************************
+A new CPU context for the Realm world has been added. The existing
+:ref:`CPU context management API<PSCI Library Integration guide for Armv8-A
+AArch32 systems>` can be used to manage Realm context.
+
+Boot flow changes
+*******************
+In a typical TF-A boot flow, BL2 runs at Secure-EL1. However when RME is
+enabled, TF-A runs in the Root world at EL3. Therefore, the boot flow is
+modified to run BL2 at EL3 when RME is enabled. In addition to this, a
+Realm-world firmware (RMM) is loaded by BL2 in the Realm physical address
+space.
+
+The boot flow when RME is enabled looks like the following:
+
+1. BL1 loads and executes BL2 at EL3
+2. BL2 loads images including RMM
+3. BL2 transfers control to BL31
+4. BL31 initializes SPM (if SPM is enabled)
+5. BL31 initializes RMM
+6. BL31 transfers control to Normal-world software
+
+Granule Protection Tables (GPT) library
+*****************************************
+Isolation between the four physical address spaces is enforced by a process
+called Granule Protection Check (GPC) performed by the MMU downstream any
+address translation. GPC makes use of Granule Protection Table (GPT) in the
+Root world that describes the physical address space assignment of every
+page (granule). A GPT library that provides APIs to initialize GPTs and to
+transition granules between different physical address spaces has been added.
+More information about the GPT library can be found in the
+:ref:`Granule Protection Tables Library` chapter.
+
+RMM Dispatcher (RMMD)
+************************
+RMMD is a new standard runtime service that handles the switch to the Realm
+world. It initializes the RMM and handles Realm Management Interface (RMI)
+SMC calls from Non-secure and Realm worlds.
+
+Test Realm Payload (TRP)
+*************************
+TRP is a small test payload that runs at R-EL2 and implements a subset of
+the Realm Management Interface (RMI) commands to primarily test EL3 firmware
+and the interface between R-EL2 and EL3. When building TF-A with RME enabled,
+if a path to an RMM image is not provided, TF-A builds the TRP by default
+and uses it as RMM image.
+
+Building and running TF-A with RME
+------------------------------------
+
+This section describes how you can build and run TF-A with RME enabled.
+We assume you have all the :ref:`Prerequisites` to build TF-A.
+
+To enable RME, you need to set the ENABLE_RME build flag when building
+TF-A. Currently, this feature is only supported for the FVP platform.
+
+The following instructions show you how to build and run TF-A with RME
+for two scenarios: TF-A with TF-A Tests, and four-world execution with
+Hafnium and TF-A Tests. The instructions assume you have already obtained
+TF-A. You can use the following command to clone TF-A.
+
+.. code:: shell
+
+ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
+
+To run the tests, you need an FVP model. Please use the :ref:`latest version
+<Arm Fixed Virtual Platforms (FVP)>` of *FVP_Base_RevC-2xAEMvA* model.
+
+.. note::
+
+ ENABLE_RME build option is currently experimental.
+
+Building TF-A with TF-A Tests
+********************************************
+Use the following instructions to build TF-A with `TF-A Tests`_ as the
+non-secure payload (BL33).
+
+**1. Obtain and build TF-A Tests**
+
+.. code:: shell
+
+ git clone https://git.trustedfirmware.org/TF-A/tf-a-tests.git
+ cd tf-a-tests
+ make CROSS_COMPILE=aarch64-none-elf- PLAT=fvp DEBUG=1
+
+This produces a TF-A Tests binary (*tftf.bin*) in the *build/fvp/debug* directory.
+
+**2. Build TF-A**
+
+.. code:: shell
+
+ cd trusted-firmware-a
+ make CROSS_COMPILE=aarch64-none-elf- \
+ PLAT=fvp \
+ ENABLE_RME=1 \
+ FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts \
+ DEBUG=1 \
+ BL33=<path/to/tftf.bin> \
+ all fip
+
+This produces *bl1.bin* and *fip.bin* binaries in the *build/fvp/debug* directory.
+The above command also builds TRP. The TRP binary is packaged in *fip.bin*.
+
+Four-world execution with Hafnium and TF-A Tests
+****************************************************
+Four-world execution involves software components at each security state: root,
+secure, realm and non-secure. This section describes how to build TF-A
+with four-world support. We use TF-A as the root firmware, `Hafnium`_ as the
+secure component, TRP as the realm-world firmware and TF-A Tests as the
+non-secure payload.
+
+Before building TF-A, you first need to build the other software components.
+You can find instructions on how to get and build TF-A Tests above.
+
+**1. Obtain and build Hafnium**
+
+.. code:: shell
+
+ git clone --recurse-submodules https://git.trustedfirmware.org/hafnium/hafnium.git
+ cd hafnium
+ make PROJECT=reference
+
+The Hafnium binary should be located at
+*out/reference/secure_aem_v8a_fvp_clang/hafnium.bin*
+
+**2. Build TF-A**
+
+Build TF-A with RME as well as SPM enabled.
+
+.. code:: shell
+
+ make CROSS_COMPILE=aarch64-none-elf- \
+ PLAT=fvp \
+ ENABLE_RME=1 \
+ FVP_HW_CONFIG_DTS=fdts/fvp-base-gicv3-psci-1t.dts \
+ SPD=spmd \
+ SPMD_SPM_AT_SEL2=1 \
+ BRANCH_PROTECTION=1 \
+ CTX_INCLUDE_PAUTH_REGS=1 \
+ DEBUG=1 \
+ SP_LAYOUT_FILE=<path/to/tf-a-tests>/build/fvp/debug/sp_layout.json> \
+ BL32=<path/to/hafnium.bin> \
+ BL33=<path/to/tftf.bin> \
+ all fip
+
+Running the tests
+*********************
+Use the following command to run the tests on FVP. TF-A Tests should boot
+and run the default tests including RME tests.
+
+.. code:: shell
+
+ FVP_Base_RevC-2xAEMvA \
+ -C bp.flashloader0.fname=<path/to/fip.bin> \
+ -C bp.secureflashloader.fname=<path/to/bl1.bin> \
+ -C bp.refcounter.non_arch_start_at_default=1 \
+ -C bp.refcounter.use_real_time=0 \
+ -C bp.ve_sysregs.exit_on_shutdown=1 \
+ -C cache_state_modelled=1 \
+ -C cluster0.NUM_CORES=4 \
+ -C cluster0.PA_SIZE=48 \
+ -C cluster0.ecv_support_level=2 \
+ -C cluster0.gicv3.cpuintf-mmap-access-level=2 \
+ -C cluster0.gicv3.without-DS-support=1 \
+ -C cluster0.gicv4.mask-virtual-interrupt=1 \
+ -C cluster0.has_arm_v8-6=1 \
+ -C cluster0.has_branch_target_exception=1 \
+ -C cluster0.has_rme=1 \
+ -C cluster0.has_rndr=1 \
+ -C cluster0.has_amu=1 \
+ -C cluster0.has_v8_7_pmu_extension=2 \
+ -C cluster0.max_32bit_el=-1 \
+ -C cluster0.restriction_on_speculative_execution=2 \
+ -C cluster0.restriction_on_speculative_execution_aarch32=2 \
+ -C cluster1.NUM_CORES=4 \
+ -C cluster1.PA_SIZE=48 \
+ -C cluster1.ecv_support_level=2 \
+ -C cluster1.gicv3.cpuintf-mmap-access-level=2 \
+ -C cluster1.gicv3.without-DS-support=1 \
+ -C cluster1.gicv4.mask-virtual-interrupt=1 \
+ -C cluster1.has_arm_v8-6=1 \
+ -C cluster1.has_branch_target_exception=1 \
+ -C cluster1.has_rme=1 \
+ -C cluster1.has_rndr=1 \
+ -C cluster1.has_amu=1 \
+ -C cluster1.has_v8_7_pmu_extension=2 \
+ -C cluster1.max_32bit_el=-1 \
+ -C cluster1.restriction_on_speculative_execution=2 \
+ -C cluster1.restriction_on_speculative_execution_aarch32=2 \
+ -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 \
+ -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B \
+ -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 \
+ -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 \
+ -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0475 \
+ -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 \
+ -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 \
+ -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 \
+ -C bp.pl011_uart0.out_file=uart0.log \
+ -C bp.pl011_uart1.out_file=uart1.log \
+ -C bp.pl011_uart2.out_file=uart2.log \
+ -C pctl.startup=0.0.0.0 \
+ -Q 1000 \
+ "$@"
+
+The bottom of the output from *uart0* should look something like the following.
+
+.. code-block:: shell
+
+ ...
+
+ > Test suite 'FF-A Interrupt'
+ Passed
+ > Test suite 'SMMUv3 tests'
+ Passed
+ > Test suite 'PMU Leakage'
+ Passed
+ > Test suite 'DebugFS'
+ Passed
+ > Test suite 'Realm payload tests'
+ Passed
+ ...
+
+
+.. _Arm Confidential Compute Architecture (Arm CCA): https://www.arm.com/why-arm/architecture/security-features/arm-confidential-compute-architecture
+.. _Arm Architecture Models website: https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms/arm-ecosystem-models
+.. _TF-A Tests: https://trustedfirmware-a-tests.readthedocs.io/en/latest
+.. _Hafnium: https://www.trustedfirmware.org/projects/hafnium
diff --git a/docs/components/secure-partition-manager-mm.rst b/docs/components/secure-partition-manager-mm.rst
index d532901..4cdb96c 100644
--- a/docs/components/secure-partition-manager-mm.rst
+++ b/docs/components/secure-partition-manager-mm.rst
@@ -6,7 +6,7 @@
Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
-- SPM based on the PSA FF-A specification (:ref:`Secure Partition Manager`).
+- SPM based on the FF-A specification (:ref:`Secure Partition Manager`).
- SPM based on the MM interface.
Both implementations differ in their architectures and only one can be selected
@@ -134,8 +134,8 @@
the rest of this document.
To enable SPM support in TF-A, the source code must be compiled with the build
-flag ``SPM_MM=1``, along with ``EL3_EXCEPTION_HANDLING=1``. On Arm
-platforms the build option ``ARM_BL31_IN_DRAM`` must be set to 1. Also, the
+flag ``SPM_MM=1``, along with ``EL3_EXCEPTION_HANDLING=1`` and ``ENABLE_SVE_FOR_NS=0``.
+On Arm platforms the build option ``ARM_BL31_IN_DRAM`` must be set to 1. Also, the
location of the binary that contains the BL32 image
(``BL32=path/to/image.bin``) must be specified.
@@ -148,7 +148,7 @@
.. code:: shell
BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \
- make PLAT=fvp SPM_MM=1 EL3_EXCEPTION_HANDLING=1 ARM_BL31_IN_DRAM=1 all fip
+ make PLAT=fvp SPM_MM=1 EL3_EXCEPTION_HANDLING=1 ENABLE_SVE_FOR_NS=0 ARM_BL31_IN_DRAM=1 all fip
Describing Secure Partition resources
-------------------------------------
@@ -822,7 +822,7 @@
--------------
-*Copyright (c) 2017-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2021, Arm Limited and Contributors. All rights reserved.*
.. _Armv8-A ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
.. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD
diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst
index 9a65e64..0572261 100644
--- a/docs/components/secure-partition-manager.rst
+++ b/docs/components/secure-partition-manager.rst
@@ -6,162 +6,176 @@
Acronyms
========
-+--------+-----------------------------------+
-| DTB | Device Tree Blob |
-+--------+-----------------------------------+
-| DTS | Device Tree Source |
-+--------+-----------------------------------+
-| EC | Execution Context |
-+--------+-----------------------------------+
-| FIP | Firmware Image Package |
-+--------+-----------------------------------+
-| FF-A | Firmware Framework for A-class |
-+--------+-----------------------------------+
-| IPA | Intermediate Physical Address |
-+--------+-----------------------------------+
-| NWd | Normal World |
-+--------+-----------------------------------+
-| ODM | Original Design Manufacturer |
-+--------+-----------------------------------+
-| OEM | Original Equipment Manufacturer |
-+--------+-----------------------------------+
-| PA | Physical Address |
-+--------+-----------------------------------+
-| PE | Processing Element |
-+--------+-----------------------------------+
-| PVM | Primary VM |
-+--------+-----------------------------------+
-| PSA | Platform Security Architecture |
-+--------+-----------------------------------+
-| SP | Secure Partition |
-+--------+-----------------------------------+
-| SPM | Secure Partition Manager |
-+--------+-----------------------------------+
-| SPMC | SPM Core |
-+--------+-----------------------------------+
-| SPMD | SPM Dispatcher |
-+--------+-----------------------------------+
-| SiP | Silicon Provider |
-+--------+-----------------------------------+
-| SWd | Secure World |
-+--------+-----------------------------------+
-| TLV | Tag-Length-Value |
-+--------+-----------------------------------+
-| TOS | Trusted Operating System |
-+--------+-----------------------------------+
-| VM | Virtual Machine |
-+--------+-----------------------------------+
++--------+--------------------------------------+
+| CoT | Chain of Trust |
++--------+--------------------------------------+
+| DMA | Direct Memory Access |
++--------+--------------------------------------+
+| DTB | Device Tree Blob |
++--------+--------------------------------------+
+| DTS | Device Tree Source |
++--------+--------------------------------------+
+| EC | Execution Context |
++--------+--------------------------------------+
+| FIP | Firmware Image Package |
++--------+--------------------------------------+
+| FF-A | Firmware Framework for Arm A-profile |
++--------+--------------------------------------+
+| IPA | Intermediate Physical Address |
++--------+--------------------------------------+
+| NWd | Normal World |
++--------+--------------------------------------+
+| ODM | Original Design Manufacturer |
++--------+--------------------------------------+
+| OEM | Original Equipment Manufacturer |
++--------+--------------------------------------+
+| PA | Physical Address |
++--------+--------------------------------------+
+| PE | Processing Element |
++--------+--------------------------------------+
+| PM | Power Management |
++--------+--------------------------------------+
+| PVM | Primary VM |
++--------+--------------------------------------+
+| SMMU | System Memory Management Unit |
++--------+--------------------------------------+
+| SP | Secure Partition |
++--------+--------------------------------------+
+| SPD | Secure Payload Dispatcher |
++--------+--------------------------------------+
+| SPM | Secure Partition Manager |
++--------+--------------------------------------+
+| SPMC | SPM Core |
++--------+--------------------------------------+
+| SPMD | SPM Dispatcher |
++--------+--------------------------------------+
+| SiP | Silicon Provider |
++--------+--------------------------------------+
+| SWd | Secure World |
++--------+--------------------------------------+
+| TLV | Tag-Length-Value |
++--------+--------------------------------------+
+| TOS | Trusted Operating System |
++--------+--------------------------------------+
+| VM | Virtual Machine |
++--------+--------------------------------------+
Foreword
========
Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
-- SPM based on the PSA FF-A specification `[1]`_.
-- SPM based on the MM interface to communicate with an S-EL0 partition `[2]`_.
+- SPM based on the FF-A specification `[1]`_.
+- SPM based on the MM interface to communicate with an S-EL0 partition `[2]`_.
Both implementations differ in their architectures and only one can be selected
at build time.
This document:
-- describes the PSA FF-A implementation where the Secure Partition Manager
- resides at EL3 and S-EL2 (or EL3 and S-EL1).
-- is not an architecture specification and it might provide assumptions
- on sections mandated as implementation-defined in the specification.
-- covers the implications to TF-A used as a bootloader, and Hafnium
- used as a reference code base for an S-EL2 secure firmware on
- platforms implementing Armv8.4-SecEL2.
+- describes the FF-A implementation where the Secure Partition Manager
+ resides at EL3 and S-EL2 (or EL3 and S-EL1).
+- is not an architecture specification and it might provide assumptions
+ on sections mandated as implementation-defined in the specification.
+- covers the implications to TF-A used as a bootloader, and Hafnium
+ used as a reference code base for an S-EL2 secure firmware on
+ platforms implementing the FEAT_SEL2 (formerly Armv8.4 Secure EL2)
+ architecture extension.
Terminology
-----------
-- Hypervisor refers to the NS-EL2 component managing Virtual Machines (or
- partitions) in the Normal World.
-- SPMC refers to the S-EL2 component managing Virtual Machines (or Secure
- Partitions) in the Secure World when Armv8.4-SecEL2 extension is implemented.
-- Alternatively, SPMC can refer to an S-EL1 component, itself being a Secure
- Partition and implementing the FF-A ABI on pre-Armv8.4 platforms.
-- VM refers to a Normal World Virtual Machine managed by an Hypervisor.
-- SP refers to a Secure World "Virtual Machine" managed by the SPMC component.
+- The term Hypervisor refers to the NS-EL2 component managing Virtual Machines
+ (or partitions) in the normal world.
+- The term SPMC refers to the S-EL2 component managing secure partitions in
+ the secure world when the FEAT_SEL2 architecture extension is implemented.
+- Alternatively, SPMC can refer to an S-EL1 component, itself being a secure
+ partition and implementing the FF-A ABI on platforms not implementing the
+ FEAT_SEL2 architecture extension.
+- The term VM refers to a normal world Virtual Machine managed by an Hypervisor.
+- The term SP refers to a secure world "Virtual Machine" managed by an SPMC.
Support for legacy platforms
----------------------------
-In the implementation, the SPM is split into SPMD and SPMC components
-(although not strictly mandated by the specification). SPMD is located
-at EL3 and principally relays FF-A messages from NWd (Hypervisor or OS
-kernel) to SPMC located either at S-EL1 or S-EL2.
+In the implementation, the SPM is split into SPMD and SPMC components.
+The SPMD is located at EL3 and mainly relays FF-A messages from
+NWd (Hypervisor or OS kernel) to SPMC located either at S-EL1 or S-EL2.
-Hence TF-A must support both cases where SPMC is either located at:
+Hence TF-A supports both cases where the SPMC is located either at:
-- S-EL1 supporting pre-Armv8.4 platforms. SPMD conveys FF-A protocol
- from EL3 to S-EL1.
-- S-EL2 supporting platforms implementing Armv8.4-SecEL2 extension.
- SPMD conveys FF-A protocol from EL3 to S-EL2.
+- S-EL1 supporting platforms not implementing the FEAT_SEL2 architecture
+ extension. The SPMD relays the FF-A protocol from EL3 to S-EL1.
+- or S-EL2 supporting platforms implementing the FEAT_SEL2 architecture
+ extension. The SPMD relays the FF-A protocol from EL3 to S-EL2.
-The same SPMD component is used to support both configurations. The SPMC
-execution level is a build time choice.
+The same TF-A SPMD component is used to support both configurations.
+The SPMC exception level is a build time choice.
Sample reference stack
======================
-The following diagram illustrates a possible configuration with SPMD and SPMC,
-one or multiple Secure Partitions, with or without an optional Hypervisor:
+The following diagram illustrates a possible configuration when the
+FEAT_SEL2 architecture extension is implemented, showing the SPMD
+and SPMC, one or multiple secure partitions, with an optional
+Hypervisor:
.. image:: ../resources/diagrams/ff-a-spm-sel2.png
TF-A build options
==================
-The following TF-A build options are provisioned:
+This section explains the TF-A build options involved in building with
+support for an FF-A based SPM where the SPMD is located at EL3 and the
+SPMC located at S-EL1 or S-EL2:
-- **SPD=spmd**: this option selects the SPMD component to relay FF-A
- protocol from NWd to SWd back and forth. It is not possible to
- enable another Secure Payload Dispatcher when this option is chosen.
-- **SPMD_SPM_AT_SEL2**: this option adjusts the SPMC execution
- level to being S-EL1 or S-EL2. It defaults to enabled (value 1) when
- SPD=spmd is chosen.
-- **CTX_INCLUDE_EL2_REGS**: this option permits saving (resp.
- restoring) the EL2 system register context before entering (resp.
- after leaving) the SPMC. It is mandatory when ``SPMD_SPM_AT_SEL2`` is
- enabled. The context save/restore routine and exhaustive list of
- registers is visible at `[4]`_.
-- **SP_LAYOUT_FILE**: this option provides a text description file
- providing paths to SP binary images and DTS format manifests
- (see `Specifying partition binary image and DT`_). It
- is required when ``SPMD_SPM_AT_SEL2`` is enabled hence when multiple
- secure partitions are to be loaded on behalf of SPMC.
+- **SPD=spmd**: this option selects the SPMD component to relay the FF-A
+ protocol from NWd to SWd back and forth. It is not possible to
+ enable another Secure Payload Dispatcher when this option is chosen.
+- **SPMD_SPM_AT_SEL2**: this option adjusts the SPMC exception
+ level to being S-EL1 or S-EL2. It defaults to enabled (value 1) when
+ SPD=spmd is chosen.
+- **CTX_INCLUDE_EL2_REGS**: this option permits saving (resp.
+ restoring) the EL2 system register context before entering (resp.
+ after leaving) the SPMC. It is mandatorily enabled when
+ ``SPMD_SPM_AT_SEL2`` is enabled. The context save/restore routine
+ and exhaustive list of registers is visible at `[4]`_.
+- **SP_LAYOUT_FILE**: this option specifies a text description file
+ providing paths to SP binary images and manifests in DTS format
+ (see `Describing secure partitions`_). It
+ is required when ``SPMD_SPM_AT_SEL2`` is enabled hence when multiple
+ secure partitions are to be loaded on behalf of the SPMC.
-+------------------------------+----------------------+------------------+
-| | CTX_INCLUDE_EL2_REGS | SPMD_SPM_AT_SEL2 |
-+------------------------------+----------------------+------------------+
-| SPMC at S-EL1 (e.g. OP-TEE) | 0 | 0 |
-+------------------------------+----------------------+------------------+
-| SPMC at S-EL2 (e.g. Hafnium) | 1 | 1 (default when |
-| | | SPD=spmd) |
-+------------------------------+----------------------+------------------+
++---------------+----------------------+------------------+
+| | CTX_INCLUDE_EL2_REGS | SPMD_SPM_AT_SEL2 |
++---------------+----------------------+------------------+
+| SPMC at S-EL1 | 0 | 0 |
++---------------+----------------------+------------------+
+| SPMC at S-EL2 | 1 | 1 (default when |
+| | | SPD=spmd) |
++---------------+----------------------+------------------+
Other combinations of such build options either break the build or are not
supported.
-Note, the ``CTX_INCLUDE_EL2_REGS`` option provides the generic support for
-barely saving/restoring EL2 registers from an Arm arch perspective. As such
-it is decoupled from the ``SPD=spmd`` option.
+Notes:
-BL32 option is re-purposed to specify the SPMC image. It can specify either the
-Hafnium binary path (built for the secure world) or the path to a TEE binary
-implementing the FF-A protocol.
-
-BL33 option can specify either:
-
-- the TFTF binary or
-- the Hafnium binary path (built for the normal world) if VMs were loaded by
- TF-A beforehand or
-- a minimal loader performing the loading of VMs and Hafnium.
+- Only Arm's FVP platform is supported to use with the TF-A reference software
+ stack.
+- The reference software stack uses FEAT_PAuth (formerly Armv8.3-PAuth) and
+ FEAT_BTI (formerly Armv8.5-BTI) architecture extensions by default at EL3
+ and S-EL2.
+- The ``CTX_INCLUDE_EL2_REGS`` option provides the generic support for
+ barely saving/restoring EL2 registers from an Arm arch perspective. As such
+ it is decoupled from the ``SPD=spmd`` option.
+- BL32 option is re-purposed to specify the SPMC image. It can specify either
+ the Hafnium binary path (built for the secure world) or the path to a TEE
+ binary implementing FF-A interfaces.
+- BL33 option can specify the TFTF binary or a normal world loader
+ such as U-Boot or the UEFI framework.
Sample TF-A build command line when SPMC is located at S-EL1
-(typically pre-Armv8.4):
+(e.g. when the FEAT_EL2 architecture extension is not implemented):
.. code:: shell
@@ -170,67 +184,108 @@
SPD=spmd \
SPMD_SPM_AT_SEL2=0 \
BL32=<path-to-tee-binary> \
- BL33=<path-to-nwd-binary> \
+ BL33=<path-to-bl33-binary> \
PLAT=fvp \
all fip
-Sample TF-A build command line for an Armv8.4-SecEL2 enabled system
-where SPMC is located at S-EL2:
+Sample TF-A build command line for a FEAT_SEL2 enabled system where the SPMC is
+located at S-EL2:
.. code:: shell
make \
CROSS_COMPILE=aarch64-none-elf- \
+ PLAT=fvp \
SPD=spmd \
CTX_INCLUDE_EL2_REGS=1 \
- ARM_ARCH_MINOR=4 \
- BL32=<path-to-swd-hafnium-binary>
- BL33=<path-to-nwd-binary> \
+ ARM_ARCH_MINOR=5 \
+ BRANCH_PROTECTION=1 \
+ CTX_INCLUDE_PAUTH_REGS=1 \
+ BL32=<path-to-hafnium-binary> \
+ BL33=<path-to-bl33-binary> \
SP_LAYOUT_FILE=sp_layout.json \
- PLAT=fvp \
all fip
-Build options to enable secure boot:
+Same as above with enabling secure boot in addition:
.. code:: shell
make \
CROSS_COMPILE=aarch64-none-elf- \
+ PLAT=fvp \
SPD=spmd \
CTX_INCLUDE_EL2_REGS=1 \
- ARM_ARCH_MINOR=4 \
- BL32=<path-to-swd-hafnium-binary>
- BL33=<path-to-nwd-binary> \
- SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json \
+ ARM_ARCH_MINOR=5 \
+ BRANCH_PROTECTION=1 \
+ CTX_INCLUDE_PAUTH_REGS=1 \
+ BL32=<path-to-hafnium-binary> \
+ BL33=<path-to-bl33-binary> \
+ SP_LAYOUT_FILE=sp_layout.json \
MBEDTLS_DIR=<path-to-mbedtls-lib> \
TRUSTED_BOARD_BOOT=1 \
COT=dualroot \
ARM_ROTPK_LOCATION=devel_rsa \
ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem \
GENERATE_COT=1 \
- PLAT=fvp \
all fip
+FVP model invocation
+====================
+
+The FVP command line needs the following options to exercise the S-EL2 SPMC:
+
++---------------------------------------------------+------------------------------------+
+| - cluster0.has_arm_v8-5=1 | Implements FEAT_SEL2, FEAT_PAuth, |
+| - cluster1.has_arm_v8-5=1 | and FEAT_BTI. |
++---------------------------------------------------+------------------------------------+
+| - pci.pci_smmuv3.mmu.SMMU_AIDR=2 | Parameters required for the |
+| - pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B | SMMUv3.2 modeling. |
+| - pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 | |
+| - pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 | |
+| - pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 | |
+| - pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 | |
+| - pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 | |
+| - pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 | |
++---------------------------------------------------+------------------------------------+
+| - cluster0.has_branch_target_exception=1 | Implements FEAT_BTI. |
+| - cluster1.has_branch_target_exception=1 | |
++---------------------------------------------------+------------------------------------+
+| - cluster0.restriction_on_speculative_execution=2 | Required by the EL2 context |
+| - cluster1.restriction_on_speculative_execution=2 | save/restore routine. |
++---------------------------------------------------+------------------------------------+
+
+Sample FVP command line invocation:
+
+.. code:: shell
+
+ <path-to-fvp-model>/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0
+ -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 \
+ -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin \
+ -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin \
+ -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log \
+ -C bp.pl011_uart2.out_file=fvp-uart2.log \
+ -C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 \
+ -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 \
+ -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 \
+ -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 \
+ -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 \
+ -C cluster0.has_branch_target_exception=1 \
+ -C cluster1.has_branch_target_exception=1 \
+ -C cluster0.restriction_on_speculative_execution=2 \
+ -C cluster1.restriction_on_speculative_execution=2
+
Boot process
============
-Loading Hafnium and Secure Partitions in the secure world
+Loading Hafnium and secure partitions in the secure world
---------------------------------------------------------
-The Hafnium implementation in normal world requires VMs to be loaded in
-memory prior to booting. The mechanism upon which VMs are loaded and
-exposed to Hafnium are either:
+TF-A BL2 is the bootlader for the SPMC and SPs in the secure world.
-- by supplying a ramdisk image where VM images are concatenated (1)
-- or by providing VM load addresses within Hafnium manifest (2)
-
-TF-A is the bootlader for the Hafnium and SPs in the secure world. TF-A
-does not provide tooling or libraries manipulating ramdisks as required
-by (1). Thus BL2 loads SPs payloads independently.
SPs may be signed by different parties (SiP, OEM/ODM, TOS vendor, etc.).
-Thus they are supplied as distinct “self-contained” signed entities within
-the FIP flash image. The FIP image itself is not signed hence providing
-ability to upgrade SPs in the field.
+Thus they are supplied as distinct signed entities within the FIP flash
+image. The FIP image itself is not signed hence this provides the ability
+to upgrade SPs in the field.
Booting through TF-A
--------------------
@@ -239,26 +294,27 @@
~~~~~~~~~~~~
An SP manifest describes SP attributes as defined in `[1]`_
-section 3.1 (partition manifest at virtual FF-A instance) in DTS text format. It
-is represented as a single file associated with the SP. A sample is
+(partition manifest at virtual FF-A instance) in DTS format. It is
+represented as a single file associated with the SP. A sample is
provided by `[5]`_. A binding document is provided by `[6]`_.
Secure Partition packages
~~~~~~~~~~~~~~~~~~~~~~~~~
-Secure Partitions are bundled as independent package files consisting
+Secure partitions are bundled as independent package files consisting
of:
-- a header
-- a DTB
-- an image payload
+- a header
+- a DTB
+- an image payload
The header starts with a magic value and offset values to SP DTB and
image payload. Each SP package is loaded independently by BL2 loader
and verified for authenticity and integrity.
-The SP package identified by its UUID (matching FF-A uuid) is inserted
-as a single entry into the FIP at end of the TF-A build flow as shown:
+The SP package identified by its UUID (matching FF-A uuid property) is
+inserted as a single entry into the FIP at end of the TF-A build flow
+as shown:
.. code:: shell
@@ -276,18 +332,17 @@
.. uml:: ../resources/diagrams/plantuml/fip-secure-partitions.puml
-Specifying partition binary image and DT
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Describing secure partitions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A description file (json format) is passed to the build flow specifying
-paths to the SP binary image and associated DTS partition manifest file.
-The latter is going through the dtc compiler to generate the dtb fed into
-the SP package.
-This file also specifies the owner of the SP, which is an optional field and
-identifies the signing domain in case of dualroot CoT.
-The possible owner of an SP could either be Silicon Provider or Platform, and
-the corresponding "owner" field value could either be "SiP" or "Plat".
-In absence of "owner" field, it defaults to "SiP".
+A json-formatted description file is passed to the build flow specifying paths
+to the SP binary image and associated DTS partition manifest file. The latter
+is processed by the dtc compiler to generate a DTB fed into the SP package.
+This file also specifies the SP owner (as an optional field) identifying the
+signing domain in case of dual root CoT.
+The SP owner can either be the silicon or the platform provider. The
+corresponding "owner" field value can either take the value of "SiP" or "Plat".
+In absence of "owner" field, it defaults to "SiP" owner.
.. code:: shell
@@ -308,14 +363,16 @@
SPMC manifest
~~~~~~~~~~~~~
-This manifest contains an SPMC attributes node consumed by SPMD at boot time. It
-is implementing the description from `[1]`_ section 3.2 (SP manifest at physical
-FF-A instance). The SP manifest at physical FF-A instance is used by the SPMD to
-setup a SP that co-resides with the SPMC and executes at S-EL1 or Secure
-Supervisor mode.
+This manifest contains the SPMC *attribute* node consumed by the SPMD at boot
+time. It implements `[1]`_ (SP manifest at physical FF-A instance) and serves
+two different cases:
-In this implementation its usage is extended to the secure physical FF-A
-instance where SPMC executes at S-EL2.
+- The SPMC resides at S-EL1: the SPMC manifest is used by the SPMD to setup a
+ SP that co-resides with the SPMC and executes at S-EL1 or Secure Supervisor
+ mode.
+- The SPMC resides at S-EL2: the SPMC manifest is used by the SPMD to setup
+ the environment required by the SPMC to run at S-EL2. SPs run at S-EL1 or
+ S-EL0.
.. code:: shell
@@ -329,166 +386,147 @@
binary_size = <0x60000>;
};
-- *spmc_id* defines the endpoint ID value that SPMC can query through
- ``FFA_ID_GET``.
-- *maj_ver/min_ver*. SPMD checks provided version versus its internal
- version and aborts if not matching.
-- *exec_state* defines SPMC execution state (can be AArch64 for
- Hafnium, or AArch64/AArch32 for OP-TEE at S-EL1).
-- *load_address* and *binary_size* are mostly used to verify secondary
- entry points fit into the loaded binary image.
-- *entrypoint* defines the cold boot primary core entry point used by
- SPMD (currently matches ``BL32_BASE``)
+- *spmc_id* defines the endpoint ID value that SPMC can query through
+ ``FFA_ID_GET``.
+- *maj_ver/min_ver*. SPMD checks provided version versus its internal
+ version and aborts if not matching.
+- *exec_state* defines the SPMC execution state (AArch64 or AArch32).
+ Notice Hafnium used as a SPMC only supports AArch64.
+- *load_address* and *binary_size* are mostly used to verify secondary
+ entry points fit into the loaded binary image.
+- *entrypoint* defines the cold boot primary core entry point used by
+ SPMD (currently matches ``BL32_BASE``) to enter the SPMC.
Other nodes in the manifest are consumed by Hafnium in the secure world.
A sample can be found at [7]:
-- The *chosen* node is currently unused in SWd. It is meant for NWd to
- specify the init ramdisk image.
-- The *hypervisor* node describes SPs. *is_ffa_partition* boolean
- attribute indicates an SP. Load-addr field specifies the load address
- at which TF-A loaded the SP package.
-- *cpus* node provide the platform topology and allows MPIDR to VMPIDR
- mapping. Notice with current implementation primary cpu is declared
- first, then secondary cpus must be declared in reverse order.
+- The *hypervisor* node describes SPs. *is_ffa_partition* boolean attribute
+ indicates a FF-A compliant SP. The *load_address* field specifies the load
+ address at which TF-A loaded the SP package.
+- *cpus* node provide the platform topology and allows MPIDR to VMPIDR mapping.
+ Note the primary core is declared first, then secondary core are declared
+ in reverse order.
+- The *memory* node provides platform information on the ranges of memory
+ available to the SPMC.
SPMC boot
~~~~~~~~~
The SPMC is loaded by BL2 as the BL32 image.
-The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image.
+The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image `[9]`_.
BL2 passes the SPMC manifest address to BL31 through a register.
-BL31(SPMD) runs from primary core, initializes the core contexts and
-launches BL32 passing the SPMC manifest address through a register.
+At boot time, the SPMD in BL31 runs from the primary core, initializes the core
+contexts and launches the SPMC (BL32) passing the following information through
+registers:
+
+- X0 holds the ``TOS_FW_CONFIG`` physical address (or SPMC manifest blob).
+- X1 holds the ``HW_CONFIG`` physical address.
+- X4 holds the currently running core linear id.
Loading of SPs
~~~~~~~~~~~~~~
+At boot time, BL2 loads SPs sequentially in addition to the SPMC as depicted
+below:
+
.. uml:: ../resources/diagrams/plantuml/bl2-loading-sp.puml
-
-Notice this boot flow is an implementation sample on Arm's FVP platform. Platforms
-not using FW_CONFIG would adjust to a different implementation.
+Note this boot flow is an implementation sample on Arm's FVP platform.
+Platforms not using TF-A's *Firmware CONFiguration* framework would adjust to a
+different implementation.
Secure boot
~~~~~~~~~~~
The SP content certificate is inserted as a separate FIP item so that BL2 loads SPMC,
-SPMC manifest and Secure Partitions and verifies them for authenticity and integrity.
+SPMC manifest, secure partitions and verifies them for authenticity and integrity.
Refer to TBBR specification `[3]`_.
-The multiple-signing domain feature (in current state dual signing domain) allows
-the use of two root keys namely S-ROTPK and NS-ROTPK (see `[8]`_):
+The multiple-signing domain feature (in current state dual signing domain `[8]`_) allows
+the use of two root keys namely S-ROTPK and NS-ROTPK:
-- SPMC (BL32) and SPMC manifest are signed by the SiP using the S-ROTPK.
-- BL33 may be signed by the OEM using NS-ROTPK.
-- An SP may be signed either by SiP (using S-ROTPK) or by OEM (using NS-ROTPK).
+- SPMC (BL32) and SPMC manifest are signed by the SiP using the S-ROTPK.
+- BL33 may be signed by the OEM using NS-ROTPK.
+- An SP may be signed either by SiP (using S-ROTPK) or by OEM (using NS-ROTPK).
-Longer term multiple signing domain will allow additional signing keys, e.g.
-if SPs originate from different parties.
-
-See `TF-A build options`_ for a sample build command line.
+Also refer to `Describing secure partitions`_ and `TF-A build options`_ sections.
Hafnium in the secure world
===========================
-**NOTE: this section is work in progress. Descriptions and implementation choices
-are subject to evolve.**
-
General considerations
----------------------
Build platform for the secure world
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The implementation might add specific code parts only relevant to the
-secure world. Such code parts might be isolated into different files
-and/or conditional code enclosed by a ``SECURE_WORLD`` macro.
+In the Hafnium reference implementation specific code parts are only relevant to
+the secure world. Such portions are isolated in architecture specific files
+and/or enclosed by a ``SECURE_WORLD`` macro.
-Secure Partitions CPU scheduling
+Secure partitions CPU scheduling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In the normal world, VMs are scheduled by the FFA_RUN ABI invoked from the
-primary scheduler (in the primary VM), or by a direct message request or
-response.
+The FF-A v1.0 specification `[1]`_ provides two ways to relinquinsh CPU time to
+secure partitions. For this a VM (Hypervisor or OS kernel), or SP invokes one of:
-With the FF-A EAC specification, Secure Partitions are scheduled by direct
-message invocations from a NWd VM or another SP.
+- the FFA_MSG_SEND_DIRECT_REQ interface.
+- the FFA_RUN interface.
Platform topology
~~~~~~~~~~~~~~~~~
-As stated in `[1]`_ section 4.4.1 the SPMC implementation assumes the
+The *execution-ctx-count* SP manifest field can take the value of one or the
+total number of PEs. The FF-A v1.0 specification `[1]`_ recommends the
following SP types:
-- Pinned MP SPs: an Execution Context id matches a physical PE id. MP
- SPs must implement the same number of ECs as the number of PEs in the
- platform. Hence the *execution-ctx-count* as defined by
- `[1]`_ (or NWd-Hafnium *vcpu_count*) can only take the
- value of one or the number of physical PEs.
-- Migratable UP SPs: a single execution context can run and be migrated
- on any physical PE. It declares a single EC in its SP manifest. An UP
- SP can receive a direct message request on any physical core.
-
-Usage of PSCI services in the secure world
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- The normal world Hypervisor (optional) or OS kernel issues PSCI service
- invocations e.g. to request PSCI version, wake-up a secondary core, or request
- core suspend. This happens at the non-secure physical FF-A instance. In the
- example case of Hafnium in the normal world, it boots on the primary core and
- one of the first initialization step is to request the PSCI version. It then
- launches the primary VM. The primary VM upon initializing performs PSCI service
- calls (at non-secure virtual FF-A instance) which are trapped by the
- Hypervisor. Invocation from OS Kernel ends straight at EL3. The PVM issues
- ``PSCI_CPU_ON`` service calls to wake-up secondary cores by passing an
- ``MPIDR``, entry point address and a CPU context address. The EL3 PSCI layer
- then performs an exception return to the secondary core entry point on the
- targeted core. Other PSCI calls can happen at run-time from the PVM e.g. to
- request core suspend.
-- In the existing TF-A PSCI standard library, PSCI service calls are filtered at
- EL3 to only originate from the NWd. Thus concerning the SPMC (at secure
- physical FF-A instance) the PSCI service invocations cannot happen as in the
- normal world. For example, a ``PSCI_CPU_ON`` service invocation from the SPMC
- does not reach the PSCI layer.
+- Pinned MP SPs: an execution context matches a physical PE. MP SPs must
+ implement the same number of ECs as the number of PEs in the platform.
+- Migratable UP SPs: a single execution context can run and be migrated on any
+ physical PE. Such SP declares a single EC in its SP manifest. An UP SP can
+ receive a direct message request originating from any physical core targeting
+ the single execution context.
Parsing SP partition manifests
------------------------------
-Hafnium must be able to consume SP manifests as defined in
-`[1]`_ section 3.1, at least for the mandatory fields.
+Hafnium consumes SP manifests as defined in `[1]`_ and `SP manifests`_.
+Note the current implementation may not implement all optional fields.
-The SP manifest may contain memory and device regions nodes.
+The SP manifest may contain memory and device regions nodes. In case of
+an S-EL2 SPMC:
-- Memory regions shall be mapped in the SP Stage-2 translation regime at
- load time. A memory region node can specify RX/TX buffer regions in which
- case it is not necessary for an SP to explicitly call the ``FFA_RXTX_MAP``
- service.
-- Device regions shall be mapped in SP Stage-2 translation regime as
- peripherals and possibly allocate additional resources (e.g. interrupts)
+- Memory regions are mapped in the SP EL1&0 Stage-2 translation regime at
+ load time (or EL1&0 Stage-1 for an S-EL1 SPMC). A memory region node can
+ specify RX/TX buffer regions in which case it is not necessary for an SP
+ to explicitly invoke the ``FFA_RXTX_MAP`` interface.
+- Device regions are mapped in the SP EL1&0 Stage-2 translation regime (or
+ EL1&0 Stage-1 for an S-EL1 SPMC) as peripherals and possibly allocate
+ additional resources (e.g. interrupts).
-Base addresses for memory and device region nodes are IPAs provided SPMC
-identity maps IPAs to PAs within SP Stage-2 translation regime.
+For the S-EL2 SPMC, base addresses for memory and device region nodes are IPAs
+provided the SPMC identity maps IPAs to PAs within SP EL1&0 Stage-2 translation
+regime.
-Note: currently both VTTBR_EL2 and VSTTBR_EL2 resolve to the same set of page
-tables. It is still open whether two sets of page tables shall be provided per
-SP. The memory region node as defined in the spec (section 3.1 Table 10)
+Note: in the current implementation both VTTBR_EL2 and VSTTBR_EL2 point to the
+same set of page tables. It is still open whether two sets of page tables shall
+be provided per SP. The memory region node as defined in the specification
provides a memory security attribute hinting to map either to the secure or
-non-secure stage-2 table.
+non-secure EL1&0 Stage-2 table if it exists.
Passing boot data to the SP
---------------------------
-`[1]`_ Section 3.4.2 “Protocol for passing data” defines a
-method to passing boot data to SPs (not currently implemented).
+In `[1]`_ , the "Protocol for passing data" section defines a method for passing
+boot data to SPs (not currently implemented).
-Provided that the whole Secure Partition package image (see `Secure
-Partition packages`_) is mapped to the SP's secure Stage-2 translation
-regime, an SP can access its own manifest DTB blob and extract its partition
-manifest properties.
+Provided that the whole secure partition package image (see
+`Secure Partition packages`_) is mapped to the SP secure EL1&0 Stage-2
+translation regime, an SP can access its own manifest DTB blob and extract its
+partition manifest properties.
SP Boot order
-------------
@@ -497,347 +535,540 @@
dependencies such as an SP providing a service required to properly boot
another SP.
+It is possible for an SP to call into another SP through a direct request
+provided the latter SP has already been booted.
+
Boot phases
-----------
Primary core boot-up
~~~~~~~~~~~~~~~~~~~~
-The SPMC performs its platform initializations then loads and creates
-secure partitions based on SP packages and manifests. Then each secure
-partition is launched in sequence (see `SP Boot order`_) on their primary
-Execution Context.
+Upon boot-up, BL31 hands over to the SPMC (BL32) on the primary boot physical
+core. The SPMC performs its platform initializations and registers the SPMC
+secondary physical core entry point physical address by the use of the
+FFA_SECONDARY_EP_REGISTER interface (SMC invocation from the SPMC to the SPMD
+at secure physical FF-A instance). This interface is implementation-defined in
+context of FF-A v1.0.
-Notice the primary physical core may not be core 0. Hence if the primary
-core linear id is N, the 1:1 mapping requires MP SPs are launched using
-EC[N] on PE[N] (see `Platform topology`_).
+The SPMC then creates secure partitions based on SP packages and manifests. Each
+secure partition is launched in sequence (`SP Boot order`_) on their "primary"
+execution context. If the primary boot physical core linear id is N, an MP SP is
+started using EC[N] on PE[N] (see `Platform topology`_). If the partition is a
+UP SP, it is started using its unique EC0 on PE[N].
-The SP's primary Execution Context (or the EC used when the partition is booted)
-exits through ``FFA_MSG_WAIT`` to indicate successful initialization.
+The SP primary EC (or the EC used when the partition is booted as described
+above):
-Secondary physical core boot-up
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+- Performs the overall SP boot time initialization, and in case of a MP SP,
+ prepares the SP environment for other execution contexts.
+- In the case of a MP SP, it invokes the FFA_SECONDARY_EP_REGISTER at secure
+ virtual FF-A instance (SMC invocation from SP to SPMC) to provide the IPA
+ entry point for other execution contexts.
+- Exits through ``FFA_MSG_WAIT`` to indicate successful initialization or
+ ``FFA_ERROR`` in case of failure.
-Upon boot-up, the SPMC running on the primary core performs
-implementation-defined SPMD service calls at secure physical FF-A instance
-to register the secondary physical cores entry points and context information:
+Secondary cores boot-up
+~~~~~~~~~~~~~~~~~~~~~~~
-- This is done through a direct message request invocation to the SPMD
- (``SET_ENTRY_POINT``). This service call does not wake-up the targeted
- core immediately. The secondary core is woken up later by a NWd
- ``PSCI_CPU_ON`` service invocation. A notification is passed from EL3
- PSCI layer to the SPMD, and then to SPMC through an implementation-defined
- interface.
-- The SPMC/SPMD interface can consist of FF-A direct message requests/responses
- transporting PM events.
+Once the system is started and NWd brought up, a secondary physical core is
+woken up by the ``PSCI_CPU_ON`` service invocation. The TF-A SPD hook mechanism
+calls into the SPMD on the newly woken up physical core. Then the SPMC is
+entered at the secondary physical core entry point.
-If there is no Hypervisor in the normal world, the OS Kernel issues
-``PSCI_CPU_ON`` calls that are directly trapped to EL3.
+In the current implementation, the first SP is resumed on the coresponding EC
+(the virtual CPU which matches the physical core). The implication is that the
+first SP must be a MP SP.
-When a secondary physical core wakes-up the SPMD notifies the SPMC which updates
-its internal states reflecting current physical core is being turned on.
-It might then return straight to the SPMD and then to the NWd.
+In a linux based system, once secure and normal worlds are booted but prior to
+a NWd FF-A driver has been loaded:
-*(under discussion)* There may be possibility that an SP registers "PM events"
-(during primary EC boot stage) through an ad-hoc interface. Such events would
-be relayed by SPMC to one or more registered SPs on need basis
-(see `Power management`_).
+- The first SP has initialized all its ECs in response to primary core boot up
+ (at system initialization) and secondary core boot up (as a result of linux
+ invoking PSCI_CPU_ON for all secondary cores).
+- Other SPs have their first execution context initialized as a result of secure
+ world initialization on the primary boot core. Other ECs for those SPs have to
+ be run first through ffa_run to complete their initialization (which results
+ in the EC completing with FFA_MSG_WAIT).
-Secondary virtual core boot-up
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In the example case where Hafnium exists in the normal world, secondary VMs
-issue a ``PSCI_CPU_ON`` service call which is trapped to the Hypervisor. The
-latter then enables the vCPU context for the targeted core, and switches to
-the PVM down to the kernel driver with an ``HF_WAKE_UP`` message. The NWd
-driver in PVM can then schedule the newly woken up vCPU context.
-
-In the secure world the primary EC of a given SP passes the secondary EC entry
-point and context. The SMC service call is trapped into the SPMC. This can be
-either *(under discussion)*:
-
-- a specific interface registering the secondary EC entry point,
- similarly to above ``SET_ENTRY_POINT`` service.
-- Re-purposing the ``PSCI_CPU_ON`` function id. It is
- assumed that even if the input arguments are the same as the ones defined in
- the PSCI standard, the usage deviates by the fact the secondary EC is not
- woken up immediately. At least for the PSA-FF-A EAC where only
- direct messaging is allowed, it is only after the first direct
- message invocation that the secondary EC is entered. This option
- might be preferred when the same code base is re-used for a VM or
- an SP. The ABI to wake-up a secondary EC can remain similar.
-
-SPs are always scheduled from the NWd, this paradigm did not change from legacy
-TEEs. There must always be some logic (or driver) in the NWd to relinquish CPU
-cycles to the SWd. If primary core is 0, an SP EC[x>0] entry point is supplied
-by the SP EC[0] when the system boots in SWd. But this EC[x] is not immediately
-entered at boot. Later in the boot process when NWd is up, a direct message
-request issued from physical core 1 ends up in SP EC[1], and only at this stage
-this context is effectively scheduled.
-
-It should be possible for an SP to call into another SP through direct message
-provided the latter SP has been booted already. The "boot-order" field in
-partition manifests (`SP Boot order`_) fulfills the dependency towards availability
-of a service within an SP offered to another SP.
+Refer to `Power management`_ for further details.
Mandatory interfaces
--------------------
-The following interfaces must be exposed to any VM or SP:
+The following interfaces are exposed to SPs:
-- ``FFA_STATUS``
-- ``FFA_ERROR``
-- ``FFA_INTERRUPT``
- ``FFA_VERSION``
- ``FFA_FEATURES``
- ``FFA_RX_RELEASE``
- ``FFA_RXTX_MAP``
-- ``FFA_RXTX_UNMAP``
+- ``FFA_RXTX_UNMAP`` (not implemented)
- ``FFA_PARTITION_INFO_GET``
- ``FFA_ID_GET``
+- ``FFA_MSG_WAIT``
+- ``FFA_MSG_SEND_DIRECT_REQ``
+- ``FFA_MSG_SEND_DIRECT_RESP``
+- ``FFA_MEM_DONATE``
+- ``FFA_MEM_LEND``
+- ``FFA_MEM_SHARE``
+- ``FFA_MEM_RETRIEVE_REQ``
+- ``FFA_MEM_RETRIEVE_RESP``
+- ``FFA_MEM_RELINQUISH``
+- ``FFA_MEM_RECLAIM``
+- ``FFA_SECONDARY_EP_REGISTER``
FFA_VERSION
~~~~~~~~~~~
-Per `[1]`_ section 8.1 ``FFA_VERSION`` requires a
-*requested_version* parameter from the caller.
+``FFA_VERSION`` requires a *requested_version* parameter from the caller.
+The returned value depends on the caller:
-In the current implementation when ``FFA_VERSION`` is invoked from:
-
-- Hypervisor in NS-EL2: the SPMD returns the SPMC version specified
- in the SPMC manifest.
-- OS kernel in NS-EL1 when NS-EL2 is not present: the SPMD returns the
- SPMC version specified in the SPMC manifest.
-- VM in NWd: the Hypervisor returns its implemented version.
-- SP in SWd: the SPMC returns its implemented version.
-- SPMC at S-EL1/S-EL2: the SPMD returns its implemented version.
+- Hypervisor or OS kernel in NS-EL1/EL2: the SPMD returns the SPMC version
+ specified in the SPMC manifest.
+- SP: the SPMC returns its own implemented version.
+- SPMC at S-EL1/S-EL2: the SPMD returns its own implemented version.
FFA_FEATURES
~~~~~~~~~~~~
-FF-A features may be discovered by Secure Partitions while booting
-through the SPMC. However, SPMC cannot get features from Hypervisor
-early at boot time as NS world is not setup yet.
+FF-A features supported by the SPMC may be discovered by secure partitions at
+boot (that is prior to NWd is booted) or run-time.
-The Hypervisor may decide to gather FF-A features from SPMC through SPMD
-once at boot time and store the result. Later when a VM requests FF-A
-features, the Hypervisor can adjust its own set of features with what
-SPMC advertised, if necessary. Another approach is to always forward FF-A
-features to the SPMC when a VM requests it to the Hypervisor. Although
-the result is not supposed to change over time so there may not be added
-value doing the systematic forwarding.
+The SPMC calling FFA_FEATURES at secure physical FF-A instance always get
+FFA_SUCCESS from the SPMD.
+
+The request made by an Hypervisor or OS kernel is forwarded to the SPMC and
+the response relayed back to the NWd.
FFA_RXTX_MAP/FFA_RXTX_UNMAP
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-VM mailboxes are re-purposed to serve as SP RX/TX buffers. The RX/TX
-map API maps the send and receive buffer IPAs to the SP Stage-2 translation regime.
+When invoked from a secure partition FFA_RXTX_MAP maps the provided send and
+receive buffers described by their IPAs to the SP EL1&0 Stage-2 translation
+regime as secure buffers in the MMU descriptors.
-Hafnium in the normal world defines VMs and their attributes as logical structures,
-including a mailbox used for FF-A indirect messaging, memory sharing, or the
-`FFA_PARTITION_INFO_GET`_ ABI.
-This same mailbox structure is re-used in the SPMC. `[1]`_ states only direct
-messaging is allowed to SPs. Thus mailbox usage is restricted to implementing
-`FFA_PARTITION_INFO_GET`_ and memory sharing ABIs.
+When invoked from the Hypervisor or OS kernel, the buffers are mapped into the
+SPMC EL2 Stage-1 translation regime and marked as NS buffers in the MMU
+descriptors.
+
+Note:
+
+- FFA_RXTX_UNMAP is not implemented.
FFA_PARTITION_INFO_GET
~~~~~~~~~~~~~~~~~~~~~~
-Partition info get service call can originate:
+Partition info get call can originate:
-- from SP to SPM
-- from VM to Hypervisor
-- from Hypervisor to SPM
-
-For the latter case, the service call must be forwarded through the SPMD.
+- from SP to SPMC
+- from Hypervisor or OS kernel to SPMC. The request is relayed by the SPMD.
FFA_ID_GET
~~~~~~~~~~
-The SPMD returns:
-
-- a default zero value on invocation from the Hypervisor.
-- The ``spmc_id`` value specified in the SPMC manifest on invocation from
- the SPMC (see `SPMC manifest`_)
-
The FF-A id space is split into a non-secure space and secure space:
-- FF-A id with bit 15 clear refer to normal world VMs.
-- FF-A id with bit 15 set refer to secure world SPs
+- FF-A ID with bit 15 clear relates to VMs.
+- FF-A ID with bit 15 set related to SPs.
+- FF-A IDs 0, 0xffff, 0x8000 are assigned respectively to the Hypervisor, SPMD
+ and SPMC.
-Such convention helps the SPMC discriminating the origin and destination worlds
-in an FF-A service invocation. In particular the SPMC shall filter unauthorized
+The SPMD returns:
+
+- The default zero value on invocation from the Hypervisor.
+- The ``spmc_id`` value specified in the SPMC manifest on invocation from
+ the SPMC (see `SPMC manifest`_)
+
+This convention helps the SPMC to determine the origin and destination worlds in
+an FF-A ABI invocation. In particular the SPMC shall filter unauthorized
transactions in its world switch routine. It must not be permitted for a VM to
-use a secure FF-A id as origin world through spoofing:
+use a secure FF-A ID as origin world by spoofing:
-- A VM-to-SP messaging passing shall have an origin world being non-secure
- (FF-A id bit 15 clear) and destination world being secure (FF-A id bit 15
- set).
-- Similarly, an SP-to-SP message shall have FF-A id bit 15 set for both origin
- and destination ids.
+- A VM-to-SP direct request/response shall set the origin world to be non-secure
+ (FF-A ID bit 15 clear) and destination world to be secure (FF-A ID bit 15
+ set).
+- Similarly, an SP-to-SP direct request/response shall set the FF-A ID bit 15
+ for both origin and destination IDs.
An incoming direct message request arriving at SPMD from NWd is forwarded to
SPMC without a specific check. The SPMC is resumed through eret and "knows" the
message is coming from normal world in this specific code path. Thus the origin
-endpoint id must be checked by SPMC for being a normal world id.
+endpoint ID must be checked by SPMC for being a normal world ID.
An SP sending a direct message request must have bit 15 set in its origin
-endpoint id and this can be checked by the SPMC when the SP invokes the ABI.
+endpoint ID and this can be checked by the SPMC when the SP invokes the ABI.
The SPMC shall reject the direct message if the claimed world in origin endpoint
-id is not consistent:
+ID is not consistent:
-- It is either forwarded by SPMD and thus origin endpoint id must be a "normal
- world id",
-- or initiated by an SP and thus origin endpoint id must be a "secure world id".
+- It is either forwarded by SPMD and thus origin endpoint ID must be a "normal
+ world ID",
+- or initiated by an SP and thus origin endpoint ID must be a "secure world ID".
-Direct messaging
-----------------
-This is a mandatory interface for Secure Partitions consisting in direct
-message request and responses.
+FFA_MSG_SEND_DIRECT_REQ/FFA_MSG_SEND_DIRECT_RESP
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The ``ffa_handler`` Hafnium function may:
+This is a mandatory interface for secure partitions consisting in direct request
+and responses with the following rules:
-- trigger a world change e.g. when an SP invokes the direct message
- response ABI to a VM.
-- handle multiple requests from the NWd without resuming an SP.
+- An SP can send a direct request to another SP.
+- An SP can receive a direct request from another SP.
+- An SP can send a direct response to another SP.
+- An SP cannot send a direct request to an Hypervisor or OS kernel.
+- An Hypervisor or OS kernel can send a direct request to an SP.
+- An SP can send a direct response to an Hypervisor or OS kernel.
-SP-to-SP
-~~~~~~~~
+SPMC-SPMD direct requests/responses
+-----------------------------------
-- An SP can send a direct message request to another SP
-- An SP can receive a direct message response from another SP.
+Implementation-defined FF-A IDs are allocated to the SPMC and SPMD.
+Using those IDs in source/destination fields of a direct request/response
+permits SPMD to SPMC communication and either way.
-VM-to-SP
-~~~~~~~~
+- SPMC to SPMD direct request/response uses SMC conduit.
+- SPMD to SPMC direct request/response uses ERET conduit.
-- A VM can send a direct message request to an SP
-- An SP can send a direct message response to a VM
+PE MMU configuration
+--------------------
-SPMC-SPMD messaging
-~~~~~~~~~~~~~~~~~~~
+With secure virtualization enabled, two IPA spaces are output from the secure
+EL1&0 Stage-1 translation (secure and non-secure). The EL1&0 Stage-2 translation
+hardware is fed by:
-Specific implementation-defined endpoint IDs are allocated to the SPMC and SPMD.
-Referring those IDs in source/destination fields of a direct message
-request/response permits SPMD to SPMC messaging back and forth.
+- A single secure IPA space when the SP EL1&0 Stage-1 MMU is disabled.
+- Two IPA spaces (secure and non-secure) when the SP EL1&0 Stage-1 MMU is
+ enabled.
-Per `[1]`_ Table 114 Config No. 1 (physical FF-A instance):
+``VTCR_EL2`` and ``VSTCR_EL2`` provide configuration bits for controlling the
+NS/S IPA translations.
+``VSTCR_EL2.SW`` = 0, ``VSTCR_EL2.SA`` = 0,``VTCR_EL2.NSW`` = 0, ``VTCR_EL2.NSA`` = 1:
-- SPMC=>SPMD direct message request uses SMC conduit
-- SPMD=>SPMC direct message request uses ERET conduit
+- Stage-2 translations for the NS IPA space access the NS PA space.
+- Stage-2 translation table walks for the NS IPA space are to the secure PA space.
-Per `[1]`_ Table 118 Config No. 1 (physical FF-A instance):
-
-- SPMC=>SPMD direct message response uses SMC conduit
-- SPMD=>SPMC direct message response uses ERET conduit
-
-Memory management
------------------
-
-This section only deals with the PE MMU configuration.
-
-Hafnium in the normal world deals with NS buffers only and provisions
-a single root page table directory to VMs. In context of S-EL2 enabled
-firmware, two IPA spaces are output from Stage-1 translation (secure
-and non-secure). The Stage-2 translation handles:
-
-- A single secure IPA space when an SP Stage-1 MMU is disabled.
-- Two IPA spaces (secure and non-secure) when Stage-1 MMU is enabled.
-
-``VTCR_EL2`` and ``VSTCR_EL2`` provide additional bits for controlling the
-NS/S IPA translations (``VSTCR_EL2.SW``, ``VSTCR_EL2.SA``, ``VTCR_EL2.NSW``,
-``VTCR_EL2.NSA``). There may be two approaches:
-
-- secure and non-secure mappings are rooted as two separate root page
- tables
-- secure and non-secure mappings use the same root page table. Access
- from S-EL1 to an NS region translates to a secure physical address
- space access.
+Secure and non-secure IPA regions use the same set of Stage-2 page tables within
+a SP.
Interrupt management
--------------------
-Road to a para-virtualized interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+GIC ownership
+~~~~~~~~~~~~~
-Current Hafnium implementation uses an ad-hoc mechanism for a VM to get
-a pending interrupt number through an hypercall. The PVM injects
-interrupts to VMs by delegation from the Hypervisor. The PVM probes a
-pending interrupt directly from the GIC distributor.
+The SPMC owns the GIC configuration. Secure and non-secure interrupts are
+trapped at S-EL2. The SPMC manages interrupt resources and allocates interrupt
+IDs based on SP manifests. The SPMC acknowledges physical interrupts and injects
+virtual interrupts by setting the use of vIRQ/vFIQ bits before resuming a SP.
-The short-term plan is to have Hafnium/SPMC in the secure world owner
-of the GIC configuration.
+Non-secure interrupt handling
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The SPMC fully owns the GIC configuration at S-EL2. The SPMC manages
-interrupt resources and allocates interrupt ID based on SP manifests.
-The SPMC acknowledges physical interrupts and injects virtual interrupts
-by setting the vIRQ bit when resuming an SP. A Secure Partition gathers
-the interrupt number through an hypercall.
+The following illustrate the scenarios of non secure physical interrupts trapped
+by the SPMC:
-Notice the SPMC/SPMD has to handle Group0 secure interrupts in addition
-to Group1 S/NS interrupts.
+- The SP handles a managed exit operation:
+
+.. image:: ../resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png
+
+- The SP is pre-empted without managed exit:
+
+.. image:: ../resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png
+
+Secure interrupt handling
+-------------------------
+
+This section documents the support implemented for secure interrupt handling in
+SPMC as per the guidance provided by FF-A v1.1 Beta0 specification.
+The following assumptions are made about the system configuration:
+
+ - In the current implementation, S-EL1 SPs are expected to use the para
+ virtualized ABIs for interrupt management rather than accessing virtual GIC
+ interface.
+ - Unless explicitly stated otherwise, this support is applicable only for
+ S-EL1 SPs managed by SPMC.
+ - Secure interrupts are configured as G1S or G0 interrupts.
+ - All physical interrupts are routed to SPMC when running a secure partition
+ execution context.
+
+A physical secure interrupt could preempt normal world execution. Moreover, when
+the execution is in secure world, it is highly likely that the target of a
+secure interrupt is not the currently running execution context of an SP. It
+could be targeted to another FF-A component. Consequently, secure interrupt
+management depends on the state of the target execution context of the SP that
+is responsible for handling the interrupt. Hence, the spec provides guidance on
+how to signal start and completion of secure interrupt handling as discussed in
+further sections.
+
+Secure interrupt signaling mechanisms
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Signaling refers to the mechanisms used by SPMC to indicate to the SP execution
+context that it has a pending virtual interrupt and to further run the SP
+execution context, such that it can handle the virtual interrupt. SPMC uses
+either the FFA_INTERRUPT interface with ERET conduit or vIRQ signal for signaling
+to S-EL1 SPs. When normal world execution is preempted by a secure interrupt,
+the SPMD uses the FFA_INTERRUPT ABI with ERET conduit to signal interrupt to SPMC
+running in S-EL2.
+
++-----------+---------+---------------+---------------------------------------+
+| SP State | Conduit | Interface and | Description |
+| | | parameters | |
++-----------+---------+---------------+---------------------------------------+
+| WAITING | ERET, | FFA_INTERRUPT,| SPMC signals to SP the ID of pending |
+| | vIRQ | Interrupt ID | interrupt. It pends vIRQ signal and |
+| | | | resumes execution context of SP |
+| | | | through ERET. |
++-----------+---------+---------------+---------------------------------------+
+| BLOCKED | ERET, | FFA_INTERRUPT | SPMC signals to SP that an interrupt |
+| | vIRQ | | is pending. It pends vIRQ signal and |
+| | | | resumes execution context of SP |
+| | | | through ERET. |
++-----------+---------+---------------+---------------------------------------+
+| PREEMPTED | vIRQ | NA | SPMC pends the vIRQ signal but does |
+| | | | not resume execution context of SP. |
++-----------+---------+---------------+---------------------------------------+
+| RUNNING | ERET, | NA | SPMC pends the vIRQ signal and resumes|
+| | vIRQ | | execution context of SP through ERET. |
++-----------+---------+---------------+---------------------------------------+
+
+Secure interrupt completion mechanisms
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A SP signals secure interrupt handling completion to the SPMC through the
+following mechanisms:
+
+ - ``FFA_MSG_WAIT`` ABI if it was in WAITING state.
+ - ``FFA_RUN`` ABI if its was in BLOCKED state.
+
+In the current implementation, S-EL1 SPs use para-virtualized HVC interface
+implemented by SPMC to perform priority drop and interrupt deactivation (we
+assume EOImode = 0, i.e. priority drop and deactivation are done together).
+
+If normal world execution was preempted by secure interrupt, SPMC uses
+FFA_NORMAL_WORLD_RESUME ABI to indicate completion of secure interrupt handling
+and further return execution to normal world. If the current SP execution
+context was preempted by a secure interrupt to be handled by execution context
+of target SP, SPMC resumes current SP after signal completion by target SP
+execution context.
+
+An action is broadly a set of steps taken by the SPMC in response to a physical
+interrupt. In order to simplify the design, the current version of secure
+interrupt management support in SPMC (Hafnium) does not fully implement the
+Scheduling models and Partition runtime models. However, the current
+implementation loosely maps to the following actions that are legally allowed
+by the specification. Please refer to the Table 8.4 in the spec for further
+description of actions. The action specified for a type of interrupt when the
+SP is in the message processing running state cannot be less permissive than the
+action specified for the same type of interrupt when the SP is in the interrupt
+handling running state.
+
++--------------------+--------------------+------------+-------------+
+| Runtime Model | NS-Int | Self S-Int | Other S-Int |
++--------------------+--------------------+------------+-------------+
+| Message Processing | Signalable with ME | Signalable | Signalable |
++--------------------+--------------------+------------+-------------+
+| Interrupt Handling | Queued | Queued | Queued |
++--------------------+--------------------+------------+-------------+
+
+Abbreviations:
+
+ - NS-Int: A Non-secure physical interrupt. It requires a switch to the Normal
+ world to be handled.
+ - Other S-Int: A secure physical interrupt targeted to an SP different from
+ the one that is currently running.
+ - Self S-Int: A secure physical interrupt targeted to the SP that is currently
+ running.
+
+The following figure describes interrupt handling flow when secure interrupt
+triggers while in normal world:
+
+.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-nwd.png
+
+A brief description of the events:
+
+ - 1) Secure interrupt triggers while normal world is running.
+ - 2) FIQ gets trapped to EL3.
+ - 3) SPMD signals secure interrupt to SPMC at S-EL2 using FFA_INTERRUPT ABI.
+ - 4) SPMC identifies target vCPU of SP and injects virtual interrupt (pends
+ vIRQ).
+ - 5) Since SP1 vCPU is in WAITING state, SPMC signals using FFA_INTERRUPT with
+ interrupt id as argument and resume it using ERET.
+ - 6) Execution traps to vIRQ handler in SP1 provided that interrupt is not
+ masked i.e., PSTATE.I = 0
+ - 7) SP1 services the interrupt and invokes the de-activation HVC call.
+ - 8) SPMC does internal state management and further de-activates the physical
+ interrupt and resumes SP vCPU.
+ - 9) SP performs secure interrupt completion through FFA_MSG_WAIT ABI.
+ - 10) SPMC returns control to EL3 using FFA_NORMAL_WORLD_RESUME.
+ - 11) EL3 resumes normal world execution.
+
+The following figure describes interrupt handling flow when secure interrupt
+triggers while in secure world:
+
+.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-swd.png
+
+A brief description of the events:
+
+ - 1) Secure interrupt triggers while SP2 is running and SP1 is blocked.
+ - 2) Gets trapped to SPMC as IRQ.
+ - 3) SPMC finds the target vCPU of secure partition responsible for handling
+ this secure interrupt. In this scenario, it is SP1.
+ - 4) SPMC pends vIRQ for SP1 and signals through FFA_INTERRUPT interface.
+ SPMC further resumes SP1 through ERET conduit.
+ - 5) Execution traps to vIRQ handler in SP1 provided that interrupt is not
+ masked i.e., PSTATE.I = 0
+ - 6) SP1 services the secure interrupt and invokes the de-activation HVC call.
+ - 7) SPMC does internal state management, de-activates the physical interrupt
+ and resumes SP1 vCPU.
+ - 8) Assuming SP1 is in BLOCKED state, SP1 performs secure interrupt completion
+ through FFA_RUN ABI.
+ - 9) SPMC resumes the pre-empted vCPU of SP2.
+
Power management
----------------
-Assumption on the Nwd:
+In platforms with or without secure virtualization:
-- NWd is the best candidate to own the platform Power Management
- policy. It is master to invoking PSCI service calls from physical
- CPUs.
-- EL3 monitor is in charge of the PM control part (its PSCI layer
- actually writing to platform registers).
-- It is fine for the Hypervisor to trap PSCI calls and relay to EL3, or
- OS kernel driver to emit PSCI service calls.
+- The NWd owns the platform PM policy.
+- The Hypervisor or OS kernel is the component initiating PSCI service calls.
+- The EL3 PSCI library is in charge of the PM coordination and control
+ (eventually writing to platform registers).
+- While coordinating PM events, the PSCI library calls backs into the Secure
+ Payload Dispatcher for events the latter has statically registered to.
-PSCI notification are relayed through the SPMD/SPD PM hooks to the SPMC.
-This can either be through re-use of PSCI FIDs or an FF-A direct message
-from SPMD to SPMC.
+When using the SPMD as a Secure Payload Dispatcher:
-The SPMD performs an exception return to the SPMC which is resumed to
-its ``eret_handler`` routine. It is then either consuming a PSCI FID or
-an FF-A FID. Depending on the servicing, the SPMC may return directly to
-the SPMD (and then NWd) without resuming an SP at this stage. An example
-of this is invocation of ``FFA_PARTITION_INFO_GET`` from NWd relayed by
-the SPMD to the SPMC. The SPMC returns the needed partition information
-to the SPMD (then NWd) without actually resuming a partition in secure world.
+- A power management event is relayed through the SPD hook to the SPMC.
+- In the current implementation only cpu on (svc_on_finish) and cpu off
+ (svc_off) hooks are registered.
+- The behavior for the cpu on event is described in `Secondary cores boot-up`_.
+ The SPMC is entered through its secondary physical core entry point.
+- The cpu off event occurs when the NWd calls PSCI_CPU_OFF. The method by which
+ the PM event is conveyed to the SPMC is implementation-defined in context of
+ FF-A v1.0 (`SPMC-SPMD direct requests/responses`_). It consists in a SPMD-to-SPMC
+ direct request/response conveying the PM event details and SPMC response.
+ The SPMD performs a synchronous entry into the SPMC. The SPMC is entered and
+ updates its internal state to reflect the physical core is being turned off.
+ In the current implementation no SP is resumed as a consequence. This behavior
+ ensures a minimal support for CPU hotplug e.g. when initiated by the NWd linux
+ userspace.
-*(under discussion)*
-About using PSCI FIDs from SPMD to SPMC to notify of PM events, it is still
-questioned what to use as the return code from the SPMC.
-If the function ID used by the SPMC is not an FF-A ID when doing SMC, then the
-EL3 std svc handler won't route the response to the SPMD. That's where comes the
-idea to embed the notification into an FF-A message. The SPMC can discriminate
-this message as being a PSCI event, process it, and reply with an FF-A return
-message that the SPMD receives as an acknowledgement.
+SMMUv3 support in Hafnium
+=========================
-SP notification
+An SMMU is analogous to an MMU in a CPU. It performs address translations for
+Direct Memory Access (DMA) requests from system I/O devices.
+The responsibilities of an SMMU include:
+
+- Translation: Incoming DMA requests are translated from bus address space to
+ system physical address space using translation tables compliant to
+ Armv8/Armv7 VMSA descriptor format.
+- Protection: An I/O device can be prohibited from read, write access to a
+ memory region or allowed.
+- Isolation: Traffic from each individial device can be independently managed.
+ The devices are differentiated from each other using unique translation
+ tables.
+
+The following diagram illustrates a typical SMMU IP integrated in a SoC with
+several I/O devices along with Interconnect and Memory system.
+
+.. image:: ../resources/diagrams/MMU-600.png
+
+SMMU has several versions including SMMUv1, SMMUv2 and SMMUv3. Hafnium provides
+support for SMMUv3 driver in both normal and secure world. A brief introduction
+of SMMUv3 functionality and the corresponding software support in Hafnium is
+provided here.
+
+SMMUv3 features
---------------
-Power management notifications are conveyed from PSCI library to the
-SPMD / SPD hooks. A range of events can be relayed to SPMC.
+- SMMUv3 provides Stage1, Stage2 translation as well as nested (Stage1 + Stage2)
+ translation support. It can either bypass or abort incoming translations as
+ well.
+- Traffic (memory transactions) from each upstream I/O peripheral device,
+ referred to as Stream, can be independently managed using a combination of
+ several memory based configuration structures. This allows the SMMUv3 to
+ support a large number of streams with each stream assigned to a unique
+ translation context.
+- Support for Armv8.1 VMSA where the SMMU shares the translation tables with
+ a Processing Element. AArch32(LPAE) and AArch64 translation table format
+ are supported by SMMUv3.
+- SMMUv3 offers non-secure stream support with secure stream support being
+ optional. Logically, SMMUv3 behaves as if there is an indepdendent SMMU
+ instance for secure and non-secure stream support.
+- It also supports sub-streams to differentiate traffic from a virtualized
+ peripheral associated with a VM/SP.
+- Additionally, SMMUv3.2 provides support for PEs implementing Armv8.4-A
+ extensions. Consequently, SPM depends on Secure EL2 support in SMMUv3.2
+ for providing Secure Stage2 translation support to upstream peripheral
+ devices.
-SPs may need to be notified about specific PM events.
+SMMUv3 Programming Interfaces
+-----------------------------
-- SPs might register PM events to the SPMC
-- On SPMD to SPMC notification, a limited range of SPs may be notified
- through a direct message.
-- This assumes the mentioned SPs supports managed exit.
+SMMUv3 has three software interfaces that are used by the Hafnium driver to
+configure the behaviour of SMMUv3 and manage the streams.
-The SPMC is the first to be notified about PM events from the SPMD. It is up
-to the SPMC to arbitrate to which SP it needs to send PM events.
-An SP explicitly registers to receive notifications to specific PM events.
-The register operation can either be an implementation-defined service call
-to the SPMC when the primary SP EC boots, or be supplied through the SP
-manifest.
+- Memory based data strutures that provide unique translation context for
+ each stream.
+- Memory based circular buffers for command queue and event queue.
+- A large number of SMMU configuration registers that are memory mapped during
+ boot time by Hafnium driver. Except a few registers, all configuration
+ registers have independent secure and non-secure versions to configure the
+ behaviour of SMMUv3 for translation of secure and non-secure streams
+ respectively.
+
+Peripheral device manifest
+--------------------------
+
+Currently, SMMUv3 driver in Hafnium only supports dependent peripheral devices.
+These devices are dependent on PE endpoint to initiate and receive memory
+management transactions on their behalf. The acccess to the MMIO regions of
+any such device is assigned to the endpoint during boot. Moreover, SMMUv3 driver
+uses the same stage 2 translations for the device as those used by partition
+manager on behalf of the PE endpoint. This ensures that the peripheral device
+has the same visibility of the physical address space as the endpoint. The
+device node of the corresponding partition manifest (refer to `[1]`_ section 3.2
+) must specify these additional properties for each peripheral device in the
+system :
+
+- smmu-id: This field helps to identify the SMMU instance that this device is
+ upstream of.
+- stream-ids: List of stream IDs assigned to this device.
+
+.. code:: shell
+
+ smmuv3-testengine {
+ base-address = <0x00000000 0x2bfe0000>;
+ pages-count = <32>;
+ attributes = <0x3>;
+ smmu-id = <0>;
+ stream-ids = <0x0 0x1>;
+ interrupts = <0x2 0x3>, <0x4 0x5>;
+ exclusive-access;
+ };
+
+SMMUv3 driver limitations
+-------------------------
+
+The primary design goal for the Hafnium SMMU driver is to support secure
+streams.
+
+- Currently, the driver only supports Stage2 translations. No support for
+ Stage1 or nested translations.
+- Supports only AArch64 translation format.
+- No support for features such as PCI Express (PASIDs, ATS, PRI), MSI, RAS,
+ Fault handling, Performance Monitor Extensions, Event Handling, MPAM.
+- No support for independent peripheral devices.
References
==========
.. _[1]:
-[1] `Platform Security Architecture Firmware Framework for Arm® v8-A 1.0 Platform Design Document <https://developer.arm.com/docs/den0077/latest>`__
+[1] `Arm Firmware Framework for Arm A-profile <https://developer.arm.com/docs/den0077/latest>`__
.. _[2]:
@@ -846,7 +1077,7 @@
.. _[3]:
[3] `Trusted Boot Board Requirements
-Client <https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a>`__
+Client <https://developer.arm.com/documentation/den0006/d/>`__
.. _[4]:
@@ -854,11 +1085,11 @@
.. _[5]:
-[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus.dts
+[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/arm/fvp/fdts/cactus.dts
.. _[6]:
-[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manifest-binding.html
+[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
.. _[7]:
@@ -866,8 +1097,12 @@
.. _[8]:
-[8] https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/
+[8] https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000296.html
+
+.. _[9]:
+
+[9] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#dynamic-configuration-during-cold-boot
--------------
-*Copyright (c) 2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2020-2021, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/components/xlat-tables-lib-v2-design.rst b/docs/components/xlat-tables-lib-v2-design.rst
index af5151f..cac32f5 100644
--- a/docs/components/xlat-tables-lib-v2-design.rst
+++ b/docs/components/xlat-tables-lib-v2-design.rst
@@ -10,7 +10,7 @@
More specifically, some use cases that this library aims to support are:
#. Statically allocate translation tables and populate them (at run-time) based
- on a description of the memory layout. The memory layout is typically
+ upon a description of the memory layout. The memory layout is typically
provided by the platform port as a list of memory regions;
#. Support for generating translation tables pertaining to a different
@@ -26,22 +26,28 @@
#. Support for changing memory attributes of memory regions at run-time.
-About version 1 and version 2
------------------------------
+About version 1, version 2 and MPU libraries
+--------------------------------------------
This document focuses on version 2 of the library, whose sources are available
in the ``lib/xlat_tables_v2`` directory. Version 1 of the library can still be
found in ``lib/xlat_tables`` directory but it is less flexible and doesn't
-support dynamic mapping. Although potential bug fixes will be applied to both
-versions, future features enhancements will focus on version 2 and might not be
-back-ported to version 1. Therefore, it is recommended to use version 2,
-especially for new platform ports.
+support dynamic mapping. ``lib/xlat_mpu``, which configures Arm's MPU
+equivalently, is also addressed here. The ``lib/xlat_mpu`` is experimental,
+meaning that its API may change. It currently strives for consistency and
+code-reuse with xlat_tables_v2. Future versions may be more MPU-specific (e.g.,
+removing all mentions of virtual addresses). Although potential bug fixes will
+be applied to all versions of the xlat_* libs, future feature enhancements will
+focus on version 2 and might not be back-ported to version 1 and MPU versions.
+Therefore, it is recommended to use version 2, especially for new platform
+ports (unless the platform uses an MPU).
-However, please note that version 2 is still in active development and is not
-considered stable yet. Hence, compatibility breaks might be introduced.
+However, please note that version 2 and the MPU version are still in active
+development and is not considered stable yet. Hence, compatibility breaks might
+be introduced.
From this point onwards, this document will implicitly refer to version 2 of the
-library.
+library, unless stated otherwise.
Design concepts and interfaces
@@ -102,6 +108,16 @@
library will choose the mapping granularity for this region as it sees fit (more
details can be found in `The memory mapping algorithm`_ section below).
+The MPU library also uses ``struct mmap_region`` to specify translations, but
+the MPU's translations are limited to specification of valid addresses and
+access permissions. If the requested virtual and physical addresses mismatch
+the system will panic. Being register-based for deterministic memory-reference
+timing, the MPU hardware does not involve memory-resident translation tables.
+
+Currently, the MPU library is also limited to MPU translation at EL2 with no
+MMU translation at other ELs. These limitations, however, are expected to be
+overcome in future library versions.
+
Translation Context
~~~~~~~~~~~~~~~~~~~
@@ -215,7 +231,8 @@
The ``MAP_REGION()`` and ``MAP_REGION_FLAT()`` macros do not allow specifying a
mapping granularity, which leaves the library implementation free to choose
it. However, in cases where a specific granularity is required, the
-``MAP_REGION2()`` macro might be used instead.
+``MAP_REGION2()`` macro might be used instead. Using ``MAP_REGION_FLAT()`` only
+to define regions for the MPU library is strongly recommended.
As explained earlier in this document, when the dynamic mapping feature is
disabled, there is no notion of dynamic regions. Conceptually, there are only
@@ -374,6 +391,9 @@
refer to the comments in the source code of the core module for more details
about the sorting algorithm in use.
+This mapping algorithm does not apply to the MPU library, since the MPU hardware
+directly maps regions by "base" and "limit" (bottom and top) addresses.
+
TLB maintenance operations
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -390,6 +410,11 @@
is deferred to the ``enable_mmu*()`` family of functions, just before the MMU is
turned on.
+Regarding enabling and disabling memory management, for the MPU library, to
+reduce confusion, calls to enable or disable the MPU use ``mpu`` in their names
+in place of ``mmu``. For example, the ``enable_mmu_el2()`` call is changed to
+``enable_mpu_el2()``.
+
TLB invalidation is not required when adding dynamic regions either. Dynamic
regions are not allowed to overlap existing memory region. Therefore, if the
dynamic mapping request is deemed legitimate, it automatically concerns memory
@@ -412,6 +437,6 @@
--------------
-*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2021, Arm Limited and Contributors. All rights reserved.*
.. |Alignment Example| image:: ../resources/diagrams/xlat_align.png
diff --git a/docs/conf.py b/docs/conf.py
index a100241..356be99 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -1,6 +1,6 @@
# -*- coding: utf-8 -*-
#
-# Copyright (c) 2019, Arm Limited. All rights reserved.
+# Copyright (c) 2019-2021, Arm Limited. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -76,6 +76,14 @@
'style_external_links': True # Display an icon next to external links
}
+# Path to _static directory
+html_static_path = ['_static']
+
+# Path to css file relative to html_static_path
+html_css_files = [
+ 'css/custom.css',
+]
+
# -- Options for autosectionlabel --------------------------------------------
# Only generate automatic section labels for document titles
diff --git a/docs/design/cpu-specific-build-macros.rst b/docs/design/cpu-specific-build-macros.rst
index c976b8b..9d0dd5e 100644
--- a/docs/design/cpu-specific-build-macros.rst
+++ b/docs/design/cpu-specific-build-macros.rst
@@ -241,9 +241,6 @@
- ``ERRATA_A76_1791580``: This applies errata 1791580 workaround to Cortex-A76
CPU. This needs to be enabled only for revision <= r4p0 of the CPU.
-- ``ERRATA_A76_1800710``: This applies errata 1800710 workaround to Cortex-A76
- CPU. This needs to be enabled only for revision <= r4p0 of the CPU.
-
- ``ERRATA_A76_1165522``: This applies errata 1165522 workaround to all
revisions of Cortex-A76 CPU. This errata is fixed in r3p0 but due to
limitation of errata framework this errata is applied to all revisions
@@ -252,22 +249,59 @@
- ``ERRATA_A76_1868343``: This applies errata 1868343 workaround to Cortex-A76
CPU. This needs to be enabled only for revision <= r4p0 of the CPU.
+- ``ERRATA_A76_1946160``: This applies errata 1946160 workaround to Cortex-A76
+ CPU. This needs to be enabled only for revisions r3p0 - r4p1 of the CPU.
+
For Cortex-A77, the following errata build flags are defined :
- ``ERRATA_A77_1508412``: This applies errata 1508412 workaround to Cortex-A77
CPU. This needs to be enabled only for revision <= r1p0 of the CPU.
-- ``ERRATA_A77_1800714``: This applies errata 1800714 workaround to Cortex-A77
- CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
-
- ``ERRATA_A77_1925769``: This applies errata 1925769 workaround to Cortex-A77
CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
+- ``ERRATA_A77_1946167``: This applies errata 1946167 workaround to Cortex-A77
+ CPU. This needs to be enabled only for revision <= r1p1 of the CPU.
+
+- ``ERRATA_A77_1791578``: This applies errata 1791578 workaround to Cortex-A77
+ CPU. This needs to be enabled for r0p0, r1p0, and r1p1, it is still open.
+
For Cortex-A78, the following errata build flags are defined :
- ``ERRATA_A78_1688305``: This applies errata 1688305 workaround to Cortex-A78
CPU. This needs to be enabled only for revision r0p0 - r1p0 of the CPU.
+- ``ERRATA_A78_1941498``: This applies errata 1941498 workaround to Cortex-A78
+ CPU. This needs to be enabled for revisions r0p0, r1p0, and r1p1 of the CPU.
+
+- ``ERRATA_A78_1951500``: This applies errata 1951500 workaround to Cortex-A78
+ CPU. This needs to be enabled for revisions r1p0 and r1p1, r0p0 has the same
+ issue but there is no workaround for that revision.
+
+- ``ERRATA_A78_1821534``: This applies errata 1821534 workaround to Cortex-A78
+ CPU. This needs to be enabled for revisions r0p0 and r1p0.
+
+- ``ERRATA_A78_1952683``: This applies errata 1952683 workaround to Cortex-A78
+ CPU. This needs to be enabled for revision r0p0, it is fixed in r1p0.
+
+- ``ERRATA_A78_2132060``: This applies errata 2132060 workaround to Cortex-A78
+ CPU. This needs to be enabled for revisions r0p0, r1p0, r1p1, and r1p2. It
+ is still open.
+
+- ``ERRATA_A78_2242635``: This applies errata 2242635 workaround to Cortex-A78
+ CPU. This needs to be enabled for revisions r1p0, r1p1, and r1p2. The issue
+ is present in r0p0 but there is no workaround. It is still open.
+
+For Cortex-A78 AE, the following errata build flags are defined :
+
+- ``ERRATA_A78_AE_1941500`` : This applies errata 1941500 workaround to Cortex-A78
+ AE CPU. This needs to be enabled for revisions r0p0 and r0p1. This erratum is
+ still open.
+
+- ``ERRATA_A78_AE_1951502`` : This applies errata 1951502 workaround to Cortex-A78
+ AE CPU. This needs to be enabled for revisions r0p0 and r0p1. This erratum is
+ still open.
+
For Neoverse N1, the following errata build flags are defined :
- ``ERRATA_N1_1073348``: This applies errata 1073348 workaround to Neoverse-N1
@@ -306,6 +340,107 @@
- ``ERRATA_N1_1868343``: This applies errata 1868343 workaround to Neoverse-N1
CPU. This needs to be enabled only for revision <= r4p0 of the CPU.
+- ``ERRATA_N1_1946160``: This applies errata 1946160 workaround to Neoverse-N1
+ CPU. This needs to be enabled for revisions r3p0, r3p1, r4p0, and r4p1, for
+ revisions r0p0, r1p0, and r2p0 there is no workaround.
+
+For Neoverse V1, the following errata build flags are defined :
+
+- ``ERRATA_V1_1774420``: This applies errata 1774420 workaround to Neoverse-V1
+ CPU. This needs to be enabled only for revisions r0p0 and r1p0, it is fixed
+ in r1p1.
+
+- ``ERRATA_V1_1791573``: This applies errata 1791573 workaround to Neoverse-V1
+ CPU. This needs to be enabled only for revisions r0p0 and r1p0, it is fixed
+ in r1p1.
+
+- ``ERRATA_V1_1852267``: This applies errata 1852267 workaround to Neoverse-V1
+ CPU. This needs to be enabled only for revisions r0p0 and r1p0, it is fixed
+ in r1p1.
+
+- ``ERRATA_V1_1925756``: This applies errata 1925756 workaround to Neoverse-V1
+ CPU. This needs to be enabled for r0p0, r1p0, and r1p1, it is still open.
+
+- ``ERRATA_V1_1940577``: This applies errata 1940577 workaround to Neoverse-V1
+ CPU. This needs to be enabled only for revision r1p0 and r1p1 of the
+ CPU.
+
+- ``ERRATA_V1_1966096``: This applies errata 1966096 workaround to Neoverse-V1
+ CPU. This needs to be enabled for revisions r1p0 and r1p1 of the CPU, the
+ issue is present in r0p0 as well but there is no workaround for that
+ revision. It is still open.
+
+- ``ERRATA_V1_2139242``: This applies errata 2139242 workaround to Neoverse-V1
+ CPU. This needs to be enabled for revisions r0p0, r1p0, and r1p1 of the
+ CPU. It is still open.
+
+- ``ERRATA_V1_2108267``: This applies errata 2108267 workaround to Neoverse-V1
+ CPU. This needs to be enabled for revisions r0p0, r1p0, and r1p1 of the CPU.
+ It is still open.
+
+- ``ERRATA_V1_2216392``: This applies errata 2216392 workaround to Neoverse-V1
+ CPU. This needs to be enabled for revisions r1p0 and r1p1 of the CPU, the
+ issue is present in r0p0 as well but there is no workaround for that
+ revision. It is still open.
+
+For Cortex-A710, the following errata build flags are defined :
+
+- ``ERRATA_A710_1987031``: This applies errata 1987031 workaround to
+ Cortex-A710 CPU. This needs to be enabled only for revisions r0p0, r1p0 and
+ r2p0 of the CPU. It is still open.
+
+- ``ERRATA_A710_2081180``: This applies errata 2081180 workaround to
+ Cortex-A710 CPU. This needs to be enabled only for revisions r0p0, r1p0 and
+ r2p0 of the CPU. It is still open.
+
+- ``ERRATA_A710_2055002``: This applies errata 2055002 workaround to
+ Cortex-A710 CPU. This needs to be enabled for revisions r1p0, r2p0 of the CPU
+ and is still open.
+
+- ``ERRATA_A710_2017096``: This applies errata 2017096 workaround to
+ Cortex-A710 CPU. This needs to be enabled for revisions r0p0, r1p0 and r2p0
+ of the CPU and is still open.
+
+- ``ERRATA_A710_2083908``: This applies errata 2083908 workaround to
+ Cortex-A710 CPU. This needs to be enabled for revision r2p0 of the CPU and
+ is still open.
+
+- ``ERRATA_A710_2058056``: This applies errata 2058056 workaround to
+ Cortex-A710 CPU. This needs to be enabled for revisions r0p0, r1p0 and r2p0
+ of the CPU and is still open.
+
+For Neoverse N2, the following errata build flags are defined :
+
+- ``ERRATA_N2_2002655``: This applies errata 2002655 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU, it is still open.
+
+- ``ERRATA_N2_2067956``: This applies errata 2067956 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2025414``: This applies errata 2025414 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2189731``: This applies errata 2189731 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2138956``: This applies errata 2138956 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2138953``: This applies errata 2138953 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2242415``: This applies errata 2242415 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2138958``: This applies errata 2138958 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2242400``: This applies errata 2242400 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
+- ``ERRATA_N2_2280757``: This applies errata 2280757 workaround to Neoverse-N2
+ CPU. This needs to be enabled for revision r0p0 of the CPU and is still open.
+
DSU Errata Workarounds
----------------------
@@ -369,14 +504,15 @@
Cortex-A57 based platform must make its own decision on whether to use
the optimization. This flag is disabled by default.
-- ``NEOVERSE_N1_EXTERNAL_LLC``: This flag indicates that an external last
+- ``NEOVERSE_Nx_EXTERNAL_LLC``: This flag indicates that an external last
level cache(LLC) is present in the system, and that the DataSource field
on the master CHI interface indicates when data is returned from the LLC.
This is used to control how the LL_CACHE* PMU events count.
+ Default value is 0 (Disabled).
--------------
-*Copyright (c) 2014-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2014-2021, Arm Limited and Contributors. All rights reserved.*
.. _CVE-2017-5715: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
.. _CVE-2018-3639: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639
diff --git a/docs/design/firmware-design.rst b/docs/design/firmware-design.rst
index c12e73f..0831dc0 100644
--- a/docs/design/firmware-design.rst
+++ b/docs/design/firmware-design.rst
@@ -26,6 +26,13 @@
TF-A can be built to support either AArch64 or AArch32 execution state.
+.. note::
+
+ The descriptions in this chapter are for the Arm TrustZone architecture.
+ For changes to the firmware design for the
+ `Arm Confidential Compute Architecture (Arm CCA)`_ please refer to the
+ chapter :ref:`Realm Management Extension (RME)`.
+
Cold boot
---------
@@ -2616,8 +2623,6 @@
``CTX_INCLUDE_PAUTH_REGS`` to 1. This enables pointer authentication in BL1,
BL2, BL31, and the TSP if it is used.
- These options are experimental features.
-
Note that Pointer Authentication is enabled for Non-secure world irrespective
of the value of these build flags if the CPU supports it.
@@ -2629,8 +2634,7 @@
~~~~~~~~~
- Branch Target Identification feature is selected by ``BRANCH_PROTECTION``
- option set to 1. This option defaults to 0 and this is an experimental
- feature.
+ option set to 1. This option defaults to 0.
- Memory Tagging Extension feature is unconditionally enabled for both worlds
(at EL0 and S-EL0) if it is only supported at EL0. If instead it is
@@ -2725,7 +2729,7 @@
--------------
-*Copyright (c) 2013-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.*
.. _Power State Coordination Interface PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
.. _SMCCC: https://developer.arm.com/docs/den0028/latest
@@ -2734,5 +2738,6 @@
.. _Arm ARM: https://developer.arm.com/docs/ddi0487/latest
.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest
.. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT) Armv8-A (ARM DEN0006D): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a
+.. _Arm Confidential Compute Architecture (Arm CCA): https://www.arm.com/why-arm/architecture/security-features/arm-confidential-compute-architecture
.. |Image 1| image:: ../resources/diagrams/rt-svc-descs-layout.png
diff --git a/docs/design/trusted-board-boot.rst b/docs/design/trusted-board-boot.rst
index 96cf24c..46177d7 100644
--- a/docs/design/trusted-board-boot.rst
+++ b/docs/design/trusted-board-boot.rst
@@ -239,9 +239,6 @@
R060_TBBR_FUNCTION as specified in the `Trusted Board Boot Requirements (TBBR)`_
document.
-Note that due to security considerations and complexity of this feature, it is
-marked as experimental.
-
Firmware Encryption Tool
------------------------
diff --git a/docs/design_documents/index.rst b/docs/design_documents/index.rst
index 187510a..c82d2ee 100644
--- a/docs/design_documents/index.rst
+++ b/docs/design_documents/index.rst
@@ -7,6 +7,7 @@
:numbered:
cmake_framework
+ measured_boot_poc
--------------
diff --git a/docs/design_documents/measured_boot_poc.rst b/docs/design_documents/measured_boot_poc.rst
new file mode 100644
index 0000000..3ae539b
--- /dev/null
+++ b/docs/design_documents/measured_boot_poc.rst
@@ -0,0 +1,507 @@
+Interaction between Measured Boot and an fTPM (PoC)
+===================================================
+
+Measured Boot is the process of cryptographically measuring the code and
+critical data used at boot time, for example using a TPM, so that the
+security state can be attested later.
+
+The current implementation of the driver included in Trusted Firmware-A
+(TF-A) stores the measurements into a `TGC event log`_ in secure
+memory. No other means of recording measurements (such as a discrete TPM) is
+supported right now.
+
+The driver also provides mechanisms to pass the Event Log to normal world if
+needed.
+
+This manual provides instructions to build a proof of concept (PoC) with the
+sole intention of showing how Measured Boot can be used in conjunction with
+a firmware TPM (fTPM) service implemented on top of OP-TEE.
+
+.. note::
+ The instructions given in this document are meant to be used to build
+ a PoC to show how Measured Boot on TF-A can interact with a third
+ party (f)TPM service and they try to be as general as possible. Different
+ platforms might have different needs and configurations (e.g. different
+ SHA algorithms) and they might also use different types of TPM services
+ (or even a different type of service to provide the attestation)
+ and therefore the instuctions given here might not apply in such scenarios.
+
+Components
+~~~~~~~~~~
+
+The PoC is built on top of the `OP-TEE Toolkit`_, which has support to build
+TF-A with support for Measured Boot enabled (and run it on a Foundation Model)
+since commit cf56848.
+
+The aforementioned toolkit builds a set of images that contain all the components
+needed to test that the Event Log was properly created. One of these images will
+contain a third party fTPM service which in turn will be used to process the
+Event Log.
+
+The reason to choose OP-TEE Toolkit to build our PoC around it is mostly
+for convenience. As the fTPM service used is an OP-TEE TA, it was easy to add
+build support for it to the toolkit and then build the PoC around it.
+
+The most relevant components installed in the image that are closely related to
+Measured Boot/fTPM functionality are:
+
+ - **OP-TEE**: As stated earlier, the fTPM service used in this PoC is built as an
+ OP-TEE TA and therefore we need to include the OP-TEE OS image.
+ Support to interfacing with Measured Boot was added to version 3.9.0 of
+ OP-TEE by implementing the ``PTA_SYSTEM_GET_TPM_EVENT_LOG`` syscall, which
+ allows the former to pass a copy of the Event Log to any TA requesting it.
+ OP-TEE knows the location of the Event Log by reading the DTB bindings
+ received from TF-A. Visit :ref:`DTB binding for Event Log properties`
+ for more details on this.
+
+ - **fTPM Service**: We use a third party fTPM service in order to validate
+ the Measured Boot functionality. The chosen fTPM service is a sample
+ implementation for Aarch32 architecture included on the `ms-tpm-20-ref`_
+ reference implementation from Microsoft. The service was updated in order
+ to extend the Measured Boot Event Log at boot up and it uses the
+ aforementioned ``PTA_SYSTEM_GET_TPM_EVENT_LOG`` call to retrieve a copy
+ of the former.
+
+ .. note::
+ Arm does not provide an fTPM implementation. The fTPM service used here
+ is a third party one which has been updated to support Measured Boot
+ service as provided by TF-A. As such, it is beyond the scope of this
+ manual to test and verify the correctness of the output generated by the
+ fTPM service.
+
+ - **TPM Kernel module**: In order to interact with the fTPM service, we need
+ a kernel module to forward the request from user space to the secure world.
+
+ - `tpm2-tools`_: This is a set of tools that allow to interact with the
+ fTPM service. We use this in order to read the PCRs with the measurements.
+
+Building the PoC for the Arm FVP platform
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As mentioned before, this PoC is based on the OP-TEE Toolkit with some
+extensions to enable Measured Boot and an fTPM service. Therefore, we can rely
+on the instructions to build the original OP-TEE Toolkit. As a general rule,
+the following steps should suffice:
+
+(1) Start by following the `Get and build the solution`_ instructions to build
+ the OP-TEE toolkit. On step 3, you need to get the manifest for FVP
+ platform from the main branch:
+
+ .. code:: shell
+
+ $ repo init -u https://github.com/OP-TEE/manifest.git -m fvp.xml
+
+ Then proceed synching the repos as stated in step 3. Continue following
+ the instructions and stop before step 5.
+
+(2) Next you should obtain the `Armv8-A Foundation Platform (For Linux Hosts Only)`_.
+ The binary should be untar'ed to the root of the repo tree, i.e., like
+ this: ``<fvp-project>/Foundation_Platformpkg``. In the end, after cloning
+ all source code, getting the toolchains and "installing"
+ Foundation_Platformpkg, you should have a folder structure that looks like
+ this:
+
+ .. code:: shell
+
+ $ ls -la
+ total 80
+ drwxrwxr-x 20 tf-a_user tf-a_user 4096 Jul 1 12:16 .
+ drwxr-xr-x 23 tf-a_user tf-a_user 4096 Jul 1 10:40 ..
+ drwxrwxr-x 12 tf-a_user tf-a_user 4096 Jul 1 10:45 build
+ drwxrwxr-x 16 tf-a_user tf-a_user 4096 Jul 1 12:16 buildroot
+ drwxrwxr-x 51 tf-a_user tf-a_user 4096 Jul 1 10:45 edk2
+ drwxrwxr-x 6 tf-a_user tf-a_user 4096 Jul 1 12:14 edk2-platforms
+ drwxr-xr-x 7 tf-a_user tf-a_user 4096 Jul 1 10:52 Foundation_Platformpkg
+ drwxrwxr-x 17 tf-a_user tf-a_user 4096 Jul 2 10:40 grub
+ drwxrwxr-x 25 tf-a_user tf-a_user 4096 Jul 2 10:39 linux
+ drwxrwxr-x 15 tf-a_user tf-a_user 4096 Jul 1 10:45 mbedtls
+ drwxrwxr-x 6 tf-a_user tf-a_user 4096 Jul 1 10:45 ms-tpm-20-ref
+ drwxrwxr-x 8 tf-a_user tf-a_user 4096 Jul 1 10:45 optee_client
+ drwxrwxr-x 10 tf-a_user tf-a_user 4096 Jul 1 10:45 optee_examples
+ drwxrwxr-x 12 tf-a_user tf-a_user 4096 Jul 1 12:13 optee_os
+ drwxrwxr-x 8 tf-a_user tf-a_user 4096 Jul 1 10:45 optee_test
+ drwxrwxr-x 7 tf-a_user tf-a_user 4096 Jul 1 10:45 .repo
+ drwxrwxr-x 4 tf-a_user tf-a_user 4096 Jul 1 12:12 toolchains
+ drwxrwxr-x 21 tf-a_user tf-a_user 4096 Jul 1 12:15 trusted-firmware-a
+
+(3) Now enter into ``ms-tpm-20-ref`` and get its dependencies:
+
+ .. code:: shell
+
+ $ cd ms-tpm-20-ref
+ $ git submodule init
+ $ git submodule update
+ Submodule path 'external/wolfssl': checked out '9c87f979a7f1d3a6d786b260653d566c1d31a1c4'
+
+(4) Now, you should be able to continue with step 5 in "`Get and build the solution`_"
+ instructions. In order to enable support for Measured Boot, you need to
+ set the ``MEASURED_BOOT`` build option:
+
+ .. code:: shell
+
+ $ MEASURED_BOOT=y make -j `nproc`
+
+ .. note::
+ The build process will likely take a long time. It is strongly recommended to
+ pass the ``-j`` option to make to run the process faster.
+
+ After this step, you should be ready to run the image.
+
+Running and using the PoC on the Armv8-A Foundation AEM FVP
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+With everything built, you can now run the image:
+
+.. code:: shell
+
+ $ make run-only
+
+.. note::
+ Using ``make run`` will build and run the image and it can be used instead
+ of simply ``make``. However, once the image is built, it is recommended to
+ use ``make run-only`` to avoid re-running all the building rules, which
+ would take time.
+
+When FVP is launched, two terminal windows will appear. ``FVP terminal_0``
+is the userspace terminal whereas ``FVP terminal_1`` is the counterpart for
+the secure world (where TAs will print their logs, for instance).
+
+Log into the image shell with user ``root``, no password will be required.
+Then we can issue the ``ftpm`` command, which is an alias that
+
+(1) loads the ftpm kernel module and
+
+(2) calls ``tpm2_pcrread``, which will access the fTPM service to read the
+ PCRs.
+
+When loading the ftpm kernel module, the fTPM TA is loaded into the secure
+world. This TA then requests a copy of the Event Log generated during the
+booting process so it can retrieve all the entries on the log and record them
+first thing.
+
+.. note::
+ For this PoC, nothing loaded after BL33 and NT_FW_CONFIG is recorded
+ in the Event Log.
+
+The secure world terminal should show the debug logs for the fTPM service,
+including all the measurements available in the Event Log as they are being
+processed:
+
+.. code:: shell
+
+ M/TA: Preparing to extend the following TPM Event Log:
+ M/TA: TCG_EfiSpecIDEvent:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 3
+ M/TA: Digest : 00
+ M/TA: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ M/TA: : 00 00 00
+ M/TA: EventSize : 33
+ M/TA: Signature : Spec ID Event03
+ M/TA: PlatformClass : 0
+ M/TA: SpecVersion : 2.0.2
+ M/TA: UintnSize : 1
+ M/TA: NumberOfAlgorithms : 1
+ M/TA: DigestSizes :
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: DigestSize : 32
+ M/TA: VendorInfoSize : 0
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 3
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ M/TA: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ M/TA: EventSize : 17
+ M/TA: Signature : StartupLocality
+ M/TA: StartupLocality : 0
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 58 26 32 6e 64 45 64 da 45 de 35 db 96 fd ed 63
+ M/TA: : 2a 6a d4 0d aa 94 b0 b1 55 e4 72 e7 1f 0a e0 d5
+ M/TA: EventSize : 5
+ M/TA: Event : BL_2
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : cf f9 7d a3 5c 73 ac cb 7b a0 25 80 6a 6e 50 a5
+ M/TA: : 6b 2e d2 8c c9 36 92 7d 46 c5 b9 c3 a4 6c 51 7c
+ M/TA: EventSize : 6
+ M/TA: Event : BL_31
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 23 b0 a3 5d 54 d9 43 1a 5c b9 89 63 1c da 06 c2
+ M/TA: : e5 de e7 7e 99 17 52 12 7d f7 45 ca 4f 4a 39 c0
+ M/TA: EventSize : 10
+ M/TA: Event : HW_CONFIG
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 4e e4 8e 5a e6 50 ed e0 b5 a3 54 8a 1f d6 0e 8a
+ M/TA: : ea 0e 71 75 0e a4 3f 82 76 ce af cd 7c b0 91 e0
+ M/TA: EventSize : 14
+ M/TA: Event : SOC_FW_CONFIG
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 01 b0 80 47 a1 ce 86 cd df 89 d2 1f 2e fc 6c 22
+ M/TA: : f8 19 ec 6e 1e ec 73 ba 5a be d0 96 e3 5f 6d 75
+ M/TA: EventSize : 6
+ M/TA: Event : BL_32
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 5d c6 ef 35 5a 90 81 b4 37 e6 3b 52 da 92 ab 8e
+ M/TA: : d9 6e 93 98 2d 40 87 96 1b 5a a7 ee f1 f4 40 63
+ M/TA: EventSize : 18
+ M/TA: Event : BL32_EXTRA1_IMAGE
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 39 b7 13 b9 93 db 32 2f 1b 48 30 eb 2c f2 5c 25
+ M/TA: : 00 0f 38 dc 8e c8 02 cd 79 f2 48 d2 2c 25 ab e2
+ M/TA: EventSize : 6
+ M/TA: Event : BL_33
+ M/TA: PCR_Event2:
+ M/TA: PCRIndex : 0
+ M/TA: EventType : 1
+ M/TA: Digests Count : 1
+ M/TA: #0 AlgorithmId : SHA256
+ M/TA: Digest : 25 10 60 5d d4 bc 9d 82 7a 16 9f 8a cc 47 95 a6
+ M/TA: : fd ca a0 c1 2b c9 99 8f 51 20 ff c6 ed 74 68 5a
+ M/TA: EventSize : 13
+ M/TA: Event : NT_FW_CONFIG
+
+These logs correspond to the measurements stored by TF-A during the measured
+boot process and therefore, they should match the logs dumped by the former
+during the boot up process. These can be seen on the terminal_0:
+
+.. code:: shell
+
+ NOTICE: Booting Trusted Firmware
+ NOTICE: BL1: v2.5(release):v2.5
+ NOTICE: BL1: Built : 10:41:20, Jul 2 2021
+ NOTICE: BL1: Booting BL2
+ NOTICE: BL2: v2.5(release):v2.5
+ NOTICE: BL2: Built : 10:41:20, Jul 2 2021
+ NOTICE: TCG_EfiSpecIDEvent:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 3
+ NOTICE: Digest : 00
+ NOTICE: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ NOTICE: : 00 00 00
+ NOTICE: EventSize : 33
+ NOTICE: Signature : Spec ID Event03
+ NOTICE: PlatformClass : 0
+ NOTICE: SpecVersion : 2.0.2
+ NOTICE: UintnSize : 1
+ NOTICE: NumberOfAlgorithms : 1
+ NOTICE: DigestSizes :
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: DigestSize : 32
+ NOTICE: VendorInfoSize : 0
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 3
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ NOTICE: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ NOTICE: EventSize : 17
+ NOTICE: Signature : StartupLocality
+ NOTICE: StartupLocality : 0
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 58 26 32 6e 64 45 64 da 45 de 35 db 96 fd ed 63
+ NOTICE: : 2a 6a d4 0d aa 94 b0 b1 55 e4 72 e7 1f 0a e0 d5
+ NOTICE: EventSize : 5
+ NOTICE: Event : BL_2
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : cf f9 7d a3 5c 73 ac cb 7b a0 25 80 6a 6e 50 a5
+ NOTICE: : 6b 2e d2 8c c9 36 92 7d 46 c5 b9 c3 a4 6c 51 7c
+ NOTICE: EventSize : 6
+ NOTICE: Event : BL_31
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 23 b0 a3 5d 54 d9 43 1a 5c b9 89 63 1c da 06 c2
+ NOTICE: : e5 de e7 7e 99 17 52 12 7d f7 45 ca 4f 4a 39 c0
+ NOTICE: EventSize : 10
+ NOTICE: Event : HW_CONFIG
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 4e e4 8e 5a e6 50 ed e0 b5 a3 54 8a 1f d6 0e 8a
+ NOTICE: : ea 0e 71 75 0e a4 3f 82 76 ce af cd 7c b0 91 e0
+ NOTICE: EventSize : 14
+ NOTICE: Event : SOC_FW_CONFIG
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 01 b0 80 47 a1 ce 86 cd df 89 d2 1f 2e fc 6c 22
+ NOTICE: : f8 19 ec 6e 1e ec 73 ba 5a be d0 96 e3 5f 6d 75
+ NOTICE: EventSize : 6
+ NOTICE: Event : BL_32
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 5d c6 ef 35 5a 90 81 b4 37 e6 3b 52 da 92 ab 8e
+ NOTICE: : d9 6e 93 98 2d 40 87 96 1b 5a a7 ee f1 f4 40 63
+ NOTICE: EventSize : 18
+ NOTICE: Event : BL32_EXTRA1_IMAGE
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 39 b7 13 b9 93 db 32 2f 1b 48 30 eb 2c f2 5c 25
+ NOTICE: : 00 0f 38 dc 8e c8 02 cd 79 f2 48 d2 2c 25 ab e2
+ NOTICE: EventSize : 6
+ NOTICE: Event : BL_33
+ NOTICE: PCR_Event2:
+ NOTICE: PCRIndex : 0
+ NOTICE: EventType : 1
+ NOTICE: Digests Count : 1
+ NOTICE: #0 AlgorithmId : SHA256
+ NOTICE: Digest : 25 10 60 5d d4 bc 9d 82 7a 16 9f 8a cc 47 95 a6
+ NOTICE: : fd ca a0 c1 2b c9 99 8f 51 20 ff c6 ed 74 68 5a
+ NOTICE: EventSize : 13
+ NOTICE: Event : NT_FW_CONFIG
+ NOTICE: BL1: Booting BL31
+ NOTICE: BL31: v2.5(release):v2.5
+ NOTICE: BL31: Built : 10:41:20, Jul 2 2021
+
+Following up with the fTPM startup process, we can see that all the
+measurements in the Event Log are extended and recorded in the appropriate PCR:
+
+.. code:: shell
+
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: TPM2_PCR_EXTEND_COMMAND returned value:
+ M/TA: ret_tag = 0x8002, size = 0x00000013, rc = 0x00000000
+ M/TA: 9 Event logs processed
+
+After the fTPM TA is loaded, the call to ``insmod`` issued by the ``ftpm``
+alias to load the ftpm kernel module returns, and then the TPM PCRs are read
+by means of ``tpm_pcrread`` command. Note that we are only interested in the
+SHA256 logs here, as this is the algorithm we used on TF-A for the measurements
+(see the field ``AlgorithmId`` on the logs above):
+
+.. code:: shell
+
+ sha256:
+ 0 : 0xA6EB3A7417B8CFA9EBA2E7C22AD5A4C03CDB8F3FBDD7667F9C3EF2EA285A8C9F
+ 1 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 2 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 3 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 4 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 5 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 6 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 7 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 8 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 9 : 0x0000000000000000000000000000000000000000000000000000000000000000
+ 10: 0x0000000000000000000000000000000000000000000000000000000000000000
+ 11: 0x0000000000000000000000000000000000000000000000000000000000000000
+ 12: 0x0000000000000000000000000000000000000000000000000000000000000000
+ 13: 0x0000000000000000000000000000000000000000000000000000000000000000
+ 14: 0x0000000000000000000000000000000000000000000000000000000000000000
+ 15: 0x0000000000000000000000000000000000000000000000000000000000000000
+ 16: 0x0000000000000000000000000000000000000000000000000000000000000000
+ 17: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+ 18: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+ 19: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+ 20: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+ 21: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+ 22: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
+ 23: 0x0000000000000000000000000000000000000000000000000000000000000000
+
+In this PoC we are only interested in PCR0, which must be non-null. This is
+because the boot process records all the images in this PCR (see field ``PCRIndex``
+on the Event Log above). The rest of the records must be 0 at this point.
+
+.. note::
+ The fTPM service used has support only for 16 PCRs, therefore the content
+ of PCRs above 15 can be ignored.
+
+.. note::
+ As stated earlier, Arm does not provide an fTPM implementation and therefore
+ we do not validate here if the content of PCR0 is correct or not. For this
+ PoC, we are only focused on the fact that the event log could be passed to a third
+ party fTPM and its records were properly extended.
+
+Fine-tuning the fTPM TA
+~~~~~~~~~~~~~~~~~~~~~~~
+
+As stated earlier, the OP-TEE Toolkit includes support to build a third party fTPM
+service. The build options for this service are tailored for the PoC and defined in
+the build environment variable ``FTPM_FLAGS`` (see ``<toolkit_home>/build/common.mk``)
+but they can be modified if needed to better adapt it to a specific scenario.
+
+The most relevant options for Measured Boot support are:
+
+ - **CFG_TA_DEBUG**: Enables debug logs in the Terminal_1 console.
+ - **CFG_TEE_TA_LOG_LEVEL**: Defines the log level used for the debug messages.
+ - **CFG_TA_MEASURED_BOOT**: Enables support for measured boot on the fTPM.
+ - **CFG_TA_EVENT_LOG_SIZE**: Defines the size, in bytes, of the larger event log that
+ the fTPM is able to store, as this buffer is allocated at build time. This must be at
+ least the same as the size of the event log generated by TF-A. If this build option
+ is not defined, the fTPM falls back to a default value of 1024 bytes, which is enough
+ for this PoC, so this variable is not defined in FTPM_FLAGS.
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
+
+.. _OP-TEE Toolkit: https://github.com/OP-TEE/build
+.. _ms-tpm-20-ref: https://github.com/microsoft/ms-tpm-20-ref
+.. _Get and build the solution: https://optee.readthedocs.io/en/latest/building/gits/build.html#get-and-build-the-solution
+.. _Armv8-A Foundation Platform (For Linux Hosts Only): https://developer.arm.com/tools-and-software/simulation-models/fixed-virtual-platforms/arm-ecosystem-models
+.. _tpm2-tools: https://github.com/tpm2-software/tpm2-tools
+.. _TGC event log: https://trustedcomputinggroup.org/resource/tcg-efi-platform-specification/
diff --git a/docs/getting_started/build-options.rst b/docs/getting_started/build-options.rst
index 8adf4ad..7662a14 100644
--- a/docs/getting_started/build-options.rst
+++ b/docs/getting_started/build-options.rst
@@ -22,10 +22,20 @@
directory containing the SP source, relative to the ``bl32/``; the directory
is expected to contain a makefile called ``<aarch32_sp-value>.mk``.
+- ``AMU_RESTRICT_COUNTERS``: Register reads to the group 1 counters will return
+ zero at all but the highest implemented exception level. Reads from the
+ memory mapped view are unaffected by this control.
+
- ``ARCH`` : Choose the target build architecture for TF-A. It can take either
``aarch64`` or ``aarch32`` as values. By default, it is defined to
``aarch64``.
+- ``ARM_ARCH_FEATURE``: Optional Arm Architecture build option which specifies
+ one or more feature modifiers. This option has the form ``[no]feature+...``
+ and defaults to ``none``. It translates into compiler option
+ ``-march=armvX[.Y]-a+[no]feature+...``. See compiler's documentation for the
+ list of supported feature modifiers.
+
- ``ARM_ARCH_MAJOR``: The major version of Arm Architecture to target when
compiling TF-A. Its value must be numeric, and defaults to 8 . See also,
*Armv8 Architecture Extensions* and *Armv7 Architecture Extensions* in
@@ -45,6 +55,9 @@
- ``BL2_AT_EL3``: This is an optional build option that enables the use of
BL2 at EL3 execution level.
+- ``BL2_ENABLE_SP_LOAD``: Boolean option to enable loading SP packages from the
+ FIP. Automatically enabled if ``SP_LAYOUT_FILE`` is provided.
+
- ``BL2_IN_XIP_MEM``: In some use-cases BL2 will be stored in eXecute In Place
(XIP) memory, like BL1. In these use-cases, it is necessary to initialize
the RW sections in RAM, while leaving the RO sections in place. This option
@@ -107,7 +120,7 @@
| 4 | bti | N | Y |
+-------+--------------+-------+-----+
- This option defaults to 0 and this is an experimental feature.
+ This option defaults to 0.
Note that Pointer Authentication is enabled for Non-secure world
irrespective of the value of this option if the CPU supports it.
@@ -168,7 +181,7 @@
- ``CTX_INCLUDE_PAUTH_REGS``: Boolean option that, when set to 1, enables
Pointer Authentication for Secure world. This will cause the ARMv8.3-PAuth
registers to be included when saving and restoring the CPU context as
- part of world switch. Default value is 0 and this is an experimental feature.
+ part of world switch. Default value is 0.
Note that Pointer Authentication is enabled for Non-secure world irrespective
of the value of this flag if the CPU supports it.
@@ -179,12 +192,17 @@
authenticated decryption algorithm to be used to decrypt firmware/s during
boot. It accepts 2 values: ``aes_gcm`` and ``none``. The default value of
this flag is ``none`` to disable firmware decryption which is an optional
- feature as per TBBR. Also, it is an experimental feature.
+ feature as per TBBR.
- ``DISABLE_BIN_GENERATION``: Boolean option to disable the generation
of the binary image. If set to 1, then only the ELF image is built.
0 is the default.
+- ``DISABLE_MTPMU``: Boolean option to disable FEAT_MTPMU if implemented
+ (Armv8.6 onwards). Its default value is 0 to keep consistency with platforms
+ that do not implement FEAT_MTPMU. For more information on FEAT_MTPMU,
+ check the latest Arm ARM.
+
- ``DYN_DISABLE_AUTH``: Provides the capability to dynamically disable Trusted
Board Boot authentication at runtime. This option is meant to be enabled only
for development platforms. ``TRUSTED_BOARD_BOOT`` flag must be set if this
@@ -202,6 +220,14 @@
v8.2 implementations also implement an AMU and this option can be used to
enable this feature on those systems as well. Default is 0.
+- ``ENABLE_AMU_AUXILIARY_COUNTERS``: Enables support for AMU auxiliary counters
+ (also known as group 1 counters). These are implementation-defined counters,
+ and as such require additional platform configuration. Default is 0.
+
+- ``ENABLE_AMU_FCONF``: Enables configuration of the AMU through FCONF, which
+ allows platforms with auxiliary counters to describe them via the
+ ``HW_CONFIG`` device tree blob. Default is 0.
+
- ``ENABLE_ASSERTIONS``: This option controls whether or not calls to ``assert()``
are compiled out. For debug builds, this option defaults to 1, and calls to
``assert()`` are left in place. For release builds, this option defaults to 0
@@ -220,6 +246,10 @@
builds, but this behaviour can be overridden in each platform's Makefile or
in the build command line.
+- ``ENABLE_FEAT_HCX``: This option sets the bit SCR_EL3.HXEn in EL3 to allow
+ access to HCRX_EL2 (extended hypervisor control register) from EL2 as well as
+ adding HCRX_EL2 to the EL2 context save/restore operations.
+
- ``ENABLE_LTO``: Boolean option to enable Link Time Optimization (LTO)
support in GCC for TF-A. This option is currently only supported for
AArch64. Default is 0.
@@ -235,9 +265,20 @@
partitioning in EL3, however. Platform initialisation code should configure
and use partitions in EL3 as required. This option defaults to ``0``.
+- ``ENABLE_MPMM``: Boolean option to enable support for the Maximum Power
+ Mitigation Mechanism supported by certain Arm cores, which allows the SoC
+ firmware to detect and limit high activity events to assist in SoC processor
+ power domain dynamic power budgeting and limit the triggering of whole-rail
+ (i.e. clock chopping) responses to overcurrent conditions. Defaults to ``0``.
+
+- ``ENABLE_MPMM_FCONF``: Enables configuration of MPMM through FCONF, which
+ allows platforms with cores supporting MPMM to describe them via the
+ ``HW_CONFIG`` device tree blob. Default is 0.
+
- ``ENABLE_PIE``: Boolean option to enable Position Independent Executable(PIE)
support within generic code in TF-A. This option is currently only supported
- in BL2_AT_EL3, BL31, and BL32 (TSP). Default is 0.
+ in BL2_AT_EL3, BL31, and BL32 (TSP) for AARCH64 binaries, and in BL32
+ (SP_min) for AARCH32. Default is 0.
- ``ENABLE_PMF``: Boolean option to enable support for optional Performance
Measurement Framework(PMF). Default is 0.
@@ -248,12 +289,31 @@
be enabled. If ``ENABLE_PMF`` is set, the residency statistics are tracked in
software.
+- ``ENABLE_RME``: Boolean option to enable support for the ARMv9 Realm
+ Management Extension. Default value is 0. This is currently an experimental
+ feature.
+
- ``ENABLE_RUNTIME_INSTRUMENTATION``: Boolean option to enable runtime
instrumentation which injects timestamp collection points into TF-A to
allow runtime performance to be measured. Currently, only PSCI is
instrumented. Enabling this option enables the ``ENABLE_PMF`` build option
as well. Default is 0.
+- ``ENABLE_SME_FOR_NS``: Boolean option to enable Scalable Matrix Extension
+ (SME), SVE, and FPU/SIMD for the non-secure world only. These features share
+ registers so are enabled together. Using this option without
+ ENABLE_SME_FOR_SWD=1 will cause SME, SVE, and FPU/SIMD instructions in secure
+ world to trap to EL3. SME is an optional architectural feature for AArch64
+ and TF-A support is experimental. At this time, this build option cannot be
+ used on systems that have SPD=spmd/SPM_MM or ENABLE_RME, and attempting to
+ build with these options will fail. Default is 0.
+
+- ``ENABLE_SME_FOR_SWD``: Boolean option to enable the Scalable Matrix
+ Extension for secure world use along with SVE and FPU/SIMD, ENABLE_SME_FOR_NS
+ must also be set to use this. If enabling this, the secure world MUST
+ handle context switching for SME, SVE, and FPU/SIMD registers to ensure that
+ no data is leaked to non-secure world. This is experimental. Default is 0.
+
- ``ENABLE_SPE_FOR_LOWER_ELS`` : Boolean option to enable Statistical Profiling
extensions. This is an optional architectural feature for AArch64.
The default is 1 but is automatically disabled when the target architecture
@@ -262,13 +322,20 @@
- ``ENABLE_SVE_FOR_NS``: Boolean option to enable Scalable Vector Extension
(SVE) for the Non-secure world only. SVE is an optional architectural feature
for AArch64. Note that when SVE is enabled for the Non-secure world, access
- to SIMD and floating-point functionality from the Secure world is disabled.
+ to SIMD and floating-point functionality from the Secure world is disabled by
+ default and controlled with ENABLE_SVE_FOR_SWD.
This is to avoid corruption of the Non-secure world data in the Z-registers
which are aliased by the SIMD and FP registers. The build option is not
compatible with the ``CTX_INCLUDE_FPREGS`` build option, and will raise an
assert on platforms where SVE is implemented and ``ENABLE_SVE_FOR_NS`` set to
- 1. The default is 1 but is automatically disabled when the target
- architecture is AArch32.
+ 1. The default is 1 but is automatically disabled when ENABLE_SME_FOR_NS=1
+ since SME encompasses SVE. At this time, this build option cannot be used on
+ systems that have SPM_MM enabled.
+
+- ``ENABLE_SVE_FOR_SWD``: Boolean option to enable SVE for the Secure world.
+ SVE is an optional architectural feature for AArch64. Note that this option
+ requires ENABLE_SVE_FOR_NS to be enabled. The default is 0 and it is
+ automatically disabled when the target architecture is AArch32.
- ``ENABLE_STACK_PROTECTOR``: String option to enable the stack protection
checks in GCC. Allowed values are "all", "strong", "default" and "none". The
@@ -279,20 +346,18 @@
component of the option ``-fstack-protector-$ENABLE_STACK_PROTECTOR``.
- ``ENCRYPT_BL31``: Binary flag to enable encryption of BL31 firmware. This
- flag depends on ``DECRYPTION_SUPPORT`` build flag which is marked as
- experimental.
+ flag depends on ``DECRYPTION_SUPPORT`` build flag.
- ``ENCRYPT_BL32``: Binary flag to enable encryption of Secure BL32 payload.
- This flag depends on ``DECRYPTION_SUPPORT`` build flag which is marked as
- experimental.
+ This flag depends on ``DECRYPTION_SUPPORT`` build flag.
- ``ENC_KEY``: A 32-byte (256-bit) symmetric key in hex string format. It could
either be SSK or BSSK depending on ``FW_ENC_STATUS`` flag. This value depends
- on ``DECRYPTION_SUPPORT`` build flag which is marked as experimental.
+ on ``DECRYPTION_SUPPORT`` build flag.
- ``ENC_NONCE``: A 12-byte (96-bit) encryption nonce or Initialization Vector
(IV) in hex string format. This value depends on ``DECRYPTION_SUPPORT``
- build flag which is marked as experimental.
+ build flag.
- ``ERROR_DEPRECATED``: This option decides whether to treat the usage of
deprecated platform APIs, helper functions or drivers within Trusted
@@ -331,8 +396,7 @@
1: Encryption is done with Binding Secret Symmetric Key (BSSK) which is
unique per device.
- This flag depends on ``DECRYPTION_SUPPORT`` build flag which is marked as
- experimental.
+ This flag depends on ``DECRYPTION_SUPPORT`` build flag.
- ``GENERATE_COT``: Boolean flag used to build and execute the ``cert_create``
tool to create certificates as per the Chain of Trust described in
@@ -392,7 +456,7 @@
library is not supported.
- ``INVERTED_MEMMAP``: memmap tool print by default lower addresses at the
- bottom, higher addresses at the top. This buid flag can be set to '1' to
+ bottom, higher addresses at the top. This build flag can be set to '1' to
invert this behavior. Lower addresses will be printed at the top and higher
addresses at the bottom.
@@ -447,9 +511,11 @@
the build. The default value is 40 in debug builds and 20 in release builds.
- ``MEASURED_BOOT``: Boolean flag to include support for the Measured Boot
- feature. If this flag is enabled ``TRUSTED_BOARD_BOOT`` must be set.
- This option defaults to 0 and is an experimental feature in the stage of
- development.
+ feature. If this flag is enabled ``TRUSTED_BOARD_BOOT`` must be set as well
+ in order to provide trust that the code taking the measurements and recording
+ them has not been tampered with.
+
+ This option defaults to 0.
- ``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
@@ -559,10 +625,15 @@
- ``SEPARATE_NOBITS_REGION``: Setting this option to ``1`` allows the NOBITS
sections of BL31 (.bss, stacks, page tables, and coherent memory) to be
allocated in RAM discontiguous from the loaded firmware image. When set, the
- platform is expected to provide definitons for ``BL31_NOBITS_BASE`` and
+ platform is expected to provide definitions for ``BL31_NOBITS_BASE`` and
``BL31_NOBITS_LIMIT``. When the option is ``0`` (the default), NOBITS
sections are placed in RAM immediately following the loaded firmware image.
+- ``SMC_PCI_SUPPORT``: This option allows platforms to handle PCI configuration
+ access requests via a standard SMCCC defined in `DEN0115`_. When combined with
+ UEFI+ACPI this can provide a certain amount of OS forward compatibility
+ with newer platforms that aren't ECAM compliant.
+
- ``SPD``: Choose a Secure Payload Dispatcher component to be built into TF-A.
This build option is only valid if ``ARCH=aarch64``. The value should be
the path to the directory containing the SPD source, relative to
@@ -654,26 +725,25 @@
- ``ARM_IO_IN_DTB``: This flag determines whether to use IO based on the
firmware configuration framework. This will move the io_policies into a
configuration device tree, instead of static structure in the code base.
- This is currently an experimental feature.
- ``COT_DESC_IN_DTB``: This flag determines whether to create COT descriptors
at runtime using fconf. If this flag is enabled, COT descriptors are
statically captured in tb_fw_config file in the form of device tree nodes
and properties. Currently, COT descriptors used by BL2 are moved to the
device tree and COT descriptors used by BL1 are retained in the code
- base statically. This is currently an experimental feature.
+ base statically.
- ``SDEI_IN_FCONF``: This flag determines whether to configure SDEI setup in
runtime using firmware configuration framework. The platform specific SDEI
shared and private events configuration is retrieved from device tree rather
- than static C structures at compile time. This is currently an experimental
- feature and is only supported if SDEI_SUPPORT build flag is enabled.
+ than static C structures at compile time. This is only supported if
+ SDEI_SUPPORT build flag is enabled.
- ``SEC_INT_DESC_IN_FCONF``: This flag determines whether to configure Group 0
and Group1 secure interrupts using the firmware configuration framework. The
platform specific secure interrupt property descriptor is retrieved from
device tree in runtime rather than depending on static C structure at compile
- time. This is currently an experimental feature.
+ time.
- ``USE_ROMLIB``: This flag determines whether library at ROM will be used.
This feature creates a library of functions to be placed in ROM and thus
@@ -745,6 +815,21 @@
functions that wait for an arbitrary time length (udelay and mdelay). The
default value is 0.
+- ``ENABLE_TRBE_FOR_NS``: This flag is used to enable access of trace buffer
+ control registers from NS ELs, NS-EL2 or NS-EL1(when NS-EL2 is implemented
+ but unused) when FEAT_TRBE is implemented. TRBE is an optional architectural
+ feature for AArch64. The default is 0 and it is automatically disabled when
+ the target architecture is AArch32.
+
+- ``ENABLE_SYS_REG_TRACE_FOR_NS``: Boolean option to enable trace system
+ registers access from NS ELs, NS-EL2 or NS-EL1 (when NS-EL2 is implemented
+ but unused). This feature is available if trace unit such as ETMv4.x, and
+ ETE(extending ETM feature) is implemented. This flag is disabled by default.
+
+- ``ENABLE_TRF_FOR_NS``: Boolean option to enable trace filter control registers
+ access from NS ELs, NS-EL2 or NS-EL1 (when NS-EL2 is implemented but unused),
+ if FEAT_TRF is implemented. This flag is disabled by default.
+
GICv3 driver options
--------------------
@@ -760,6 +845,11 @@
GIC-600, so is safe to select even for a GIC500 implementation.
This option defaults to 0.
+- ``GICV3_SUPPORT_GIC600AE_FMU``: Add support for the Fault Management Unit
+ for GIC-600 AE. Enabling this option will introduce support to initialize
+ the FMU. Platforms should call the init function during boot to enable the
+ FMU and its safety mechanisms. This option defaults to 0.
+
- ``GICV3_IMPL_GIC600_MULTICHIP``: Selects GIC-600 variant with multichip
functionality. This option defaults to 0
@@ -830,6 +920,30 @@
# Resume execution
continue
+Firmware update options
+-----------------------
+
+- ``NR_OF_FW_BANKS``: Define the number of firmware banks. This flag is used
+ in defining the firmware update metadata structure. This flag is by default
+ set to '2'.
+
+- ``NR_OF_IMAGES_IN_FW_BANK``: Define the number of firmware images in each
+ firmware bank. Each firmware bank must have the same number of images as per
+ the `PSA FW update specification`_.
+ This flag is used in defining the firmware update metadata structure. This
+ flag is by default set to '1'.
+
+- ``PSA_FWU_SUPPORT``: Enable the firmware update mechanism as per the
+ `PSA FW update specification`_. The default value is 0, and this is an
+ experimental feature.
+ PSA firmware update implementation has some limitations, such as BL2 is
+ not part of the protocol-updatable images, if BL2 needs to be updated, then
+ it should be done through another platform-defined mechanism, and it assumes
+ that the platform's hardware supports CRC32 instructions.
+
--------------
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
+
+.. _DEN0115: https://developer.arm.com/docs/den0115/latest
+.. _PSA FW update specification: https://developer.arm.com/documentation/den0118/a/
diff --git a/docs/getting_started/image-terminology.rst b/docs/getting_started/image-terminology.rst
index 5993d6e..a90ec0b 100644
--- a/docs/getting_started/image-terminology.rst
+++ b/docs/getting_started/image-terminology.rst
@@ -92,6 +92,14 @@
abbreviated name should identify the vendor as well as the image
function. For example, ``AP_BL3_ARM_RAS``.
+Realm Monitor Management Firmware: ``RMM``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This is the Realm-EL2 firmware. It is required if
+:ref:`Realm Management Extension (RME)` feature is enabled. If a path to RMM
+image is not provided, TF-A builds Test Realm Payload (TRP) image by default
+and uses it as the RMM image.
+
SCP Boot ROM: ``SCP_BL1`` (previously ``BL0``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/getting_started/porting-guide.rst b/docs/getting_started/porting-guide.rst
index 19e26e4..92ff39f 100644
--- a/docs/getting_started/porting-guide.rst
+++ b/docs/getting_started/porting-guide.rst
@@ -116,7 +116,7 @@
by ``plat/common/aarch64/platform_mp_stack.S`` and
``plat/common/aarch64/platform_up_stack.S``.
-- **define : CACHE_WRITEBACK_GRANULE**
+- **#define : CACHE_WRITEBACK_GRANULE**
Defines the size in bits of the largest cache line across all the cache
levels in the platform.
@@ -562,15 +562,6 @@
doesn't print anything to the console. If ``PLAT_LOG_LEVEL_ASSERT`` isn't
defined, it defaults to ``LOG_LEVEL``.
-If the platform port uses the Activity Monitor Unit, the following constant
-may be defined:
-
-- **PLAT_AMU_GROUP1_COUNTERS_MASK**
- This mask reflects the set of group counters that should be enabled. The
- maximum number of group 1 counters supported by AMUv1 is 16 so the mask
- can be at most 0xffff. If the platform does not define this mask, no group 1
- counters are enabled.
-
File : plat_macros.S [mandatory]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -891,8 +882,55 @@
On success the function should return 0 and a negative error code otherwise.
-Note that this API depends on ``DECRYPTION_SUPPORT`` build flag which is
-marked as experimental.
+Note that this API depends on ``DECRYPTION_SUPPORT`` build flag.
+
+Function : plat_fwu_set_images_source() [when PSA_FWU_SUPPORT == 1]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Argument : struct fwu_metadata *metadata
+ Return : void
+
+This function is mandatory when PSA_FWU_SUPPORT is enabled.
+It provides a means to retrieve image specification (offset in
+non-volatile storage and length) of active/updated images using the passed
+FWU metadata, and update I/O policies of active/updated images using retrieved
+image specification information.
+Further I/O layer operations such as I/O open, I/O read, etc. on these
+images rely on this function call.
+
+In Arm platforms, this function is used to set an I/O policy of the FIP image,
+container of all active/updated secure and non-secure images.
+
+Function : plat_fwu_set_metadata_image_source() [when PSA_FWU_SUPPORT == 1]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Argument : unsigned int image_id, uintptr_t *dev_handle,
+ uintptr_t *image_spec
+ Return : int
+
+This function is mandatory when PSA_FWU_SUPPORT is enabled. It is
+responsible for setting up the platform I/O policy of the requested metadata
+image (either FWU_METADATA_IMAGE_ID or BKUP_FWU_METADATA_IMAGE_ID) that will
+be used to load this image from the platform's non-volatile storage.
+
+FWU metadata can not be always stored as a raw image in non-volatile storage
+to define its image specification (offset in non-volatile storage and length)
+statically in I/O policy.
+For example, the FWU metadata image is stored as a partition inside the GUID
+partition table image. Its specification is defined in the partition table
+that needs to be parsed dynamically.
+This function provides a means to retrieve such dynamic information to set
+the I/O policy of the FWU metadata image.
+Further I/O layer operations such as I/O open, I/O read, etc. on FWU metadata
+image relies on this function call.
+
+It returns '0' on success, otherwise a negative error value on error.
+Alongside, returns device handle and image specification from the I/O policy
+of the requested FWU metadata image.
Common optional modifications
-----------------------------
@@ -1151,6 +1189,25 @@
the SMCCC function specified in the argument; otherwise returns
SMC_ARCH_CALL_NOT_SUPPORTED.
+Function : plat_mboot_measure_image()
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Argument : unsigned int, image_info_t *
+ Return : void
+
+When the MEASURED_BOOT flag is enabled:
+
+- This function measures the given image and records its measurement using
+ the measured boot backend driver.
+- On the Arm FVP port, this function measures the given image using its
+ passed id and information and then records that measurement in the
+ Event Log buffer.
+- This function must return 0 on success, a negative error code otherwise.
+
+When the MEASURED_BOOT flag is disabled, this function doesn't do anything.
+
Modifications specific to a Boot Loader stage
---------------------------------------------
@@ -1402,6 +1459,42 @@
The default implementation of this function asserts therefore platforms must
override it when using the FWU feature.
+Function : bl1_plat_mboot_init() [optional]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Argument : void
+ Return : void
+
+When the MEASURED_BOOT flag is enabled:
+
+- This function is used to initialize the backend driver(s) of measured boot.
+- On the Arm FVP port, this function is used to initialize the Event Log
+ backend driver, and also to write header information in the Event Log buffer.
+
+When the MEASURED_BOOT flag is disabled, this function doesn't do anything.
+
+Function : bl1_plat_mboot_finish() [optional]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Argument : void
+ Return : void
+
+When the MEASURED_BOOT flag is enabled:
+
+- This function is used to finalize the measured boot backend driver(s),
+ and also, set the information for the next bootloader component to
+ extend the measurement if needed.
+- On the Arm FVP port, this function is used to pass the base address of
+ the Event Log buffer and its size to BL2 via tb_fw_config to extend the
+ Event Log buffer with the measurement of various images loaded by BL2.
+ It results in panic on error.
+
+When the MEASURED_BOOT flag is disabled, this function doesn't do anything.
+
Boot Loader Stage 2 (BL2)
-------------------------
@@ -1690,6 +1783,42 @@
This function returns 0 on success, a negative error code otherwise.
This function is included if SCP_BL2U_BASE is defined.
+Function : bl2_plat_mboot_init() [optional]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Argument : void
+ Return : void
+
+When the MEASURED_BOOT flag is enabled:
+
+- This function is used to initialize the backend driver(s) of measured boot.
+- On the Arm FVP port, this function is used to initialize the Event Log
+ backend driver with the Event Log buffer information (base address and
+ size) received from BL1. It results in panic on error.
+
+When the MEASURED_BOOT flag is disabled, this function doesn't do anything.
+
+Function : bl2_plat_mboot_finish() [optional]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+::
+
+ Argument : void
+ Return : void
+
+When the MEASURED_BOOT flag is enabled:
+
+- This function is used to finalize the measured boot backend driver(s),
+ and also, set the information for the next bootloader component to extend
+ the measurement if needed.
+- On the Arm FVP port, this function is used to pass the Event Log buffer
+ information (base address and size) to non-secure(BL33) and trusted OS(BL32)
+ via nt_fw and tos_fw config respectively. It results in panic on error.
+
+When the MEASURED_BOOT flag is disabled, this function doesn't do anything.
+
Boot Loader Stage 3-1 (BL31)
----------------------------
@@ -1742,9 +1871,9 @@
which is list of executable images following BL31,
arg1 - Points to load address of SOC_FW_CONFIG if present
- except in case of Arm FVP platform.
+ except in case of Arm FVP and Juno platform.
- In case of Arm FVP platform, Points to load address
+ In case of Arm FVP and Juno platform, points to load address
of FW_CONFIG.
arg2 - Points to load address of HW_CONFIG if present
@@ -2009,6 +2138,53 @@
The default implementation only prints out a warning message.
+.. _porting_guide_trng_requirements:
+
+TRNG porting requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The |TRNG| backend requires the platform to provide the following values
+and mandatory functions.
+
+Values
+......
+
+value: uuid_t plat_trng_uuid [mandatory]
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This value must be defined to the UUID of the TRNG backend that is specific to
+the hardware after ``plat_trng_setup`` function is called. This value must
+conform to the SMCCC calling convention; The most significant 32 bits of the
+UUID must not equal ``0xffffffff`` or the signed integer ``-1`` as this value in
+w0 indicates failure to get a TRNG source.
+
+Functions
+.........
+
+Function: void plat_entropy_setup(void) [mandatory]
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ Argument: none
+ Return: none
+
+This function is expected to do platform-specific initialization of any TRNG
+hardware. This may include generating a UUID from a hardware-specific seed.
+
+Function: bool plat_get_entropy(uint64_t \*out) [mandatory]
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+ Argument: uint64_t *
+ Return: bool
+ Out : when the return value is true, the entropy has been written into the
+ storage pointed to
+
+This function writes entropy into storage provided by the caller. If no entropy
+is available, it must return false and the storage must not be written.
+
Power State Coordination Interface (in BL31)
--------------------------------------------
@@ -2941,7 +3117,7 @@
--------------
-*Copyright (c) 2013-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.*
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
.. _Arm Generic Interrupt Controller version 2.0 (GICv2): http://infocenter.arm.com/help/topic/com.arm.doc.ihi0048b/index.html
diff --git a/docs/getting_started/prerequisites.rst b/docs/getting_started/prerequisites.rst
index 91ecdf3..f45193a 100644
--- a/docs/getting_started/prerequisites.rst
+++ b/docs/getting_started/prerequisites.rst
@@ -26,7 +26,7 @@
|TF-A| can be built with any of the following *cross-compiler* toolchains that
target the Armv7-A or Armv8-A architectures:
-- GCC >= 9.2-2019.12 (from the `Arm Developer website`_)
+- GCC >= 10.3-2021.07 (from the `Arm Developer website`_)
- Clang >= 4.0
- Arm Compiler >= 6.0
@@ -60,7 +60,7 @@
The following libraries are required for Trusted Board Boot support:
-- mbed TLS == 2.24.0 (tag: ``mbedtls-2.24.0``)
+- mbed TLS == 2.26.0 (tag: ``mbedtls-2.26.0``)
These tools are optional:
@@ -75,6 +75,12 @@
The standard software package used for debugging software on Arm development
platforms and |FVP| models.
+- Node.js >= 14
+
+ Highly recommended, and necessary in order to install and use the packaged
+ Git hooks and helper tools. Without these tools you will need to rely on the
+ CI for feedback on commit message conformance.
+
Package Installation (Linux)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -91,11 +97,22 @@
sudo apt install device-tree-compiler
+Additionally, to install an up-to-date version of Node.js, you can use the `Node
+Version Manager`_ to install a version of your choosing (we recommend 14, but
+later LTS versions might offer a more stable experience):
+
+.. code:: shell
+
+ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | "$SHELL"
+ exec "$SHELL" -ic "nvm install 14; exec $SHELL"
+
+.. _Node Version Manager: https://github.com/nvm-sh/nvm#install--update-script
+
Supporting Files
----------------
TF-A has been tested with pre-built binaries and file systems from `Linaro
-Release 19.06`_. Alternatively, you can build the binaries from source using
+Release 20.01`_. Alternatively, you can build the binaries from source using
instructions in :ref:`Performing an Initial Build`.
.. _prerequisites_get_source:
@@ -109,28 +126,44 @@
.. code:: shell
- git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a" && (cd "trusted-firmware-a" && mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://review.trustedfirmware.org/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg)
+ git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a"
-This will clone the Git repository also install a *commit hook* that
-automatically inserts appropriate *Change-Id:* lines at the end of your
-commit messages. These change IDs are required when committing changes that you
-intend to push for review via our Gerrit system.
+Additional Steps for Contributors
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-You can read more about Git hooks in the *githooks* page of the Git documentation,
-available at: https://git-scm.com/docs/githooks
+If you are planning on contributing back to TF-A, there are some things you'll
+want to know.
-Alternatively, you can clone without the commit hook using:
+TF-A is hosted by a `Gerrit Code Review`_ server. Gerrit requires that all
+commits include a ``Change-Id`` footer, and this footer is typically
+automatically generated by a Git hook installed by you, the developer.
+
+If you have Node.js installed already, you can automatically install this hook,
+along with any additional hooks and Javascript-based tooling that we use, by
+running from within your newly-cloned repository:
.. code:: shell
- git clone "https://review.trustedfirmware.org/TF-A/trusted-firmware-a"
+ npm install --no-save
+
+If you have opted **not** to install Node.js, you can install the Gerrit hook
+manually by running:
+
+.. code:: shell
+
+ curl -Lo $(git rev-parse --git-dir)/hooks/commit-msg https://review.trustedfirmware.org/tools/hooks/commit-msg
+ chmod +x $(git rev-parse --git-dir)/hooks/commit-msg
+
+You can read more about Git hooks in the *githooks* page of the Git
+documentation, available `here <https://git-scm.com/docs/githooks>`_.
--------------
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
.. _Arm Developer website: https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
+.. _Gerrit Code Review: https://www.gerritcodereview.com/
.. _Linaro Release Notes: https://community.arm.com/dev-platforms/w/docs/226/old-release-notes
.. _Linaro instructions: https://community.arm.com/dev-platforms/w/docs/304/arm-reference-platforms-deliverables
.. _Development Studio 5 (DS-5): https://developer.arm.com/products/software-development-tools/ds-5-development-studio
-.. _Linaro Release 19.06: http://releases.linaro.org/members/arm/platforms/19.06
+.. _Linaro Release 20.01: http://releases.linaro.org/members/arm/platforms/20.01
diff --git a/docs/getting_started/rt-svc-writers-guide.rst b/docs/getting_started/rt-svc-writers-guide.rst
index b3758b8..5a4be4d 100644
--- a/docs/getting_started/rt-svc-writers-guide.rst
+++ b/docs/getting_started/rt-svc-writers-guide.rst
@@ -200,13 +200,13 @@
SMC_RET1(handle, SMC_UNK);
#. Determining if the requested function is valid for the calling security
- state. SMC Calls can be made from both the normal and trusted worlds and
+ state. SMC Calls can be made from Non-secure, Secure or Realm worlds and
the framework will forward all calls to the service handler.
The ``flags`` parameter to this function indicates the caller security state
- in bit[0], where a value of ``1`` indicates a non-secure caller. The
- ``is_caller_secure(flags)`` and ``is_caller_non_secure(flags)`` can be used to
- test this condition.
+ in bits 0 and 5. The ``is_caller_secure(flags)``, ``is_caller_non_secure(flags)``
+ and ``is_caller_realm(flags)`` helper functions can be used to determine whether
+ the caller's security state is Secure, Non-secure or Realm respectively.
If invalid, the request should be completed with:
@@ -314,7 +314,7 @@
--------------
-*Copyright (c) 2014-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2014-2021, Arm Limited and Contributors. All rights reserved.*
.. _SMCCC: https://developer.arm.com/docs/den0028/latest
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
diff --git a/docs/global_substitutions.txt b/docs/global_substitutions.txt
index d33155b..af15146 100644
--- a/docs/global_substitutions.txt
+++ b/docs/global_substitutions.txt
@@ -1,5 +1,7 @@
.. |AArch32| replace:: :term:`AArch32`
.. |AArch64| replace:: :term:`AArch64`
+.. |AMU| replace:: :term:`AMU`
+.. |AMUs| replace:: :term:`AMUs <AMU>`
.. |API| replace:: :term:`API`
.. |BTI| replace:: :term:`BTI`
.. |CoT| replace:: :term:`CoT`
@@ -23,6 +25,7 @@
.. |Linaro| replace:: :term:`Linaro`
.. |MMU| replace:: :term:`MMU`
.. |MPAM| replace:: :term:`MPAM`
+.. |MPMM| replace:: :term:`MPMM`
.. |MPIDR| replace:: :term:`MPIDR`
.. |MTE| replace:: :term:`MTE`
.. |OEN| replace:: :term:`OEN`
@@ -56,6 +59,7 @@
.. |TF-M| replace:: :term:`TF-M`
.. |TLB| replace:: :term:`TLB`
.. |TLK| replace:: :term:`TLK`
+.. |TRNG| replace:: :term:`TRNG`
.. |TSP| replace:: :term:`TSP`
.. |TZC| replace:: :term:`TZC`
.. |UBSAN| replace:: :term:`UBSAN`
diff --git a/docs/glossary.rst b/docs/glossary.rst
index 08add3a..aeeb133 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -15,6 +15,10 @@
AArch64
64-bit execution state of the ARMv8 ISA
+ AMU
+ Activity Monitor Unit, a hardware monitoring unit introduced by FEAT_AMUv1
+ that exposes CPU core runtime metrics as a set of counter registers.
+
API
Application Programming Interface
@@ -60,8 +64,8 @@
FDT
Flattened Device Tree
- FFA
- Firmware Framework for A-class processors
+ FF-A
+ Firmware Framework for Arm A-profile
FIP
Firmware Image Package
@@ -88,6 +92,10 @@
MPAM
Memory Partitioning And Monitoring. An optional Armv8.4 extension.
+ MPMM
+ Maximum Power Mitigation Mechanism, an optional power management mechanism
+ supported by some Arm Armv9-A cores.
+
MPIDR
Multiprocessor Affinity Register
@@ -193,6 +201,9 @@
TLK
Trusted Little Kernel. A Trusted OS from NVIDIA.
+ TRNG
+ True Randon Number Generator (hardware based)
+
TSP
Test Secure Payload
diff --git a/docs/index.rst b/docs/index.rst
index cb53127..edc2535 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -15,8 +15,8 @@
perf/index
security_advisories/index
design_documents/index
+ threat_model/index
change-log
- change-log-upcoming
glossary
license
@@ -30,6 +30,7 @@
- `SMC Calling Convention`_
- `System Control and Management Interface (SCMI)`_
- `Software Delegated Exception Interface (SDEI)`_
+- `PSA FW update specification`_
Where possible, the code is designed for reuse or porting to other Armv7-A and
Armv8-A model and hardware platforms.
@@ -83,7 +84,7 @@
--------------
-*Copyright (c) 2013-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.*
.. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile
.. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
@@ -92,3 +93,4 @@
.. _System Control and Management Interface (SCMI): http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf
.. _Software Delegated Exception Interface (SDEI): http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest
+.. _PSA FW update specification: https://developer.arm.com/documentation/den0118/a/
diff --git a/docs/license.rst b/docs/license.rst
index 2f97043..80f1118 100644
--- a/docs/license.rst
+++ b/docs/license.rst
@@ -76,5 +76,15 @@
BSD-3-Clause license. Any contributions to this code must be made under the
terms of both licenses.
+- Some source files originating from the Linux source tree, which are
+ disjunctively dual licensed (GPL-2.0 OR MIT), are redistributed under the
+ terms of the MIT license. These files are:
+
+ - ``include/dt-bindings/interrupt-controller/arm-gic.h``
+ - ``include/dt-bindings/interrupt-controller/irq.h``
+
+ See the original `Linux MIT license`_.
+
.. _FreeBSD: http://www.freebsd.org
+.. _Linux MIT license: https://raw.githubusercontent.com/torvalds/linux/master/LICENSES/preferred/MIT
.. _SCC: http://www.simple-cc.org/
diff --git a/docs/plat/allwinner.rst b/docs/plat/allwinner.rst
index d82380d..b696989 100644
--- a/docs/plat/allwinner.rst
+++ b/docs/plat/allwinner.rst
@@ -5,22 +5,8 @@
SoCs with ARMv8 cores. Only BL31 is used to provide proper EL3 setup and
PSCI runtime services.
-U-Boot's SPL acts as a loader, loading both BL31 and BL33 (typically U-Boot).
-Loading is done from SD card, eMMC or SPI flash, also via an USB debug
-interface (FEL).
-
-BL31 lives in SRAM A2, which is documented to be accessible from secure
-world only.
-
-Current limitations:
-
-- Missing PMIC support
-
-After building bl31.bin, the binary must be fed to the U-Boot build system
-to include it in the FIT image that the SPL loader will process.
-bl31.bin can be either copied (or sym-linked) into U-Boot's root directory,
-or the environment variable BL31 must contain the binary's path.
-See the respective `U-Boot documentation`_ for more details.
+Building TF-A
+-------------
To build for machines with an A64 or H5 SoC:
@@ -34,8 +20,75 @@
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h6 DEBUG=1 bl31
+To build for machines with an H616 or H313 SoC:
+
+.. code:: shell
+
+ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=sun50i_h616 DEBUG=1 bl31
+
+
+Installation
+------------
+
+U-Boot's SPL acts as a loader, loading both BL31 and BL33 (typically U-Boot).
+Loading is done from SD card, eMMC or SPI flash, also via an USB debug
+interface (FEL).
+
+After building bl31.bin, the binary must be fed to the U-Boot build system
+to include it in the FIT image that the SPL loader will process.
+bl31.bin can be either copied (or sym-linked) into U-Boot's root directory,
+or the environment variable BL31 must contain the binary's path.
+See the respective `U-Boot documentation`_ for more details.
+
.. _U-Boot documentation: https://gitlab.denx.de/u-boot/u-boot/-/blob/master/board/sunxi/README.sunxi64
+Memory layout
+-------------
+
+A64, H5 and H6 SoCs
+~~~~~~~~~~~~~~~~~~~
+
+BL31 lives in SRAM A2, which is documented to be accessible from secure
+world only. Since this SRAM region is very limited (48 KB), we take
+several measures to reduce memory consumption. One of them is to confine
+BL31 to only 28 bits of virtual address space, which reduces the number
+of required page tables (each occupying 4KB of memory).
+The mapping we use on those SoCs is as follows:
+
+::
+
+ 0 64K 16M 1GB 1G+160M physical address
+ +-+------+-+---+------+--...---+-------+----+------+----------
+ |B| |S|///| |//...///| |////| |
+ |R| SRAM |C|///| dev |//...///| (sec) |////| BL33 | DRAM ...
+ |O| |P|///| MMIO |//...///| DRAM |////| |
+ |M| | |///| |//...///| (32M) |////| |
+ +-+------+-+---+------+--...---+-------+----+------+----------
+ | | | | | | / / / /
+ | | | | | | / / / /
+ | | | | | | / / / /
+ | | | | | | / // /
+ | | | | | | / / /
+ +-+------+-+---+------+--+-------+------+
+ |B| |S|///| |//| | |
+ |R| SRAM |C|///| dev |//| sec | BL33 |
+ |O| |P|///| MMIO |//| DRAM | |
+ |M| | |///| |//| | |
+ +-+------+-+---+------+--+-------+------+
+ 0 64K 16M 160M 192M 256M virtual address
+
+
+H616 SoC
+~~~~~~~~
+
+The H616 lacks the secure SRAM region present on the other SoCs, also
+lacks the "ARISC" management processor (SCP) we use. BL31 thus needs to
+run from DRAM, which prevents our compressed virtual memory map described
+above. Since running in DRAM also lifts the restriction of the limited
+SRAM size, we use the normal 1:1 mapping with 32 bits worth of virtual
+address space. So the virtual addresses used in BL31 match the physical
+addresses as presented above.
+
Trusted OS dispatcher
---------------------
diff --git a/docs/plat/arm/arm-build-options.rst b/docs/plat/arm/arm-build-options.rst
index 2e50068..339ebbe 100644
--- a/docs/plat/arm/arm-build-options.rst
+++ b/docs/plat/arm/arm-build-options.rst
@@ -91,9 +91,33 @@
platforms. If this option is specified, then the path to the CryptoCell
SBROM library must be specified via ``CCSBROM_LIB_PATH`` flag.
+- ``ARM_ETHOSN_NPU_DRIVER``: boolean option to enable a SiP service that can
+ configure an Arm Ethos-N NPU. To use this service the target platform's
+ ``HW_CONFIG`` must include the device tree nodes for the NPU. Currently, only
+ the Arm Juno platform has this included in its ``HW_CONFIG`` and the platform
+ only loads the ``HW_CONFIG`` in AArch64 builds. Default is 0.
+
- ``ARM_SPMC_MANIFEST_DTS`` : path to an alternate manifest file used as the
SPMC Core manifest. Valid when ``SPD=spmd`` is selected.
+- ``ARM_BL2_SP_LIST_DTS``: Path to DTS file snippet to override the hardcoded
+ SP nodes in tb_fw_config.
+
+- ``OPTEE_SP_FW_CONFIG``: DTC build flag to include OP-TEE as SP in tb_fw_config
+ device tree. This flag is defined only when ``ARM_SPMC_MANIFEST_DTS`` manifest
+ file name contains pattern optee_sp.
+
+- ``TS_SP_FW_CONFIG``: DTC build flag to include Trusted Services (Crypto and
+ internal-trusted-storage) as SP in tb_fw_config device tree.
+
+- ``ARM_GPT_SUPPORT``: Enable GPT parser to get the entry address and length of
+ the various partitions present in the GPT image. This support is available
+ only for the BL2 component, and it is disabled by default.
+ The following diagram shows the view of the FIP partition inside the GPT
+ image:
+
+ |FIP in a GPT image|
+
For a better understanding of these options, the Arm development platform memory
map is explained in the :ref:`Firmware Design`.
@@ -122,6 +146,14 @@
valid value greater than 1, the platform code performs required configuration
to support multi-chip operation.
+- ``CSS_SGI_PLATFORM_VARIANT``: Selects the variant of a SGI/RD platform. A
+ particular SGI/RD platform may have multiple variants which may differ in
+ core count, cluster count or other peripherals. This build option is used
+ to select the appropriate platform variant for the build. The range of
+ valid values is platform specific.
+
--------------
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
+.. |FIP in a GPT image| image:: ../../resources/diagrams/FIP_in_a_GPT_image.png
+
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
diff --git a/docs/plat/arm/diphda/index.rst b/docs/plat/arm/diphda/index.rst
new file mode 100644
index 0000000..27afda4
--- /dev/null
+++ b/docs/plat/arm/diphda/index.rst
@@ -0,0 +1,61 @@
+Diphda Platform
+==========================
+
+Some of the features of the Diphda platform referenced in TF-A include:
+
+- Cortex-A35 application processor (64-bit mode)
+- Secure Enclave
+- GIC-400
+- Trusted Board Boot
+
+Boot Sequence
+-------------
+
+The board boot relies on CoT (chain of trust). The trusted-firmware-a
+BL2 is extracted from the FIP and verified by the Secure Enclave
+processor. BL2 verification relies on the signature area at the
+beginning of the BL2 image. This area is needed by the SecureEnclave
+bootloader.
+
+Then, the application processor is released from reset and starts by
+executing BL2.
+
+BL2 performs the actions described in the trusted-firmware-a TBB design
+document.
+
+Build Procedure (TF-A only)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Obtain AArch64 ELF bare-metal target `toolchain <https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads>`_.
+ Set the CROSS_COMPILE environment variable to point to the toolchain folder.
+
+- Build TF-A:
+
+ .. code:: shell
+
+ make LD=aarch64-none-elf-ld \
+ CC=aarch64-none-elf-gcc \
+ V=1 \
+ BUILD_BASE=<path to the build folder> \
+ PLAT=diphda \
+ SPD=spmd \
+ SPMD_SPM_AT_SEL2=0 \
+ DEBUG=1 \
+ MBEDTLS_DIR=mbedtls \
+ OPENSSL_DIR=<path to openssl usr folder> \
+ RUNTIME_SYSROOT=<path to the sysroot> \
+ ARCH=aarch64 \
+ TARGET_PLATFORM=<fpga or fvp> \
+ ENABLE_PIE=1 \
+ BL2_AT_EL3=1 \
+ CREATE_KEYS=1 \
+ GENERATE_COT=1 \
+ TRUSTED_BOARD_BOOT=1 \
+ COT=tbbr \
+ ARM_ROTPK_LOCATION=devel_rsa \
+ ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem \
+ BL32=<path to optee binary> \
+ BL33=<path to u-boot binary> \
+ bl2
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
diff --git a/docs/plat/arm/fvp/index.rst b/docs/plat/arm/fvp/index.rst
index 3a13268..2aaf195 100644
--- a/docs/plat/arm/fvp/index.rst
+++ b/docs/plat/arm/fvp/index.rst
@@ -12,46 +12,50 @@
(64-bit host machine only).
.. note::
- The FVP models used are Version 11.12 Build 38, unless otherwise stated.
+ The FVP models used are Version 11.16 Build 16, unless otherwise stated.
-- ``FVP_Base_AEMvA``
-- ``FVP_Base_AEMv8A-AEMv8A``
+- ``Foundation_Platform``
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
-- ``FVP_Base_RevC-2xAEMv8A``
-- ``FVP_Base_Cortex-A32x4``
+- ``FVP_Base_AEMv8A-AEMv8A`` (For certain configurations also uses 11.14/21)
+- ``FVP_Base_AEMv8A-GIC600AE``
+- ``FVP_Base_AEMvA`` (For certain configurations also uses 0.0/6684)
+- ``FVP_Base_Cortex-A32x4`` (Version 11.12/38)
- ``FVP_Base_Cortex-A35x4``
- ``FVP_Base_Cortex-A53x4``
-- ``FVP_Base_Cortex-A55x4+Cortex-A75x4``
- ``FVP_Base_Cortex-A55x4``
+- ``FVP_Base_Cortex-A55x4+Cortex-A75x4``
- ``FVP_Base_Cortex-A57x1-A53x1``
- ``FVP_Base_Cortex-A57x2-A53x4``
- ``FVP_Base_Cortex-A57x4-A53x4``
- ``FVP_Base_Cortex-A57x4``
-- ``FVP_Base_Cortex-A65x4``
- ``FVP_Base_Cortex-A65AEx8``
+- ``FVP_Base_Cortex-A65x4``
+- ``FVP_Base_Cortex-A710x4``
- ``FVP_Base_Cortex-A72x4-A53x4``
- ``FVP_Base_Cortex-A72x4``
- ``FVP_Base_Cortex-A73x4-A53x4``
- ``FVP_Base_Cortex-A73x4``
- ``FVP_Base_Cortex-A75x4``
-- ``FVP_Base_Cortex-A76x4``
- ``FVP_Base_Cortex-A76AEx4``
- ``FVP_Base_Cortex-A76AEx8``
+- ``FVP_Base_Cortex-A76x4``
- ``FVP_Base_Cortex-A77x4``
- ``FVP_Base_Cortex-A78x4``
- ``FVP_Base_Neoverse-E1x1``
- ``FVP_Base_Neoverse-E1x2``
- ``FVP_Base_Neoverse-E1x4``
- ``FVP_Base_Neoverse-N1x4``
+- ``FVP_Base_Neoverse-N2x4`` (Version 11.12 build 38)
- ``FVP_Base_Neoverse-V1x4``
-- ``FVP_CSS_SGI-575`` (Version 11.10 build 36)
-- ``FVP_CSS_SGM-775``
-- ``FVP_RD_E1_edge`` (Version 11.9 build 41)
-- ``FVP_RD_N1_edge`` (Version 11.10 build 36)
-- ``FVP_RD_N1_edge_dual`` (Version 11.10 build 36)
-- ``FVP_RD_Daniel`` (Version 11.10 build 36)
-- ``FVP_TC0`` (Version 0.0 build 6114)
-- ``Foundation_Platform``
+- ``FVP_Base_RevC-2xAEMvA`` (For certain configurations also uses 0.0/6557)
+- ``FVP_CSS_SGI-575`` (Version 11.15/26)
+- ``FVP_Morello`` (Version 0.11/19)
+- ``FVP_RD_E1_edge`` (Version 11.15/26)
+- ``FVP_RD_N1_edge_dual`` (Version 11.15/26)
+- ``FVP_RD_N1_edge`` (Version 11.15/26)
+- ``FVP_RD_V1`` (Version 11.15/26)
+- ``FVP_TC0``
+- ``FVP_TC1``
The latest version of the AArch32 build of TF-A has been tested on the
following Arm FVPs without shifted affinities, and that do not support threaded
@@ -96,7 +100,7 @@
the models. The models can be launched with ``-Q 100`` option if they are
required to match the run time characteristics of the older versions.
-All the above platforms have been tested with `Linaro Release 19.06`_.
+All the above platforms have been tested with `Linaro Release 20.01`_.
.. _build_options_arm_fvp_platform:
@@ -141,6 +145,11 @@
HW_CONFIG blob instead of the DTS file. This option is useful to override
the default HW_CONFIG selected by the build system.
+- ``FVP_GICR_REGION_PROTECTION``: Mark the redistributor pages of
+ inactive/fused CPU cores as read-only. The default value of this option
+ is ``0``, which means the redistributor pages of all CPU cores are marked
+ as read and write.
+
Booting Firmware Update images
------------------------------
@@ -516,8 +525,8 @@
Notes:
-- If Position Independent Executable (PIE) support is enabled for BL31
- in this config, it can be loaded at any valid address for execution.
+- Position Independent Executable (PIE) support is enabled in this
+ config allowing BL31 to be loaded at any valid address for execution.
- Since a FIP is not loaded when using BL31 as reset entrypoint, the
``--data="<path-to><bl31|bl32|bl33-binary>"@<base-address-of-binary>``
@@ -578,8 +587,8 @@
--data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000
.. note::
- The load address of ``<bl32-binary>`` depends on the value ``BL32_BASE``.
- It should match the address programmed into the RVBAR register as well.
+ Position Independent Executable (PIE) support is enabled in this
+ config allowing SP_MIN to be loaded at any valid address for execution.
Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -634,10 +643,10 @@
--------------
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
.. _TB_FW_CONFIG for FVP: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts
.. _Arm's website: `FVP models`_
.. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-platforms
-.. _Linaro Release 19.06: http://releases.linaro.org/members/arm/platforms/19.06
+.. _Linaro Release 20.01: http://releases.linaro.org/members/arm/platforms/20.01
.. _Arm FVP website: https://developer.arm.com/products/system-design/fixed-virtual-platforms
diff --git a/docs/plat/arm/fvp_r/index.rst b/docs/plat/arm/fvp_r/index.rst
new file mode 100644
index 0000000..8af16ba
--- /dev/null
+++ b/docs/plat/arm/fvp_r/index.rst
@@ -0,0 +1,46 @@
+ARM V8-R64 Fixed Virtual Platform (FVP)
+=======================================
+
+Some of the features of Armv8-R AArch64 FVP platform referenced in Trusted
+Boot R-class include:
+
+- Secure World Support Only
+- EL2 as Maximum EL support (No EL3)
+- MPU Support only at EL2
+- MPU or MMU Support at EL0/EL1
+- AArch64 Support Only
+- Trusted Board Boot
+
+Further information on v8-R64 FVP is available at `info <https://developer.arm.com/documentation/ddi0600/latest/>`_
+
+Boot Sequence
+-------------
+
+BL1 –> BL33
+
+The execution begins from BL1 which loads the BL33 image, a boot-wrapped (bootloader + Operating System)
+Operating System, from FIP to DRAM.
+
+Build Procedure
+~~~~~~~~~~~~~~~
+
+- Obtain arm `toolchain <https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads>`_.
+ Set the CROSS_COMPILE environment variable to point to the toolchain folder.
+
+- Build TF-A:
+
+ .. code:: shell
+
+ make PLAT=fvp_r BL33=<path_to_os.bin> all fip
+
+ Enable TBBR by adding the following options to the make command:
+
+ .. code:: shell
+
+ MBEDTLS_DIR=<path_to_mbedtls_directory> \
+ TRUSTED_BOARD_BOOT=1 \
+ GENERATE_COT=1 \
+ ARM_ROTPK_LOCATION=devel_rsa \
+ ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
diff --git a/docs/plat/arm/index.rst b/docs/plat/arm/index.rst
index f72992b..f262dc0 100644
--- a/docs/plat/arm/index.rst
+++ b/docs/plat/arm/index.rst
@@ -7,11 +7,13 @@
juno/index
fvp/index
+ fvp_r/index
fvp-ve/index
- tc0/index
+ tc/index
arm_fpga/index
arm-build-options
morello/index
+ diphda/index
This chapter holds documentation related to Arm's development platforms,
including both software models (FVPs) and hardware development boards
@@ -19,4 +21,4 @@
--------------
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
diff --git a/docs/plat/arm/juno/index.rst b/docs/plat/arm/juno/index.rst
index cf328fa..8b9d453 100644
--- a/docs/plat/arm/juno/index.rst
+++ b/docs/plat/arm/juno/index.rst
@@ -12,24 +12,21 @@
This version of TF-A has been tested on variants r0, r1 and r2 of Juno.
-To execute the software stack on Juno, the version of the Juno board recovery
-image indicated in the `Linaro Release Notes`_ must be installed. If you have an
-earlier version installed or are unsure which version is installed, please
-re-install the recovery image by following the
-`Instructions for using Linaro's deliverables on Juno`_.
+To run TF-A on Juno, you need to first prepare an SD card with Juno software
+stack that includes TF-A. This version of TF-A is tested with pre-built
+`Linaro release software stack`_ version 20.01. You can alternatively
+build the software stack yourself by following the
+`Juno platform software user guide`_. Once you prepare the software stack
+on an SD card, you can replace the ``bl1.bin`` and ``fip.bin``
+binaries in the ``SOFTWARE/`` directory with custom built TF-A binaries.
Preparing TF-A images
---------------------
-After building TF-A, the files ``bl1.bin`` and ``fip.bin`` need copying to the
-``SOFTWARE/`` directory of the Juno SD card.
-
-Creating a Firmware Image Package (FIP)
----------------------------------------
-
This section provides Juno and FVP specific instructions to build Trusted
Firmware, obtain the additional required firmware, and pack it all together in
-a single FIP binary. It assumes that a Linaro release has been installed.
+a single FIP binary. It assumes that a Linaro release software stack has been
+installed.
.. note::
Pre-built binaries for AArch32 are available from Linaro Release 16.12
@@ -57,9 +54,16 @@
make realclean
-#. Obtain SCP_BL2 (Juno) and BL33 (all platforms)
+#. Obtain SCP binaries (Juno)
- Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP
+ This version of TF-A is tested with SCP version 2.8.0 on Juno. You can
+ download pre-built SCP binaries (``scp_bl1.bin`` and ``scp_bl2.bin``)
+ from `TF-A downloads page`_. Alternatively, you can `build
+ the binaries from source`_.
+
+#. Obtain BL33 (all platforms)
+
+ Use the fiptool to extract the BL33 image from the FIP
package included in the Linaro release:
.. code:: shell
@@ -71,8 +75,7 @@
./tools/fiptool/fiptool unpack <path-to-linaro-release>/[SOFTWARE]/fip.bin
The unpack operation will result in a set of binary images extracted to the
- current working directory. The SCP_BL2 image corresponds to
- ``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``.
+ current working directory. BL33 corresponds to ``nt-fw.bin``.
.. note::
The fiptool will complain if the images to be unpacked already
@@ -102,7 +105,7 @@
.. code:: shell
- make PLAT=juno BL33=nt-fw.bin SCP_BL2=scp-fw.bin all fip
+ make PLAT=juno BL33=nt-fw.bin SCP_BL2=scp_bl2.bin all fip
For AArch32:
@@ -144,7 +147,7 @@
.. code:: shell
make ARCH=aarch64 PLAT=juno JUNO_AARCH32_EL3_RUNTIME=1 \
- BL33=nt-fw.bin SCP_BL2=scp-fw.bin \
+ BL33=nt-fw.bin SCP_BL2=scp_bl2.bin \
BL32=<path-to-temporary>/bl32.bin all fip
The resulting BL1 and FIP images may be found in:
@@ -159,6 +162,8 @@
./build/fvp/release/bl1.bin
./build/fvp/release/fip.bin
+After building TF-A, the files ``bl1.bin``, ``fip.bin`` and ``scp_bl1.bin``
+need to be copied to the ``SOFTWARE/`` directory on the Juno SD card.
Booting Firmware Update images
------------------------------
@@ -236,10 +241,12 @@
--------------
-*Copyright (c) 2019, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
-.. _Linaro Release Notes: https://community.arm.com/dev-platforms/w/docs/226/old-release-notes
-.. _Instructions for using Linaro's deliverables on Juno: https://community.arm.com/dev-platforms/w/docs/303/juno
+.. _Linaro release software stack: http://releases.linaro.org/members/arm/platforms/
+.. _Juno platform software user guide: https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.git/about/docs/juno/user-guide.rst
+.. _TF-A downloads page: https://downloads.trustedfirmware.org/tf-a/css_scp_2.8.0/juno/
+.. _build the binaries from source: https://github.com/ARM-software/SCP-firmware/blob/master/user_guide.md#scp-firmware-user-guide
.. _Arm Platforms Portal: https://community.arm.com/dev-platforms/
.. _Juno Getting Started Guide: http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/DUI0928E_juno_arm_development_platform_gsg.pdf
.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf
diff --git a/docs/plat/arm/tc/index.rst b/docs/plat/arm/tc/index.rst
new file mode 100644
index 0000000..20d3e56
--- /dev/null
+++ b/docs/plat/arm/tc/index.rst
@@ -0,0 +1,56 @@
+TC Total Compute Platform
+==========================
+
+Some of the features of TC platform referenced in TF-A include:
+
+- A `System Control Processor <https://github.com/ARM-software/SCP-firmware>`_
+ to abstract power and system management tasks away from application
+ processors. The RAM firmware for SCP is included in the TF-A FIP and is
+ loaded by AP BL2 from FIP in flash to SRAM for copying by SCP (SCP has access
+ to AP SRAM).
+- GICv4
+- Trusted Board Boot
+- SCMI
+- MHUv2
+
+Currently, the main difference between TC0 (TARGET_PLATFORM=0) and TC1
+(TARGET_PLATFORM=1) platforms w.r.t to TF-A is the CPUs supported. TC0 has
+support for Cortex A510, Cortex A710 and Cortex X2, while TC1 has support for
+Cortex A510, Cortex Makalu and Cortex Makalu ELP Arm CPUs.
+
+
+Boot Sequence
+-------------
+
+The execution begins from SCP_BL1. SCP_BL1 powers up the AP which starts
+executing AP_BL1 and then executes AP_BL2 which loads the SCP_BL2 from
+FIP to SRAM. The SCP has access to AP SRAM. The address and size of SCP_BL2
+is communicated to SCP using SDS. SCP copies SCP_BL2 from SRAM to its own
+RAM and starts executing it. The AP then continues executing the rest of TF-A
+stages including BL31 runtime stage and hands off executing to
+Non-secure world (u-boot).
+
+Build Procedure (TF-A only)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Obtain arm `toolchain <https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads>`_.
+ Set the CROSS_COMPILE environment variable to point to the toolchain folder.
+
+- Build TF-A:
+
+ .. code:: shell
+
+ make PLAT=tc BL33=<path_to_uboot.bin> \
+ SCP_BL2=<path_to_scp_ramfw.bin> TARGET_PLATFORM={0,1} all fip
+
+ Enable TBBR by adding the following options to the make command:
+
+ .. code:: shell
+
+ MBEDTLS_DIR=<path_to_mbedtls_directory> \
+ TRUSTED_BOARD_BOOT=1 \
+ GENERATE_COT=1 \
+ ARM_ROTPK_LOCATION=devel_rsa \
+ ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem
+
+*Copyright (c) 2020-2021, Arm Limited. All rights reserved.*
diff --git a/docs/plat/arm/tc0/index.rst b/docs/plat/arm/tc0/index.rst
deleted file mode 100644
index 34d1f13..0000000
--- a/docs/plat/arm/tc0/index.rst
+++ /dev/null
@@ -1,50 +0,0 @@
-TC0 Total Compute Platform
-==========================
-
-Some of the features of TC0 platform referenced in TF-A include:
-
-- A `System Control Processor <https://github.com/ARM-software/SCP-firmware>`_
- to abstract power and system management tasks away from application
- processors. The RAM firmware for SCP is included in the TF-A FIP and is
- loaded by AP BL2 from FIP in flash to SRAM for copying by SCP (SCP has access
- to AP SRAM).
-- GICv4
-- Trusted Board Boot
-- SCMI
-- MHUv2
-
-Boot Sequence
--------------
-
-The execution begins from SCP_BL1. SCP_BL1 powers up the AP which starts
-executing AP_BL1 and then executes AP_BL2 which loads the SCP_BL2 from
-FIP to SRAM. The SCP has access to AP SRAM. The address and size of SCP_BL2
-is communicated to SCP using SDS. SCP copies SCP_BL2 from SRAM to its own
-RAM and starts executing it. The AP then continues executing the rest of TF-A
-stages including BL31 runtime stage and hands off executing to
-Non-secure world (u-boot).
-
-Build Procedure (TF-A only)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- Obtain arm `toolchain <https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads>`_.
- Set the CROSS_COMPILE environment variable to point to the toolchain folder.
-
-- Build TF-A:
-
- .. code:: shell
-
- make PLAT=tc0 BL33=<path_to_uboot.bin> \
- SCP_BL2=<path_to_scp_ramfw.bin> all fip
-
- Enable TBBR by adding the following options to the make command:
-
- .. code:: shell
-
- MBEDTLS_DIR=<path_to_mbedtls_directory> \
- TRUSTED_BOARD_BOOT=1 \
- GENERATE_COT=1 \
- ARM_ROTPK_LOCATION=devel_rsa \
- ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem
-
-*Copyright (c) 2020, Arm Limited. All rights reserved.*
diff --git a/docs/plat/deprecated.rst b/docs/plat/deprecated.rst
new file mode 100644
index 0000000..7cc4258
--- /dev/null
+++ b/docs/plat/deprecated.rst
@@ -0,0 +1,20 @@
+Deprecated platforms
+====================
+
+Process of deprecating a platform
+---------------------------------
+
+Platform can be deprecated and its source can be kept in repository for a cooling
+off period before deleting it or it can be deleted straight away. For later types
+Deprecated/Deleted version would be same.
+
+List of deprecated platforms
+----------------------------
+
++----------------+----------------+--------------------+--------------------+
+| Platform | Vendor | Deprecated version | Deleted version |
++================+================+====================+====================+
+| sgm775 | Arm | 2.5 | 2.7 |
++----------------+----------------+--------------------+--------------------+
+| mt6795 | MTK | 2.5 | 2.7 |
++----------------+----------------+--------------------+--------------------+
diff --git a/docs/plat/imx8m.rst b/docs/plat/imx8m.rst
index f184b69..0fe15c9 100644
--- a/docs/plat/imx8m.rst
+++ b/docs/plat/imx8m.rst
@@ -6,6 +6,9 @@
reliability and embedded security needed to drive the growth of fast-growing
edge node computing, streaming multimedia, and machine learning applications.
+imx8mq is dropped in TF-A CI build due to the small OCRAM size, but still actively
+maintained in NXP official release.
+
Boot Sequence
-------------
@@ -43,3 +46,17 @@
used to generate flash.bin, and flash.bin needs to be flashed into SD card
with certain offset for BOOT ROM. the u-boot and imx-mkimage will be upstreamed
soon, this doc will be updated once they are ready, and the link will be posted.
+
+TBBR Boot Sequence
+------------------
+
+When setting NEED_BL2=1 on imx8mm. We support an alternative way of
+boot sequence to support TBBR.
+
+Bootrom --> SPL --> BL2 --> BL31 --> BL33(u-boot with UEFI) --> grub
+
+This helps us to fulfill the SystemReady EBBR standard.
+BL2 will be in the FIT image and SPL will verify it.
+All of the BL3x will be put in the FIP image. BL2 will verify them.
+In U-boot we turn on the UEFI secure boot features so it can verify
+grub. And we use grub to verify linux kernel.
diff --git a/docs/plat/index.rst b/docs/plat/index.rst
index fb60e56..5848005 100644
--- a/docs/plat/index.rst
+++ b/docs/plat/index.rst
@@ -9,6 +9,7 @@
allwinner
arm/index
+ deprecated
meson-axg
meson-gxbb
meson-gxl
@@ -20,11 +21,13 @@
marvell/index
mt8183
mt8192
+ mt8195
nvidia-tegra
warp7
imx8
imx8m
ls1043a
+ nxp/index
poplar
qemu
qemu-sbsa
@@ -32,6 +35,7 @@
rpi3
rpi4
rcar-gen3
+ rz-g2
rockchip
socionext-uniphier
synquacer
diff --git a/docs/plat/marvell/armada/build.rst b/docs/plat/marvell/armada/build.rst
index e21fb3c..6872f56 100644
--- a/docs/plat/marvell/armada/build.rst
+++ b/docs/plat/marvell/armada/build.rst
@@ -26,7 +26,7 @@
*u-boot.bin* should be used and not *u-boot-spl.bin*
-Set MSS/SCP image path (mandatory only for A7K/8K/CN913x)
+Set MSS/SCP image path (mandatory only for A7K/8K/CN913x when MSS_SUPPORT=1)
.. code:: shell
@@ -51,6 +51,20 @@
There are several build options:
+- PLAT
+
+ Supported Marvell platforms are:
+
+ - a3700 - A3720 DB, EspressoBin and Turris MOX
+ - a70x0
+ - a70x0_amc - AMC board
+ - a70x0_mochabin - Globalscale MOCHAbin
+ - a80x0
+ - a80x0_mcbin - MacchiatoBin
+ - a80x0_puzzle - IEI Puzzle-M801
+ - t9130 - CN913x
+ - t9130_cex7_eval - CN913x CEx7 Evaluation Board
+
- DEBUG
Default is without debug information (=0). in order to enable it use ``DEBUG=1``.
@@ -61,17 +75,17 @@
Defines the level of logging which will be purged to the default output port.
- LOG_LEVEL_NONE 0
- LOG_LEVEL_ERROR 10
- LOG_LEVEL_NOTICE 20
- LOG_LEVEL_WARNING 30
- LOG_LEVEL_INFO 40
- LOG_LEVEL_VERBOSE 50
+ - 0 - LOG_LEVEL_NONE
+ - 10 - LOG_LEVEL_ERROR
+ - 20 - LOG_LEVEL_NOTICE (default for DEBUG=0)
+ - 30 - LOG_LEVEL_WARNING
+ - 40 - LOG_LEVEL_INFO (default for DEBUG=1)
+ - 50 - LOG_LEVEL_VERBOSE
- USE_COHERENT_MEM
This flag determines whether to include the coherent memory region in the
- BL memory map or not.
+ BL memory map or not. Enabled by default.
- LLC_ENABLE
@@ -89,25 +103,23 @@
- MARVELL_SECURE_BOOT
Build trusted(=1)/non trusted(=0) image, default is non trusted.
-
-- BLE_PATH
-
- Points to BLE (Binary ROM extension) sources folder.
- Only required for A7K/8K/CN913x builds.
- The parameter is optional, its default value is ``plat/marvell/armada/a8k/common/ble``.
+ This parameter is used only for ``mrvl_flash`` and ``mrvl_uart`` targets.
- MV_DDR_PATH
- For A7K/8K/CN913x, use this parameter to point to mv_ddr driver sources to allow BLE build. For A37x0,
- it is used for ddr_tool build.
+ This parameter is required for ``mrvl_flash`` and ``mrvl_uart`` targets.
+ For A7K/8K/CN913x it is used for BLE build and for Armada37x0 it used
+ for ddr_tool build.
- Usage example: MV_DDR_PATH=path/to/mv_ddr
+ Specify path to the full checkout of Marvell mv-ddr-marvell git
+ repository. Checkout must contain also .git subdirectory because
+ mv-ddr build process calls git commands.
- The parameter is optional for A7K/8K/CN913x, when this parameter is not set, the mv_ddr
- sources are expected to be located at: drivers/marvell/mv_ddr. However, the parameter
- is necessary for A37x0.
+ Do not remove any parts of git checkout becuase build process and other
+ applications need them for correct building and version determination.
- For the mv_ddr source location, check the section "Tools and external components installation"
+
+CN913x specific build options:
- CP_NUM
@@ -117,34 +129,121 @@
family (PLAT=t9130), which can have external CPs connected to the MCI ports. Valid
values with CP_NUM are in a range of 1 to 3.
+
+A7K/8K/CN913x specific build options:
+
+- BLE_PATH
+
+ Points to BLE (Binary ROM extension) sources folder.
+ The parameter is optional, its default value is ``plat/marvell/armada/a8k/common/ble``
+ which uses TF-A in-tree BLE implementation.
+
+- MSS_SUPPORT
+
+ When ``MSS_SUPPORT=1``, then TF-A includes support for Management SubSystem (MSS).
+ When enabled it is required to specify path to the MSS firmware image via ``SCP_BL2``
+ option.
+
+ This option is by default enabled.
+
+- SCP_BL2
+
+ Specify path to the MSS fimware image binary which will run on Cortex-M3 coprocessor.
+ It is available in Marvell binaries-marvell git repository. Required when ``MSS_SUPPORT=1``.
+
+Globalscale MOCHAbin specific build options:
+
- DDR_TOPOLOGY
- For Armada37x0 only, the DDR topology map index/name, default is 0.
+ The DDR topology map index/name, default is 0.
Supported Options:
- - DDR3 1CS (0): DB-88F3720-DDR3-Modular (512MB); EspressoBIN (512MB)
- - DDR4 1CS (1): DB-88F3720-DDR4-Modular (512MB)
- - DDR3 2CS (2): EspressoBIN V3-V5 (1GB 2CS)
- - DDR4 2CS (3): DB-88F3720-DDR4-Modular (4GB)
- - DDR3 1CS (4): DB-88F3720-DDR3-Modular (1GB); EspressoBIN V3-V5 (1GB 1CS)
- - DDR4 1CS (5): EspressoBin V7 (1GB)
- - DDR4 2CS (6): EspressoBin V7 (2GB)
- - DDR3 2CS (7): EspressoBin V3-V5 (2GB)
- - CUSTOMER (CUST): Customer board, DDR3 1CS 512MB
+ - 0 - DDR4 1CS 2GB
+ - 1 - DDR4 1CS 4GB
+ - 2 - DDR4 2CS 8GB
+
+Armada37x0 specific build options:
+
+- HANDLE_EA_EL3_FIRST
+
+ When ``HANDLE_EA_EL3_FIRST=1``, External Aborts and SError Interrupts will be always trapped
+ in TF-A. TF-A in this case enables dirty hack / workaround for a bug found in U-Boot and
+ Linux kernel PCIe controller driver pci-aardvark.c, traps and then masks SError interrupt
+ caused by AXI SLVERR on external access (syndrome 0xbf000002).
+
+ Otherwise when ``HANDLE_EA_EL3_FIRST=0``, these exceptions will be trapped in the current
+ exception level (or in EL1 if the current exception level is EL0). So exceptions caused by
+ U-Boot will be trapped in U-Boot, exceptions caused by Linux kernel (or user applications)
+ will be trapped in Linux kernel.
+
+ Mentioned bug in pci-aardvark.c driver is fixed in U-Boot version v2021.07 and Linux kernel
+ version v5.13 (workarounded since Linux kernel version 5.9) and also backported in Linux
+ kernel stable releases since versions v5.12.13, v5.10.46, v5.4.128, v4.19.198, v4.14.240.
+
+ If target system has already patched version of U-Boot and Linux kernel then it is strongly
+ recommended to not enable this workaround as it disallows propagating of all External Aborts
+ to running Linux kernel and makes correctable errors as fatal aborts.
+
+ This option is now disabled by default. In past this option was enabled by default in
+ TF-A versions v2.2, v2.3, v2.4 and v2.5.
+
+- CM3_SYSTEM_RESET
+
+ When ``CM3_SYSTEM_RESET=1``, the Cortex-M3 secure coprocessor will be used for system reset.
+
+ TF-A will send command 0x0009 with a magic value via the rWTM mailbox interface to the
+ Cortex-M3 secure coprocessor.
+ The firmware running in the coprocessor must either implement this functionality or
+ ignore the 0x0009 command (which is true for the firmware from A3700-utils-marvell
+ repository). If this option is enabled but the firmware does not support this command,
+ an error message will be printed prior trying to reboot via the usual way.
+
+ This option is needed on Turris MOX as a workaround to a HW bug which causes reset to
+ sometime hang the board.
+
+- A3720_DB_PM_WAKEUP_SRC
+
+ For Armada 3720 Development Board only, when ``A3720_DB_PM_WAKEUP_SRC=1``,
+ TF-A will setup PM wake up src configuration. This option is disabled by default.
+
+
+Armada37x0 specific build options for ``mrvl_flash`` and ``mrvl_uart`` targets:
+
+- DDR_TOPOLOGY
+
+ The DDR topology map index/name, default is 0.
+
+ Supported Options:
+ - 0 - DDR3 1CS 512MB (DB-88F3720-DDR3-Modular, EspressoBin V3-V5)
+ - 1 - DDR4 1CS 512MB (DB-88F3720-DDR4-Modular)
+ - 2 - DDR3 2CS 1GB (EspressoBin V3-V5)
+ - 3 - DDR4 2CS 4GB (DB-88F3720-DDR4-Modular)
+ - 4 - DDR3 1CS 1GB (DB-88F3720-DDR3-Modular, EspressoBin V3-V5)
+ - 5 - DDR4 1CS 1GB (EspressoBin V7, EspressoBin-Ultra)
+ - 6 - DDR4 2CS 2GB (EspressoBin V7)
+ - 7 - DDR3 2CS 2GB (EspressoBin V3-V5)
+ - CUST - CUSTOMER BOARD (Customer board settings)
- CLOCKSPRESET
- For Armada37x0 only, the clock tree configuration preset including CPU and DDR frequency,
+ The clock tree configuration preset including CPU and DDR frequency,
default is CPU_800_DDR_800.
- - CPU_600_DDR_600 - CPU at 600 MHz, DDR at 600 MHz
- - CPU_800_DDR_800 - CPU at 800 MHz, DDR at 800 MHz
- - CPU_1000_DDR_800 - CPU at 1000 MHz, DDR at 800 MHz
- - CPU_1200_DDR_750 - CPU at 1200 MHz, DDR at 750 MHz
+ - CPU_600_DDR_600 - CPU at 600 MHz, DDR at 600 MHz
+ - CPU_800_DDR_800 - CPU at 800 MHz, DDR at 800 MHz
+ - CPU_1000_DDR_800 - CPU at 1000 MHz, DDR at 800 MHz
+ - CPU_1200_DDR_750 - CPU at 1200 MHz, DDR at 750 MHz
+
+ Look at Armada37x0 chip package marking on board to identify correct CPU frequency.
+ The last line on package marking (next line after the 88F37x0 line) should contain:
+
+ - C080 or I080 - chip with 800 MHz CPU - use ``CLOCKSPRESET=CPU_800_DDR_800``
+ - C100 or I100 - chip with 1000 MHz CPU - use ``CLOCKSPRESET=CPU_1000_DDR_800``
+ - C120 - chip with 1200 MHz CPU - use ``CLOCKSPRESET=CPU_1200_DDR_750``
- BOOTDEV
- For Armada37x0 only, the flash boot device, default is ``SPINOR``.
+ The flash boot device, default is ``SPINOR``.
Currently, Armada37x0 only supports ``SPINOR``, ``SPINAND``, ``EMMCNORM`` and ``SATA``:
@@ -157,9 +256,13 @@
- SATA - SATA device boot
+ Image needs to be stored at disk LBA 0 or at disk partition with
+ MBR type 0x4d (ASCII 'M' as in Marvell) or at disk partition with
+ GPT name ``MARVELL BOOT PARTITION``.
+
- PARTNUM
- For Armada37x0 only, the boot partition number, default is 0.
+ The boot partition number, default is 0.
To boot from eMMC, the value should be aligned with the parameter in
U-Boot with name of ``CONFIG_SYS_MMC_ENV_PART``, whose value by default is
@@ -168,41 +271,106 @@
- WTMI_IMG
- For Armada37x0 only, the path of the WTMI image can point to an image which
+ The path of the binary can point to an image which
does nothing, an image which supports EFUSE or a customized CM3 firmware
- binary. The default image is wtmi.bin that built from sources in WTP
+ binary. The default image is ``fuse.bin`` that built from sources in WTP
folder, which is the next option. If the default image is OK, then this
option should be skipped.
+ Please note that this is not a full WTMI image, just a main loop without
+ hardware initialization code. Final WTMI image is built from this WTMI_IMG
+ binary and sys-init code from the WTP directory which sets DDR and CPU
+ clocks according to DDR_TOPOLOGY and CLOCKSPRESET options.
+
+ CZ.NIC as part of Turris project released free and open source WTMI
+ application firmware ``wtmi_app.bin`` for all Armada 3720 devices.
+ This firmware includes additional features like access to Hardware
+ Random Number Generator of Armada 3720 SoC which original Marvell's
+ ``fuse.bin`` image does not have.
+
+ CZ.NIC's Armada 3720 Secure Firmware is available at website:
+
+ https://gitlab.nic.cz/turris/mox-boot-builder/
+
- WTP
- For Armada37x0 only, use this parameter to point to wtptools source code
- directory, which can be found as a3700_utils.zip in the release. Usage
- example: ``WTP=/path/to/a3700_utils``
+ Specify path to the full checkout of Marvell A3700-utils-marvell git
+ repository. Checkout must contain also .git subdirectory because WTP
+ build process calls git commands.
- For example, in order to build the image in debug mode with log level up to 'notice' level run
+ WTP build process uses also Marvell mv-ddr-marvell git repository
+ specified in MV_DDR_PATH option.
- .. code:: shell
+ Do not remove any parts of git checkout becuase build process and other
+ applications need them for correct building and version determination.
- > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 PLAT=<MARVELL_PLATFORM> all fip
+- CRYPTOPP_PATH
- And if we want to build a Armada37x0 image in debug mode with log level up to 'notice' level,
- the image has the preset CPU at 1000 MHz, preset DDR3 at 800 MHz, the DDR topology of DDR4 2CS,
- the image boot from SPI NOR flash partition 0, and the image is non trusted in WTP, the command
- line is as following
+ Use this parameter to point to Crypto++ source code
+ directory. If this option is specified then Crypto++ source code in
+ CRYPTOPP_PATH directory will be automatically compiled. Crypto++ library
+ is required for building WTP image tool. Either CRYPTOPP_PATH or
+ CRYPTOPP_LIBDIR with CRYPTOPP_INCDIR needs to be specified for Armada37x0.
- .. code:: shell
+- CRYPTOPP_LIBDIR
- > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 CLOCKSPRESET=CPU_1000_DDR_800 \
- MARVELL_SECURE_BOOT=0 DDR_TOPOLOGY=3 BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 all fip
+ Use this parameter to point to the directory with
+ compiled Crypto++ library. By default it points to the CRYPTOPP_PATH.
- Supported MARVELL_PLATFORM are:
- - a3700 (for both A3720 DB and EspressoBin)
- - a70x0
- - a70x0_amc (for AMC board)
- - a80x0
- - a80x0_mcbin (for MacchiatoBin)
- - t9130 (OcteonTX2 CN913x)
+- CRYPTOPP_INCDIR
+
+ Use this parameter to point to the directory with
+ header files of Crypto++ library. By default it points to the CRYPTOPP_PATH.
+
+
+For example, in order to build the image in debug mode with log level up to 'notice' level run
+
+.. code:: shell
+
+ > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 PLAT=<MARVELL_PLATFORM> mrvl_flash
+
+And if we want to build a Armada37x0 image in debug mode with log level up to 'notice' level,
+the image has the preset CPU at 1000 MHz, preset DDR3 at 800 MHz, the DDR topology of DDR4 2CS,
+the image boot from SPI NOR flash partition 0, and the image is non trusted in WTP, the command
+line is as following
+
+.. code:: shell
+
+ > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 CLOCKSPRESET=CPU_1000_DDR_800 \
+ MARVELL_SECURE_BOOT=0 DDR_TOPOLOGY=3 BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 \
+ MV_DDR_PATH=/path/to/mv-ddr-marvell/ WTP=/path/to/A3700-utils-marvell/ \
+ CRYPTOPP_PATH=/path/to/cryptopp/ BL33=/path/to/u-boot.bin \
+ all fip mrvl_bootimage mrvl_flash mrvl_uart
+
+To build just TF-A without WTMI image (useful for A3720 Turris MOX board), run following command:
+
+.. code:: shell
+
+ > make USE_COHERENT_MEM=0 PLAT=a3700 CM3_SYSTEM_RESET=1 BL33=/path/to/u-boot.bin \
+ CROSS_COMPILE=aarch64-linux-gnu- mrvl_bootimage
+
+Here is full example how to build production release of Marvell firmware image (concatenated
+binary of Marvell's A3720 sys-init, CZ.NIC's Armada 3720 Secure Firmware, TF-A and U-Boot) for
+EspressoBin board (PLAT=a3700) with 1GHz CPU (CLOCKSPRESET=CPU_1000_DDR_800) and
+1GB DDR4 RAM (DDR_TOPOLOGY=5):
+
+.. code:: shell
+
+ > git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
+ > git clone https://source.denx.de/u-boot/u-boot.git
+ > git clone https://github.com/weidai11/cryptopp.git
+ > git clone https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git
+ > git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git
+ > git clone https://gitlab.nic.cz/turris/mox-boot-builder.git
+ > make -C u-boot CROSS_COMPILE=aarch64-linux-gnu- mvebu_espressobin-88f3720_defconfig u-boot.bin
+ > make -C mox-boot-builder CROSS_CM3=arm-linux-gnueabi- wtmi_app.bin
+ > make -C trusted-firmware-a CROSS_COMPILE=aarch64-linux-gnu- CROSS_CM3=arm-linux-gnueabi- \
+ USE_COHERENT_MEM=0 PLAT=a3700 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=5 \
+ MV_DDR_PATH=$PWD/mv-ddr-marvell/ WTP=$PWD/A3700-utils-marvell/ \
+ CRYPTOPP_PATH=$PWD/cryptopp/ BL33=$PWD/u-boot/u-boot.bin \
+ WTMI_IMG=$PWD/mox-boot-builder/wtmi_app.bin FIP_ALIGN=0x100 mrvl_flash
+
+Produced Marvell firmware flash image: ``trusted-firmware-a/build/a3700/release/flash-image.bin``
Special Build Flags
--------------------
@@ -224,23 +392,31 @@
Build output
------------
-Marvell's TF-A compilation generates 7 files:
+Marvell's TF-A compilation generates 8 files:
- - ble.bin - BLe image
+ - ble.bin - BLe image (not available for Armada37x0)
- bl1.bin - BL1 image
- bl2.bin - BL2 image
- bl31.bin - BL31 image
- fip.bin - FIP image (contains BL2, BL31 & BL33 (U-Boot) images)
- boot-image.bin - TF-A image (contains BL1 and FIP images)
- - flash-image.bin - Image which contains boot-image.bin and SPL image.
- Should be placed on the boot flash/device.
+ - flash-image.bin - Flashable Marvell firmware image. For Armada37x0 it
+ contains TIM, WTMI and boot-image.bin images. For other platforms it contains
+ BLe and boot-image.bin images. Should be placed on the boot flash/device.
+ - uart-images.tgz.bin - GZIPed TAR archive which contains Armada37x0 images
+ for booting via UART. Could be loaded via Marvell's WtpDownload tool from
+ A3700-utils-marvell repository.
+
+Additional make target ``mrvl_bootimage`` produce ``boot-image.bin`` file. Target
+``mrvl_flash`` produce final ``flash-image.bin`` file and target ``mrvl_uart``
+produce ``uart-images.tgz.bin`` file.
Tools and external components installation
------------------------------------------
-Armada37x0 Builds require installation of 3 components
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Armada37x0 Builds require installation of additional components
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(1) ARM cross compiler capable of building images for the service CPU (CM3).
This component is usually included in the Linux host packages.
@@ -260,19 +436,32 @@
> export CROSS_CM3=/opt/arm-cross/bin/arm-linux-gnueabi
(2) DDR initialization library sources (mv_ddr) available at the following repository
- (use the "mv-ddr-devel" branch):
+ (use the "master" branch):
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git
(3) Armada3700 tools available at the following repository
- (use the "A3700_utils-armada-18.12-fixed" branch):
+ (use the "master" branch):
https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git
-Armada70x0 and Armada80x0 Builds require installation of an additional component
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+(4) Crypto++ library available at the following repository:
+
+ https://github.com/weidai11/cryptopp.git
+
+(5) Optional CZ.NIC's Armada 3720 Secure Firmware:
+
+ https://gitlab.nic.cz/turris/mox-boot-builder.git
+
+Armada70x0, Armada80x0 and CN913x Builds require installation of additional components
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(1) DDR initialization library sources (mv_ddr) available at the following repository
- (use the "mv-ddr-devel" branch):
+ (use the "master" branch):
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git
+
+(2) MSS Management SubSystem Firmware available at the following repository
+ (use the "binaries-marvell-armada-SDK10.0.1.0" branch):
+
+ https://github.com/MarvellEmbeddedProcessors/binaries-marvell.git
diff --git a/docs/plat/marvell/armada/misc/mvebu-ccu.rst b/docs/plat/marvell/armada/misc/mvebu-ccu.rst
index 5bac11f..12118e9 100644
--- a/docs/plat/marvell/armada/misc/mvebu-ccu.rst
+++ b/docs/plat/marvell/armada/misc/mvebu-ccu.rst
@@ -1,7 +1,7 @@
Marvell CCU address decoding bindings
=====================================
-CCU configration driver (1st stage address translation) for Marvell Armada 8K and 8K+ SoCs.
+CCU configuration driver (1st stage address translation) for Marvell Armada 8K and 8K+ SoCs.
The CCU node includes a description of the address decoding configuration.
diff --git a/docs/plat/marvell/armada/misc/mvebu-io-win.rst b/docs/plat/marvell/armada/misc/mvebu-io-win.rst
index 52845ca..7498291 100644
--- a/docs/plat/marvell/armada/misc/mvebu-io-win.rst
+++ b/docs/plat/marvell/armada/misc/mvebu-io-win.rst
@@ -1,7 +1,7 @@
Marvell IO WIN address decoding bindings
========================================
-IO Window configration driver (2nd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
+IO Window configuration driver (2nd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
The IO WIN includes a description of the address decoding configuration.
diff --git a/docs/plat/marvell/armada/misc/mvebu-iob.rst b/docs/plat/marvell/armada/misc/mvebu-iob.rst
index d02a7e8..aa41822 100644
--- a/docs/plat/marvell/armada/misc/mvebu-iob.rst
+++ b/docs/plat/marvell/armada/misc/mvebu-iob.rst
@@ -1,7 +1,7 @@
Marvell IOB address decoding bindings
=====================================
-IO bridge configration driver (3rd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
+IO bridge configuration driver (3rd stage address translation) for Marvell Armada 8K and 8K+ SoCs.
The IOB includes a description of the address decoding configuration.
diff --git a/docs/plat/mt8195.rst b/docs/plat/mt8195.rst
new file mode 100644
index 0000000..b2aeea2
--- /dev/null
+++ b/docs/plat/mt8195.rst
@@ -0,0 +1,21 @@
+MediaTek 8195
+=============
+
+MediaTek 8195 (MT8195) is a 64-bit ARM SoC introduced by MediaTek in 2021.
+The chip incorporates eight cores - four Cortex-A55 little cores and Cortex-A76.
+Cortex-A76 can operate at up to 2.2 GHz.
+Cortex-A55 can operate at up to 2.0 GHz.
+
+Boot Sequence
+-------------
+
+::
+
+ Boot Rom --> Coreboot --> TF-A BL31 --> Depthcharge --> Linux Kernel
+
+How to Build
+------------
+
+.. code:: shell
+
+ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=mt8195 DEBUG=1 COREBOOT=1
diff --git a/docs/plat/nvidia-tegra.rst b/docs/plat/nvidia-tegra.rst
index 02ff38b..391c7c8 100644
--- a/docs/plat/nvidia-tegra.rst
+++ b/docs/plat/nvidia-tegra.rst
@@ -19,7 +19,7 @@
multi-processing (HMP) solution designed to optimize performance and
efficiency.
-T186 has Dual NVIDIA Denver 2 ARM® CPU cores, plus Quad ARM Cortex®-A57 cores,
+T186 has Dual NVIDIA Denver2 ARM® CPU cores, plus Quad ARM Cortex®-A57 cores,
in a coherent multiprocessor configuration. The Denver 2 and Cortex-A57 cores
support ARMv8, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
including legacy ARMv7 applications. The Denver 2 processors each have 128 KB
@@ -29,20 +29,6 @@
high speed coherency fabric connects these two processor complexes and allows
heterogeneous multi-processing with all six cores if required.
-- .. rubric:: T210
- :name: t210
-
-T210 has Quad Arm® Cortex®-A57 cores in a switched configuration with a
-companion set of quad Arm Cortex-A53 cores. The Cortex-A57 and A53 cores
-support Armv8-A, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
-including legacy Armv7-A applications. The Cortex-A57 processors each have
-48 KB Instruction and 32 KB Data Level 1 caches; and have a 2 MB shared
-Level 2 unified cache. The Cortex-A53 processors each have 32 KB Instruction
-and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache.
-
-- .. rubric:: T132
- :name: t132
-
Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is
fully Armv8-A architecture compatible. Each of the two Denver cores
implements a 7-way superscalar microarchitecture (up to 7 concurrent
@@ -68,6 +54,17 @@
to extensive power-gating and dynamic voltage and clock scaling based on
workloads.
+- .. rubric:: T210
+ :name: t210
+
+T210 has Quad Arm® Cortex®-A57 cores in a switched configuration with a
+companion set of quad Arm Cortex-A53 cores. The Cortex-A57 and A53 cores
+support Armv8-A, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code
+including legacy Armv7-A applications. The Cortex-A57 processors each have
+48 KB Instruction and 32 KB Data Level 1 caches; and have a 2 MB shared
+Level 2 unified cache. The Cortex-A53 processors each have 32 KB Instruction
+and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache.
+
Directory structure
-------------------
@@ -89,7 +86,6 @@
These are the supported Trusted OS' by Tegra platforms.
-- Tegra132: TLK
- Tegra210: TLK and Trusty
- Tegra186: Trusty
- Tegra194: Trusty
@@ -110,7 +106,7 @@
.. code:: shell
CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf- make PLAT=tegra \
- TARGET_SOC=<target-soc e.g. t194|t186|t210|t132> SPD=<dispatcher e.g. trusty|tlkd>
+ TARGET_SOC=<target-soc e.g. t194|t186|t210> SPD=<dispatcher e.g. trusty|tlkd>
bl31
Platforms wanting to use different TZDRAM\_BASE, can add ``TZDRAM_BASE=<value>``
diff --git a/docs/plat/nxp/index.rst b/docs/plat/nxp/index.rst
new file mode 100644
index 0000000..8546887
--- /dev/null
+++ b/docs/plat/nxp/index.rst
@@ -0,0 +1,17 @@
+NXP Reference Development Platforms
+===================================
+
+.. toctree::
+ :maxdepth: 1
+ :caption: Contents
+
+ nxp-layerscape
+ nxp-ls-fuse-prov
+ nxp-ls-tbbr
+
+This chapter holds documentation related to NXP reference development platforms.
+It includes details on image flashing, fuse provisioning and trusted board boot-up.
+
+--------------
+
+*Copyright (c) 2021, NXP Limited. All rights reserved.*
diff --git a/docs/plat/nxp/nxp-layerscape.rst b/docs/plat/nxp/nxp-layerscape.rst
new file mode 100644
index 0000000..9a470e6
--- /dev/null
+++ b/docs/plat/nxp/nxp-layerscape.rst
@@ -0,0 +1,301 @@
+NXP SoCs - Overview
+=====================
+.. section-numbering::
+ :suffix: .
+
+The QorIQ family of ARM based SoCs that are supported on TF-A are:
+
+1. LX2160A
+
+- SoC Overview:
+
+The LX2160A multicore processor, the highest-performance member of the
+Layerscape family, combines FinFET process technology's low power and
+sixteen Arm® Cortex®-A72 cores with datapath acceleration optimized for
+L2/3 packet processing, together with security offload, robust traffic
+management and quality of service.
+
+Details about LX2160A can be found at `lx2160a`_.
+
+- LX2160ARDB Board:
+
+The LX2160A reference design board provides a comprehensive platform
+that enables design and evaluation of the LX2160A or LX2162A processors. It
+comes preloaded with a board support package (BSP) based on a standard Linux
+kernel.
+
+Board details can be fetched from the link: `lx2160ardb`_.
+
+2. LS1028A
+
+- SoC Overview:
+
+The Layerscape LS1028A applications processor for industrial and
+automotive includes a time-sensitive networking (TSN) -enabled Ethernet
+switch and Ethernet controllers to support converged IT and OT networks.
+Two powerful 64-bit Arm®v8 cores support real-time processing for
+industrial control and virtual machines for edge computing in the IoT.
+The integrated GPU and LCD controller enable Human-Machine Interface
+(HMI) systems with next-generation interfaces.
+
+Details about LS1028A can be found at `ls1028a`_.
+
+- LS1028ARDB Boards:
+
+The LS1028A reference design board (RDB) is a computing, evaluation,
+and development platform that supports industrial IoT applications, human
+machine interface solutions, and industrial networking.
+
+Details about LS1028A RDB board can be found at `ls1028ardb`_.
+
+Table of supported boot-modes by each platform & platform that needs FIP-DDR:
+-----------------------------------------------------------------------------
+
++---------------------+---------------------------------------------------------------------+-----------------+
+| | BOOT_MODE | |
+| PLAT +-------+--------+-------+-------+-------+-------------+--------------+ fip_ddr_needed |
+| | sd | qspi | nor | nand | emmc | flexspi_nor | flexspi_nand | |
++=====================+=======+========+=======+=======+=======+=============+==============+=================+
+| lx2160ardb | yes | | | | yes | yes | | yes |
++---------------------+-------+--------+-------+-------+-------+-------------+--------------+-----------------+
+| ls1028ardb | yes | | | | yes | yes | | no |
++---------------------+-------+--------+-------+-------+-------+-------------+--------------+-----------------+
+
+
+Boot Sequence
+-------------
+::
+
++ Secure World | Normal World
++ EL0 |
++ |
++ EL1 BL32(Tee OS) | kernel
++ ^ | | ^
++ | | | |
++ EL2 | | | BL33(u-boot)
++ | | | ^
++ | v | /
++ EL3 BootROM --> BL2 --> BL31 ---------------/
++
+
+Boot Sequence with FIP-DDR
+--------------------------
+::
+
++ Secure World | Normal World
++ EL0 |
++ |
++ EL1 fip-ddr BL32(Tee OS) | kernel
++ ^ | ^ | | ^
++ | | | | | |
++ EL2 | | | | | BL33(u-boot)
++ | | | | | ^
++ | v | v | /
++ EL3 BootROM --> BL2 -----> BL31 ---------------/
++
+
+DDR Memory Layout
+--------------------------
+
+NXP Platforms divide DRAM into banks:
+
+- DRAM0 Bank: Maximum size of this bank is fixed to 2GB, DRAM0 size is defined in platform_def.h if it is less than 2GB.
+
+- DRAM1 ~ DRAMn Bank: Greater than 2GB belongs to DRAM1 and following banks, and size of DRAMn Bank varies for one platform to others.
+
+The following diagram is default DRAM0 memory layout in which secure memory is at top of DRAM0.
+
+::
+
+ high +---------------------------------------------+
+ | |
+ | Secure EL1 Payload Shared Memory (2 MB) |
+ | |
+ +---------------------------------------------+
+ | |
+ | Secure Memory (64 MB) |
+ | |
+ +---------------------------------------------+
+ | |
+ | Non Secure Memory |
+ | |
+ low +---------------------------------------------+
+
+How to build
+=============
+
+Code Locations
+--------------
+
+- OP-TEE:
+ `link <https://source.codeaurora.org/external/qoriq/qoriq-components/optee_os>`__
+
+- U-Boot:
+ `link <https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot>`__
+
+- RCW:
+ `link <https://source.codeaurora.org/external/qoriq/qoriq-components/rcw>`__
+
+- ddr-phy-binary: Required by platforms that need fip-ddr.
+ `link <https:://github.com/NXP/ddr-phy-binary>`__
+
+- cst: Required for TBBR.
+ `link <https:://source.codeaurora.org/external/qoriq/qoriq-components/cst>`__
+
+Build Procedure
+---------------
+
+- Fetch all the above repositories into local host.
+
+- Prepare AARCH64 toolchain and set the environment variable "CROSS_COMPILE".
+
+ .. code:: shell
+
+ export CROSS_COMPILE=.../bin/aarch64-linux-gnu-
+
+- Build RCW. Refer README from the respective cloned folder for more details.
+
+- Build u-boot and OPTee firstly, and get binary images: u-boot.bin and tee.bin.
+ For u-boot you can use the <platform>_tfa_defconfig for build.
+
+- Copy/clone the repo "ddr-phy-binary" to the tfa directory for platform needing ddr-fip.
+
+- Below are the steps to build TF-A images for the supported platforms.
+
+Compilation steps without BL32
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+BUILD BL2:
+
+-To compile
+ .. code:: shell
+
+ make PLAT=$PLAT \
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ pbl
+
+BUILD FIP:
+
+ .. code:: shell
+
+ make PLAT=$PLAT \
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ BL33=$UBOOT_SECURE_BIN \
+ pbl \
+ fip
+
+Compilation steps with BL32
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+BUILD BL2:
+
+-To compile
+ .. code:: shell
+
+ make PLAT=$PLAT \
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ BL32=$TEE_BIN SPD=opteed\
+ pbl
+
+BUILD FIP:
+
+ .. code:: shell
+
+ make PLAT=$PLAT \
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ BL32=$TEE_BIN SPD=opteed\
+ BL33=$UBOOT_SECURE_BIN \
+ pbl \
+ fip
+
+
+BUILD fip-ddr (Mandatory for certain platforms, refer table above):
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-To compile additional fip-ddr for selected platforms(Refer above table if the platform needs fip-ddr).
+ .. code:: shell
+
+ make PLAT=<platform_name> fip-ddr
+
+
+Deploy ATF Images
+=================
+
+Note: The size in the standard uboot commands for copy to nor, qspi, nand or sd
+should be modified based on the binary size of the image to be copied.
+
+- Deploy ATF images on flexspi-Nor flash Alt Bank from U-Boot prompt.
+ -- Commands to flash images for bl2_xxx.pbl and fip.bin.
+
+ .. code:: shell
+
+ tftp 82000000 $path/bl2_flexspi_nor.pbl;
+ i2c mw 66 50 20;sf probe 0:0; sf erase 0 +$filesize; sf write 0x82000000 0x0 $filesize;
+
+ tftp 82000000 $path/fip.bin;
+ i2c mw 66 50 20;sf probe 0:0; sf erase 0x100000 +$filesize; sf write 0x82000000 0x100000 $filesize;
+
+ -- Next step is valid for platform where FIP-DDR is needed.
+
+ .. code:: shell
+
+ tftp 82000000 $path/ddr_fip.bin;
+ i2c mw 66 50 20;sf probe 0:0; sf erase 0x800000 +$filesize; sf write 0x82000000 0x800000 $filesize;
+
+ -- Then reset to alternate bank to boot up ATF.
+
+ .. code:: shell
+
+ qixisreset altbank;
+
+- Deploy ATF images on SD/eMMC from U-Boot prompt.
+ -- file_size_in_block_sizeof_512 = (Size_of_bytes_tftp / 512)
+
+ .. code:: shell
+
+ mmc dev <idx>; (idx = 1 for eMMC; idx = 0 for SD)
+
+ tftp 82000000 $path/bl2_<sd>_or_<emmc>.pbl;
+ mmc write 82000000 8 <file_size_in_block_sizeof_512>;
+
+ tftp 82000000 $path/fip.bin;
+ mmc write 82000000 0x800 <file_size_in_block_sizeof_512>;
+
+ -- Next step is valid for platform that needs FIP-DDR.
+
+ .. code:: shell
+
+ tftp 82000000 $path/ddr_fip.bin;
+ mmc write 82000000 0x4000 <file_size_in_block_sizeof_512>;
+
+ -- Then reset to sd/emmc to boot up ATF from sd/emmc as boot-source.
+
+ .. code:: shell
+
+ qixisreset <sd or emmc>;
+
+Trusted Board Boot:
+===================
+
+For TBBR, the binary name changes:
+
++-------------+--------------------------+---------+-------------------+
+| Boot Type | BL2 | FIP | FIP-DDR |
++=============+==========================+=========+===================+
+| Normal Boot | bl2_<boot_mode>.pbl | fip.bin | ddr_fip.bin |
++-------------+--------------------------+---------+-------------------+
+| TBBR Boot | bl2_<boot_mode>_sec.pbl | fip.bin | ddr_fip_sec.bin |
++-------------+--------------------------+---------+-------------------+
+
+Refer `nxp-ls-tbbr.rst`_ for detailed user steps.
+
+
+.. _lx2160a: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-processors/layerscape-lx2160a-lx2120a-lx2080a-processors:LX2160A
+.. _lx2160ardb: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-communication-process/layerscape-lx2160a-multicore-communications-processor:LX2160A
+.. _ls1028a: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-processors/layerscape-1028a-applications-processor:LS1028A
+.. _ls1028ardb: https://www.nxp.com/design/qoriq-developer-resources/layerscape-ls1028a-reference-design-board:LS1028ARDB
+.. _nxp-ls-tbbr.rst: ./nxp-ls-tbbr.rst
diff --git a/docs/plat/nxp/nxp-ls-fuse-prov.rst b/docs/plat/nxp/nxp-ls-fuse-prov.rst
new file mode 100644
index 0000000..64e1c6f
--- /dev/null
+++ b/docs/plat/nxp/nxp-ls-fuse-prov.rst
@@ -0,0 +1,271 @@
+
+Steps to blow fuses on NXP LS SoC:
+==================================
+
+
+- Enable POVDD
+ -- Refer board GSG(Getting Started Guide) for the steps to enable POVDD.
+ -- Once the POVDD is enabled, make sure to set variable POVDD_ENABLE := yes, in the platform.mk.
+
++---+-----------------+-----------+------------+-----------------+-----------------------------+
+| | Platform | Jumper | Switch | LED to Verify | Through GPIO Pin (=number) |
++===+=================+===========+============+=================+=============================+
+| 1.| lx2160ardb | J9 | | | no |
++---+-----------------+-----------+------------+-----------------+-----------------------------+
+| 2.| lx2160aqds | J35 | | | no |
++---+-----------------+-----------+------------+-----------------+-----------------------------+
+| 3.| lx2162aqds | J35 | SW9[4] = 1 | D15 | no |
++---+-----------------+-----------+------------+-----------------+-----------------------------+
+
+- SFP registers to be written to:
+
++---+----------------------------------+----------------------+----------------------+
+| | Platform | OTPMKR0..OTPMKR7 | SRKHR0..SRKHR7 |
++===+==================================+======================+======================+
+| 1.| lx2160ardb/lx2160aqds/lx2162aqds | 0x1e80234..0x1e80250 | 0x1e80254..0x1e80270 |
++---+----------------------------------+----------------------+----------------------+
+
+- At U-Boot prompt, verify that SNVS register - HPSR, whether OTPMK was written, already:
+
++---+----------------------------------+-------------------------------------------+---------------+
+| | Platform | OTPMK_ZERO_BIT(=value) | SNVS_HPSR_REG |
++===+==================================+===========================================+===============+
+| 1.| lx2160ardb/lx2160aqds/lx2162aqds | 27 (= 1 means not blown, =0 means blown) | 0x01E90014 |
++---+----------------------------------+-------------------------------------------+---------------+
+
+From u-boot prompt:
+
+ -- Check for the OTPMK.
+ .. code:: shell
+
+ md $SNVS_HPSR_REG
+
+ Command Output:
+ 01e90014: 88000900
+
+ In case it is read as 00000000, then read this register using jtag (in development mode only through CW tap).
+ +0 +4 +8 +C
+ [0x01E90014] 88000900
+
+ Note: OTPMK_ZERO_BIT is 1, indicating that the OTPMK is not blown.
+
+ -- Check for the SRK Hash.
+ .. code:: shell
+
+ md $SRKHR0 0x10
+
+ Command Output:
+ 01e80254: 00000000 00000000 00000000 00000000 ................
+ 01e80264: 00000000 00000000 00000000 00000000 ................
+
+ Note: Zero means that SRK hash is not blown.
+
+- If not blown, then from the U-Boot prompt, using following commands:
+ -- Provision the OTPMK.
+
+ .. code:: shell
+
+ mw.l $OTPMKR0 <OTMPKR_0_32Bit_val>
+ mw.l $OTPMKR1 <OTMPKR_1_32Bit_val>
+ mw.l $OTPMKR2 <OTMPKR_2_32Bit_val>
+ mw.l $OTPMKR3 <OTMPKR_3_32Bit_val>
+ mw.l $OTPMKR4 <OTMPKR_4_32Bit_val>
+ mw.l $OTPMKR5 <OTMPKR_5_32Bit_val>
+ mw.l $OTPMKR6 <OTMPKR_6_32Bit_val>
+ mw.l $OTPMKR7 <OTMPKR_7_32Bit_val>
+
+ -- Provision the SRK Hash.
+
+ .. code:: shell
+
+ mw.l $SRKHR0 <SRKHR_0_32Bit_val>
+ mw.l $SRKHR1 <SRKHR_1_32Bit_val>
+ mw.l $SRKHR2 <SRKHR_2_32Bit_val>
+ mw.l $SRKHR3 <SRKHR_3_32Bit_val>
+ mw.l $SRKHR4 <SRKHR_4_32Bit_val>
+ mw.l $SRKHR5 <SRKHR_5_32Bit_val>
+ mw.l $SRKHR6 <SRKHR_6_32Bit_val>
+ mw.l $SRKHR7 <SRKHR_7_32Bit_val>
+
+ Note: SRK Hash should be carefully written keeping in mind the SFP Block Endianness.
+
+- At U-Boot prompt, verify that SNVS registers for OTPMK are correctly written:
+
+ -- Check for the OTPMK.
+ .. code:: shell
+
+ md $SNVS_HPSR_REG
+
+ Command Output:
+ 01e90014: 80000900
+
+ OTPMK_ZERO_BIT is zero, indicating that the OTPMK is blown.
+
+ Note: In case it is read as 00000000, then read this register using jtag (in development mode only through CW tap).
+
+ .. code:: shell
+
+ md $OTPMKR0 0x10
+
+ Command Output:
+ 01e80234: ffffffff ffffffff ffffffff ffffffff ................
+ 01e80244: ffffffff ffffffff ffffffff ffffffff ................
+
+ Note: OTPMK will never be visible in plain.
+
+ -- Check for the SRK Hash. For example, if following SRK hash is written:
+
+ SFP SRKHR0 = fdc2fed4
+ SFP SRKHR1 = 317f569e
+ SFP SRKHR2 = 1828425c
+ SFP SRKHR3 = e87b5cfd
+ SFP SRKHR4 = 34beab8f
+ SFP SRKHR5 = df792a70
+ SFP SRKHR6 = 2dff85e1
+ SFP SRKHR7 = 32a29687,
+
+ then following would be the value on dumping SRK hash.
+
+ .. code:: shell
+
+ md $SRKHR0 0x10
+
+ Command Output:
+ 01e80254: d4fec2fd 9e567f31 5c422818 fd5c7be8 ....1.V..(B\.{\.
+ 01e80264: 8fabbe34 702a79df e185ff2d 8796a232 4....y*p-...2...
+
+ Note: SRK Hash is visible in plain based on the SFP Block Endianness.
+
+- Caution: Donot proceed to the next step, until you are sure that OTPMK and SRKH are correctly blown from above steps.
+ -- After the next step, there is no turning back.
+ -- Fuses will be burnt, which cannot be undo.
+
+- Write SFP_INGR[INST] with the PROGFB(0x2) instruction to blow the fuses.
+ -- User need to save the SRK key pair and OTPMK Key forever, to continue using this board.
+
++---+----------------------------------+-------------------------------------------+-----------+
+| | Platform | SFP_INGR_REG | SFP_WRITE_DATE_FRM_MIRROR_REG_TO_FUSE |
++===+==================================+=======================================================+
+| 1.| lx2160ardb/lx2160aqds/lx2162aqds | 0x01E80020 | 0x2 |
++---+----------------------------------+--------------+----------------------------------------+
+
+ .. code:: shell
+
+ md $SFP_INGR_REG $SFP_WRITE_DATE_FRM_MIRROR_REG_TO_FUSE
+
+- On reset, if the SFP register were read from u-boot, it will show the following:
+ -- Check for the OTPMK.
+
+ .. code:: shell
+
+ md $SNVS_HPSR_REG
+
+ Command Output:
+ 01e90014: 80000900
+
+ In case it is read as 00000000, then read this register using jtag (in development mode only through CW tap).
+ +0 +4 +8 +C
+ [0x01E90014] 80000900
+
+ Note: OTPMK_ZERO_BIT is zero, indicating that the OTPMK is blown.
+
+ .. code:: shell
+
+ md $OTPMKR0 0x10
+
+ Command Output:
+ 01e80234: ffffffff ffffffff ffffffff ffffffff ................
+ 01e80244: ffffffff ffffffff ffffffff ffffffff ................
+
+ Note: OTPMK will never be visible in plain.
+
+ -- SRK Hash
+
+ .. code:: shell
+
+ md $SRKHR0 0x10
+
+ Command Output:
+ 01e80254: d4fec2fd 9e567f31 5c422818 fd5c7be8 ....1.V..(B\.{\.
+ 01e80264: 8fabbe34 702a79df e185ff2d 8796a232 4....y*p-...2...
+
+ Note: SRK Hash is visible in plain based on the SFP Block Endianness.
+
+Second method to do the fuse provsioning:
+=========================================
+
+This method is used for quick way to provision fuses.
+Typically used by those who needs to provision number of boards.
+
+- Enable POVDD:
+ -- Refer the table above to enable POVDD.
+
+ Note: If GPIO Pin supports enabling POVDD, it can be done through the below input_fuse_file.
+
+ -- Once the POVDD is enabled, make sure to set variable POVDD_ENABLE := yes, in the platform.mk.
+
+- User need to populate the "input_fuse_file", corresponding to the platform for:
+
+ -- OTPMK
+ -- SRKH
+
+ Table of fuse provisioning input file for every supported platform:
+
++---+----------------------------------+-----------------------------------------------------------------+
+| | Platform | FUSE_PROV_FILE |
++===+==================================+=================================================================+
+| 1.| lx2160ardb/lx2160aqds/lx2162aqds | ${CST_DIR}/input_files/gen_fusescr/ls2088_1088/input_fuse_file |
++---+----------------------------------+--------------+--------------------------------------------------+
+
+- Create the TF-A binary with FUSE_PROG=1.
+
+ .. code:: shell
+
+ make PLAT=$PLAT FUSE_PROG=1\
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ BL32=$TEE_BIN SPD=opteed\
+ BL33=$UBOOT_SECURE_BIN \
+ pbl \
+ fip \
+ fip_fuse \
+ FUSE_PROV_FILE=../../apps/security/cst/input_files/gen_fusescr/ls2088_1088/input_fuse_file
+
+- Deployment:
+ -- Refer the nxp-layerscape.rst for deploying TF-A images.
+ -- Deploying fip_fuse.bin:
+
+ For Flexspi-Nor:
+
+ .. code:: shell
+
+ tftp 82000000 $path/fuse_fip.bin;
+ i2c mw 66 50 20;sf probe 0:0; sf erase 0x880000 +$filesize; sf write 0x82000000 0x880000 $filesize;
+
+ For SD or eMMC [file_size_in_block_sizeof_512 = (Size_of_bytes_tftp / 512)]:
+
+ .. code:: shell
+
+ tftp 82000000 $path/fuse_fip.bin;
+ mmc write 82000000 0x4408 <file_size_in_block_sizeof_512>;
+
+- Valiation:
+
++---+----------------------------------+---------------------------------------------------+
+| | Platform | Error_Register | Error_Register_Address |
++===+==================================+===================================================+
+| 1.| lx2160ardb/lx2160aqds/lx2162aqds | DCFG scratch 4 register | 0x01EE020C |
++---+----------------------------------+---------------------------------------------------+
+
+ At the U-Boot prompt, check DCFG scratch 4 register for any error.
+
+ .. code:: shell
+
+ md $Error_Register_Address 1
+
+ Command Ouput:
+ 01ee020c: 00000000
+
+ Note:
+ - 0x00000000 shows no error, then fuse provisioning is successful.
+ - For non-zero value, refer the code header file ".../drivers/nxp/sfp/sfp_error_codes.h"
diff --git a/docs/plat/nxp/nxp-ls-tbbr.rst b/docs/plat/nxp/nxp-ls-tbbr.rst
new file mode 100644
index 0000000..43e15f7
--- /dev/null
+++ b/docs/plat/nxp/nxp-ls-tbbr.rst
@@ -0,0 +1,210 @@
+
+--------------
+NXP Platforms:
+--------------
+TRUSTED_BOARD_BOOT option can be enabled by specifying TRUSTED_BOARD_BOOT=1 on command line during make.
+
+
+
+Bare-Minimum Preparation to run TBBR on NXP Platforms:
+=======================================================
+- OTPMK(One Time Programable Key) needs to be burnt in fuses.
+ -- It is the 256 bit key that stores a secret value used by the NXP SEC 4.0 IP in Trusted or Secure mode.
+
+ Note: It is primarily for the purpose of decrypting additional secrets stored in system non-volatile memory.
+
+ -- NXP CST tool gives an option to generate it.
+
+ Use the below command from directory 'cst', with correct options.
+
+ .. code:: shell
+
+ ./gen_otpmk_drbg
+
+- SRKH (Super Root Key Hash) needs to be burnt in fuses.
+ -- It is the 256 bit hash of the list of the public keys of the SRK key pair.
+ -- NXP CST tool gives an option to generate the RSA key pair and its hash.
+
+ Use the below command from directory 'cst', with correct options.
+
+ .. code:: shell
+
+ ./gen_keys
+
+Refer fuse frovisioning readme 'nxp-ls-fuse-prov.rst' for steps to blow these keys.
+
+
+
+Two options are provided for TRUSTED_BOARD_BOOT:
+================================================
+
+-------------------------------------------------------------------------
+Option 1: CoT using X 509 certificates
+-------------------------------------------------------------------------
+
+- This CoT is as provided by ARM.
+
+- To use this option user needs to specify mbedtld dir path in MBEDTLS_DIR.
+
+- To generate CSF header, path of CST repository needs to be specified as CST_DIR
+
+- CSF header is embedded to each of the BL2 image.
+
+- GENERATE_COT=1 adds the tool 'cert_create' to the build environment to generate:
+ -- X509 Certificates as (.crt) files.
+ -- X509 Pem key file as (.pem) files.
+
+- SAVE_KEYS=1 saves the keys and certificates, if GENERATE_COT=1.
+ -- For this to work, file name for cert and keys are provided as part of compilation or build command.
+
+ --- default file names will be used, incase not provided as part compilation or build command.
+ --- default folder 'BUILD_PLAT' will be used to store them.
+
+- ROTPK for x.509 certificates is generated and embedded in bl2.bin and
+ verified as part of CoT by Boot ROM during secure boot.
+
+- Compilation steps:
+
+All Images
+ .. code:: shell
+
+ make PLAT=$PLAT TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 MBEDTLS_DIR=$MBEDTLS_PATH CST_DIR=$CST_DIR_PATH \
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ BL32=$TEE_BIN SPD=opteed\
+ BL33=$UBOOT_SECURE_BIN \
+ pbl \
+ fip
+
+Additional FIP_DDR Image (For NXP platforms like lx2160a)
+ .. code:: shell
+
+ make PLAT=$PLAT TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 MBEDTLS_DIR=$MBEDTLS_PATH fip_ddr
+
+ Note: make target 'fip_ddr' should never be combine with other make target 'fip', 'pbl' & 'bl2'.
+
+-------------------------------------------------------------------------
+Option 2: CoT using NXP CSF headers.
+-------------------------------------------------------------------------
+
+- This option is automatically selected when TRUSTED_BOARD_BOOT is set but MBEDTLS_DIR path is not specified.
+
+- CSF header is embedded to each of the BL31, BL32 and BL33 image.
+
+- To generate CSF header, path of CST repository needs to be specified as CST_DIR
+
+- Default input files for CSF header generation is added in this repo.
+
+- Default input file requires user to generate RSA key pair named
+ -- srk.pri, and
+ -- srk.pub, and add them in ATF repo.
+ -- These keys can be generated using gen_keys tool of CST.
+
+- To change the input file , user can use the options BL33_INPUT_FILE, BL32_INPUT_FILE, BL31_INPUT_FILE
+
+- There are 2 paths in secure boot flow :
+ -- Development Mode (sb_en in RCW = 1, SFP->OSPR, ITS = 0)
+
+ --- In this flow , even on ROTPK comparison failure, flow would continue.
+ --- However SNVS is transitioned to non-secure state
+
+ -- Production mode (SFP->OSPR, ITS = 1)
+
+ --- Any failure is fatal failure
+
+- Compilation steps:
+
+All Images
+ .. code:: shell
+
+ make PLAT=$PLAT TRUSTED_BOARD_BOOT=1 CST_DIR=$CST_DIR_PATH \
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ BL32=$TEE_BIN SPD=opteed\
+ BL33=$UBOOT_SECURE_BIN \
+ pbl \
+ fip
+
+Additional FIP_DDR Image (For NXP platforms like lx2160a)
+ .. code:: shell
+
+ make PLAT=$PLAT TRUSTED_BOARD_BOOT=1 CST_DIR=$CST_DIR_PATH fip_ddr
+
+- Compilation Steps with build option for generic image processing filters to prepend CSF header:
+ -- Generic image processing filters to prepend CSF header
+
+ BL32_INPUT_FILE = < file name>
+ BL33_INPUT_FILE = <file name>
+
+ .. code:: shell
+
+ make PLAT=$PLAT TRUSTED_BOARD_BOOT=1 CST_DIR=$CST_DIR_PATH \
+ BOOT_MODE=<platform_supported_boot_mode> \
+ RCW=$RCW_BIN \
+ BL32=$TEE_BIN SPD=opteed\
+ BL33=$UBOOT_SECURE_BIN \
+ BL33_INPUT_FILE = <ip file> \
+ BL32_INPUT_FILE = <ip_file> \
+ BL31_INPUT_FILE = <ip file> \
+ pbl \
+ fip
+
+
+Deploy ATF Images
+=================
+Same steps as mentioned in the readme "nxp-layerscape.rst".
+
+
+
+Verification to check if Secure state is achieved:
+==================================================
+
++---+----------------+-----------------+------------------------+----------------------------------+-------------------------------+
+| | Platform | SNVS_HPSR_REG | SYS_SECURE_BIT(=value) | SYSTEM_SECURE_CONFIG_BIT(=value) | SSM_STATE |
++===+================+=================+========================+==================================+===============================+
+| 1.| lx2160ardb or | 0x01E90014 | 15 | 14-12 | 11-8 |
+| | lx2160aqds or | | ( = 1, BootROM Booted) | ( = 010 means Intent to Secure, | (=1111 means secure boot) |
+| | lx2162aqds | | | ( = 000 Unsecure) | (=1011 means Non-secure Boot) |
++---+----------------+-----------------+------------------------+----------------------------------+-------------------------------+
+
+- Production mode (SFP->OSPR, ITS = 1)
+ -- Linux prompt will successfully come. if the TBBR is successful.
+
+ --- Else, Linux boot will be successful.
+
+ -- For secure-boot status, read SNVS Register $SNVS_HPSR_REG from u-boot prompt:
+
+ .. code:: shell
+
+ md $SNVS_HPSR_REG
+
+ Command Output:
+ 1e90014: 8000AF00
+
+ In case it is read as 00000000, then read this register using jtag (in development mode only through CW tap).
+ +0 +4 +8 +C
+ [0x01E90014] 8000AF00
+
+
+- Development Mode (sb_en in RCW = 1, SFP->OSPR, ITS = 0)
+ -- Refer the SoC specific table to read the register to interpret whether the secure boot is achieved or not.
+ -- Using JTAG (in development environment only, using CW tap):
+
+ --- For secure-boot status, read SNVS Register $SNVS_HPSR_REG
+
+ .. code:: shell
+
+ ccs::display_regs 86 0x01E90014 4 0 1
+
+ Command Output:
+ Using the SAP chain position number 86, following is the output.
+
+ +0 +4 +8 +C
+ [0x01E90014] 8000AF00
+
+ Note: Chain position number will vary from one SoC to other SoC.
+
+- Interpretation of the value:
+
+ -- 0xA indicates BootROM booted, with intent to secure.
+ -- 0xF = secure boot, as SSM_STATE.
diff --git a/docs/plat/qti.rst b/docs/plat/qti.rst
index 814e672..1d483e7 100644
--- a/docs/plat/qti.rst
+++ b/docs/plat/qti.rst
@@ -1,8 +1,8 @@
Qualcomm Technologies, Inc.
===========================
-Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QTI SC7180.
-
+Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QTI SC7180,
+SC7280.
Boot Trace
-------------
@@ -38,4 +38,6 @@
added to satisfy compilation.
QTISELIB for SC7180 is available at
-`link <https://review.coreboot.org/cgit/qc_blobs.git/plain/sc7180/qtiseclib/libqtisec.a>`__
+`link <https://github.com/coreboot/qc_blobs/blob/master/sc7180/qtiseclib/libqtisec.a?raw=true>`__
+QTISELIB for SC7280 is available at
+`link <https://github.com/coreboot/qc_blobs/blob/master/sc7280/qtiseclib/libqtisec.a?raw=true>`__
diff --git a/docs/plat/rpi4.rst b/docs/plat/rpi4.rst
index beb0227..6e83fd7 100644
--- a/docs/plat/rpi4.rst
+++ b/docs/plat/rpi4.rst
@@ -60,7 +60,7 @@
run after the SoC gets its power. The on-chip Boot ROM loads the next stage
(bootcode.bin) from flash (EEPROM), which is again GPU code.
This part knows how to access the MMC controller and how to parse a FAT
-filesystem, so it will load further compononents and configuration files
+filesystem, so it will load further components and configuration files
from the first FAT partition on the SD card.
To accommodate this existing way of configuring and setting up the board,
diff --git a/docs/plat/rz-g2.rst b/docs/plat/rz-g2.rst
new file mode 100644
index 0000000..e7ae620
--- /dev/null
+++ b/docs/plat/rz-g2.rst
@@ -0,0 +1,228 @@
+Renesas RZ/G
+============
+
+The "RZ/G" Family of high-end 64-bit Arm®-based microprocessors (MPUs)
+enables the solutions required for the smart society of the future.
+Through a variety of Arm Cortex®-A53 and A57-based devices, engineers can
+easily implement high-resolution human machine interfaces (HMI), embedded
+vision, embedded artificial intelligence (e-AI) and real-time control and
+industrial ethernet connectivity.
+
+The scalable RZ/G hardware platform and flexible software platform
+cover the full product range, from the premium class to the entry
+level. Plug-ins are available for multiple open-source software tools.
+
+
+Renesas RZ/G2 reference platforms:
+----------------------------------
+
++--------------+----------------------------------------------------------------------------------+
+| Board | Details |
++==============+===============+==================================================================+
+| hihope-rzg2h | "96 boards" compatible board from Hoperun equipped with Renesas RZ/G2H SoC |
+| +----------------------------------------------------------------------------------+
+| | http://hihope.org/product/musashi |
++--------------+----------------------------------------------------------------------------------+
+| hihope-rzg2m | "96 boards" compatible board from Hoperun equipped with Renesas RZ/G2M SoC |
+| +----------------------------------------------------------------------------------+
+| | http://hihope.org/product/musashi |
++--------------+----------------------------------------------------------------------------------+
+| hihope-rzg2n | "96 boards" compatible board from Hoperun equipped with Renesas RZ/G2N SoC |
+| +----------------------------------------------------------------------------------+
+| | http://hihope.org/product/musashi |
++--------------+----------------------------------------------------------------------------------+
+| ek874 | "96 boards" compatible board from Silicon Linux equipped with Renesas RZ/G2E SoC |
+| +----------------------------------------------------------------------------------+
+| | https://www.si-linux.co.jp/index.php?CAT%2FCAT874 |
++--------------+----------------------------------------------------------------------------------+
+
+`boards info <https://www.renesas.com/us/en/products/rzg-linux-platform/rzg-marcketplace/board-solutions.html#rzg2>`__
+
+The current TF-A port has been tested on the HiHope RZ/G2M
+SoC_id r8a774a1 revision ES1.3.
+
+
+::
+
+ ARM CA57 (ARMv8) 1.5 GHz dual core, with NEON/VFPv4, L1$ I/D 48K/32K, L2$ 1MB
+ ARM CA53 (ARMv8) 1.2 GHz quad core, with NEON/VFPv4, L1$ I/D 32K/32K, L2$ 512K
+ Memory controller for LPDDR4-3200 4GB in 2 channels(32-bit bus mode)
+ Two- and three-dimensional graphics engines,
+ Video processing units,
+ Display Output,
+ Video Input,
+ SD card host interface,
+ USB3.0 and USB2.0 interfaces,
+ CAN interfaces,
+ Ethernet AVB,
+ Wi-Fi + BT,
+ PCI Express Interfaces,
+ Memories
+ INTERNAL 384KB SYSTEM RAM
+ DDR 4 GB LPDDR4
+ QSPI FLASH 64MB
+ EMMC 32 GB EMMC (HS400 240 MBYTES/S)
+ MICROSD-CARD SLOT (SDR104 100 MBYTES/S)
+
+Overview
+--------
+On RZ/G2 SoCs the BOOTROM starts the cpu at EL3; for this port BL2
+will therefore be entered at this exception level (the Renesas' ATF
+reference tree [1] resets into EL1 before entering BL2 - see its
+bl2.ld.S)
+
+BL2 initializes DDR before determining the boot reason (cold or warm).
+
+Once BL2 boots, it determines the boot reason, writes it to shared
+memory (BOOT_KIND_BASE) together with the BL31 parameters
+(PARAMS_BASE) and jumps to BL31.
+
+To all effects, BL31 is as if it is being entered in reset mode since
+it still needs to initialize the rest of the cores; this is the reason
+behind using direct shared memory access to BOOT_KIND_BASE _and_
+PARAMS_BASE instead of using registers to get to those locations (see
+el3_common_macros.S and bl31_entrypoint.S for the RESET_TO_BL31 use
+case).
+
+[1] https://github.com/renesas-rz/meta-rzg2/tree/BSP-1.0.5/recipes-bsp/arm-trusted-firmware/files
+
+
+How to build
+------------
+
+The TF-A build options depend on the target board so you will have to
+refer to those specific instructions. What follows is customized to
+the HiHope RZ/G2M development kit used in this port.
+
+Build Tested:
+~~~~~~~~~~~~~
+
+.. code:: bash
+
+ make bl2 bl31 rzg LOG_LEVEL=40 PLAT=rzg LSI=G2M RCAR_DRAM_SPLIT=2\
+ RCAR_LOSSY_ENABLE=1 SPD="none" MBEDTLS_DIR=$mbedtls
+
+System Tested:
+~~~~~~~~~~~~~~
+* mbed_tls:
+ git@github.com:ARMmbed/mbedtls.git [devel]
+
+| commit 72ca39737f974db44723760623d1b29980c00a88
+| Merge: ef94c4fcf dd9ec1c57
+| Author: Janos Follath <janos.follath@arm.com>
+| Date: Wed Oct 7 09:21:01 2020 +0100
+
+* u-boot:
+ The port has beent tested using mainline uboot with HiHope RZ/G2M board
+ specific patches.
+
+| commit 46ce9e777c1314ccb78906992b94001194eaa87b
+| Author: Heiko Schocher <hs@denx.de>
+| Date: Tue Nov 3 15:22:36 2020 +0100
+
+* linux:
+ The port has beent tested using mainline kernel.
+
+| commit f8394f232b1eab649ce2df5c5f15b0e528c92091
+| Author: Linus Torvalds <torvalds@linux-foundation.org>
+| Date: Sun Nov 8 16:10:16 2020 -0800
+| Linux 5.10-rc3
+
+TF-A Build Procedure
+~~~~~~~~~~~~~~~~~~~~
+
+- Fetch all the above 3 repositories.
+
+- Prepare the AARCH64 toolchain.
+
+- Build u-boot using hihope_rzg2_defconfig.
+
+ Result: u-boot-elf.srec
+
+.. code:: bash
+
+ make CROSS_COMPILE=aarch64-linux-gnu-
+ hihope_rzg2_defconfig
+
+ make CROSS_COMPILE=aarch64-linux-gnu-
+
+- Build TF-A
+
+ Result: bootparam_sa0.srec, cert_header_sa6.srec, bl2.srec, bl31.srec
+
+.. code:: bash
+
+ make bl2 bl31 rzg LOG_LEVEL=40 PLAT=rzg LSI=G2M RCAR_DRAM_SPLIT=2\
+ RCAR_LOSSY_ENABLE=1 SPD="none" MBEDTLS_DIR=$mbedtls
+
+
+Install Procedure
+~~~~~~~~~~~~~~~~~
+
+- Boot the board in Mini-monitor mode and enable access to the
+ QSPI flash.
+
+
+- Use the flash_writer utility[2] to flash all the SREC files.
+
+[2] https://github.com/renesas-rz/rzg2_flash_writer
+
+
+Boot trace
+----------
+::
+
+ INFO: ARM GICv2 driver initialized
+ NOTICE: BL2: RZ/G2 Initial Program Loader(CA57) Rev.2.0.6
+ NOTICE: BL2: PRR is RZ/G2M Ver.1.3
+ NOTICE: BL2: Board is HiHope RZ/G2M Rev.4.0
+ NOTICE: BL2: Boot device is QSPI Flash(40MHz)
+ NOTICE: BL2: LCM state is unknown
+ NOTICE: BL2: DDR3200(rev.0.40)
+ NOTICE: BL2: [COLD_BOOT]
+ NOTICE: BL2: DRAM Split is 2ch
+ NOTICE: BL2: QoS is default setting(rev.0.19)
+ NOTICE: BL2: DRAM refresh interval 1.95 usec
+ NOTICE: BL2: Periodic Write DQ Training
+ NOTICE: BL2: CH0: 400000000 - 47fffffff, 2 GiB
+ NOTICE: BL2: CH2: 600000000 - 67fffffff, 2 GiB
+ NOTICE: BL2: Lossy Decomp areas
+ NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570
+ NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0
+ NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0
+ NOTICE: BL2: FDT at 0xe631db30
+ NOTICE: BL2: v2.3(release):v2.4-rc0-2-g1433701e5
+ NOTICE: BL2: Built : 13:45:26, Nov 7 2020
+ NOTICE: BL2: Normal boot
+ INFO: BL2: Doing platform setup
+ INFO: BL2: Loading image id 3
+ NOTICE: BL2: dst=0xe631d200 src=0x8180000 len=512(0x200)
+ NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800)
+ WARNING: r-car ignoring the BL31 size from certificate,using RCAR_TRUSTED_SRAM_SIZE instead
+ INFO: Loading image id=3 at address 0x44000000
+ NOTICE: rcar_file_len: len: 0x0003e000
+ NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=253952(0x3e000)
+ INFO: Image id=3 loaded: 0x44000000 - 0x4403e000
+ INFO: BL2: Loading image id 5
+ INFO: Loading image id=5 at address 0x50000000
+ NOTICE: rcar_file_len: len: 0x00100000
+ NOTICE: BL2: dst=0x50000000 src=0x8300000 len=1048576(0x100000)
+ INFO: Image id=5 loaded: 0x50000000 - 0x50100000
+ NOTICE: BL2: Booting BL31
+ INFO: Entry point address = 0x44000000
+ INFO: SPSR = 0x3cd
+
+
+ U-Boot 2021.01-rc1-00244-gac37e14fbd (Nov 04 2020 - 20:03:34 +0000)
+
+ CPU: Renesas Electronics R8A774A1 rev 1.3
+ Model: HopeRun HiHope RZ/G2M with sub board
+ DRAM: 3.9 GiB
+ MMC: mmc@ee100000: 0, mmc@ee160000: 1
+ Loading Environment from MMC... OK
+ In: serial@e6e88000
+ Out: serial@e6e88000
+ Err: serial@e6e88000
+ Net: eth0: ethernet@e6800000
+ Hit any key to stop autoboot: 0
+ =>
diff --git a/docs/plat/stm32mp1.rst b/docs/plat/stm32mp1.rst
index f597460..af302c6 100644
--- a/docs/plat/stm32mp1.rst
+++ b/docs/plat/stm32mp1.rst
@@ -37,6 +37,17 @@
for ROM code is able to load this image.
Tool stm32image can be used to prepend this header to the generated TF-A binary.
+Boot with FIP
+~~~~~~~~~~~~~
+The use of FIP is now the recommended way to boot STM32MP1 platform.
+Only BL2 (with STM32 header) is loaded by ROM code. The other binaries are
+inside the FIP binary: BL32 (SP_min or OP-TEE), U-Boot and their respective
+device tree blobs.
+
+STM32IMAGE bootchain
+~~~~~~~~~~~~~~~~~~~~
+Although still supported, this way of booting is not recommended.
+Pease use FIP instead.
At compilation step, BL2, BL32 and DTB file are linked together in a single
binary. The stm32image tool is also generated and the header is added to TF-A
binary. This binary file with header is named tf-a-stm32mp157c-ev1.stm32.
@@ -55,15 +66,17 @@
| ... |
| |
0x2FFC0000 +-----------------+ \
- | | |
- | ... | |
- | | |
- 0x2FFD8000 +-----------------+ |
- | TF-A DTB | | Embedded SRAM
- 0x2FFDC000 +-----------------+ |
- | BL2 | |
- 0x2FFEF000 +-----------------+ |
+ | BL32 DTB | |
+ 0x2FFC5000 +-----------------+ |
| BL32 | |
+ 0x2FFDF000 +-----------------+ |
+ | ... | |
+ 0x2FFE3000 +-----------------+ |
+ | BL2 DTB | | Embedded SRAM
+ 0x2FFEA000 +-----------------+ |
+ | BL2 | |
+ 0x2FFFF000 +-----------------+ |
+ | SCMI mailbox | |
0x30000000 +-----------------+ /
| |
| ... |
@@ -95,28 +108,118 @@
------------------
Boot media(s) supported by BL2 must be specified in the build command.
Available storage medias are:
+
- ``STM32MP_SDMMC``
- ``STM32MP_EMMC``
- ``STM32MP_RAW_NAND``
- ``STM32MP_SPI_NAND``
- ``STM32MP_SPI_NOR``
-To build with SP_min and support for all bootable devices:
+Boot with FIP
+~~~~~~~~~~~~~
+You need to build BL2, BL32 (SP_min or OP-TEE) and BL33 (U-Boot) before building FIP binary.
+
+U-Boot
+______
.. code:: bash
- make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=sp_min STM32MP_SDMMC=1 STM32MP_EMMC=1 STM32MP_RAW_NAND=1 STM32MP_SPI_NAND=1
- STM32MP_SPI_NOR=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb
cd <u-boot_directory>
make stm32mp15_trusted_defconfig
make DEVICE_TREE=stm32mp157c-ev1 all
-To build TF-A with OP-TEE support for all bootable devices:
+OP-TEE (optional)
+_________________
+
.. code:: bash
- make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=optee STM32MP_SDMMC=1 STM32MP_EMMC=1 STM32MP_RAW_NAND=1 STM32MP_SPI_NAND=1 STM32MP_SPI_NOR=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb
cd <optee_directory>
- make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm PLATFORM=stm32mp1 CFG_EMBED_DTB_SOURCE_FILE=stm32mp157c-ev1.dts
+ make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm PLATFORM=stm32mp1 \
+ CFG_EMBED_DTB_SOURCE_FILE=stm32mp157c-ev1.dts
+
+
+TF-A BL32 (SP_min)
+__________________
+If you choose not to use OP-TEE, you can use TF-A SP_min.
+To build TF-A BL32, and its device tree file:
+
+.. code:: bash
+
+ make CROSS_COMPILE=arm-none-eabi- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \
+ AARCH32_SP=sp_min DTB_FILE_NAME=stm32mp157c-ev1.dtb bl32 dtbs
+
+TF-A BL2
+________
+To build TF-A BL2 with its STM32 header for SD-card boot:
+
+.. code:: bash
+
+ make CROSS_COMPILE=arm-none-eabi- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \
+ DTB_FILE_NAME=stm32mp157c-ev1.dtb STM32MP_SDMMC=1
+
+For other boot devices, you have to replace STM32MP_SDMMC in the previous command
+with the desired device flag.
+
+This BL2 is independent of the BL32 used (SP_min or OP-TEE)
+
+
+FIP
+___
+With BL32 SP_min:
+
+.. code:: bash
+
+ make CROSS_COMPILE=arm-none-eabi- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \
+ AARCH32_SP=sp_min \
+ DTB_FILE_NAME=stm32mp157c-ev1.dtb \
+ BL33=<u-boot_directory>/u-boot-nodtb.bin \
+ BL33_CFG=<u-boot_directory>/u-boot.dtb \
+ fip
+
+With OP-TEE:
+
+.. code:: bash
+
+ make CROSS_COMPILE=arm-none-eabi- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \
+ AARCH32_SP=optee \
+ DTB_FILE_NAME=stm32mp157c-ev1.dtb \
+ BL33=<u-boot_directory>/u-boot-nodtb.bin \
+ BL33_CFG=<u-boot_directory>/u-boot.dtb \
+ BL32=<optee_directory>/tee-header_v2.bin \
+ BL32_EXTRA1=<optee_directory>/tee-pager_v2.bin
+ BL32_EXTRA2=<optee_directory>/tee-pageable_v2.bin
+ fip
+
+
+STM32IMAGE bootchain
+~~~~~~~~~~~~~~~~~~~~
+You need to add the following flag to the make command:
+``STM32MP_USE_STM32IMAGE=1``
+
+To build with SP_min and support for SD-card boot:
+
+.. code:: bash
+
+ make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \
+ AARCH32_SP=sp_min STM32MP_SDMMC=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb \
+ STM32MP_USE_STM32IMAGE=1
+
+ cd <u-boot_directory>
+ make stm32mp15_trusted_defconfig
+ make DEVICE_TREE=stm32mp157c-ev1 all
+
+To build TF-A with OP-TEE support for SD-card boot:
+
+.. code:: bash
+
+ make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 \
+ AARCH32_SP=optee STM32MP_SDMMC=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb \
+ STM32MP_USE_STM32IMAGE=1
+
+ cd <optee_directory>
+ make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm PLATFORM=stm32mp1 \
+ CFG_EMBED_DTB_SOURCE_FILE=stm32mp157c-ev1.dts
+
cd <u-boot_directory>
make stm32mp15_trusted_defconfig
make DEVICE_TREE=stm32mp157c-ev1 all
@@ -130,7 +233,19 @@
Populate SD-card
----------------
-The SD-card has to be formated with GPT.
+Boot with FIP
+~~~~~~~~~~~~~
+The SD-card has to be formatted with GPT.
+It should contain at least those partitions:
+
+- fsbl: to copy the tf-a-stm32mp157c-ev1.stm32 binary (BL2)
+- fip: which contains the FIP binary
+
+Usually, two copies of fsbl are used (fsbl1 and fsbl2) instead of one partition fsbl.
+
+STM32IMAGE bootchain
+~~~~~~~~~~~~~~~~~~~~
+The SD-card has to be formatted with GPT.
It should contain at least those partitions:
- fsbl: to copy the tf-a-stm32mp157c-ev1.stm32 binary
diff --git a/docs/plat/xilinx-versal.rst b/docs/plat/xilinx-versal.rst
index 57a363b..d65b048 100644
--- a/docs/plat/xilinx-versal.rst
+++ b/docs/plat/xilinx-versal.rst
@@ -19,6 +19,16 @@
make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal VERSAL_PLATFORM=versal_virt bl31
```
+To build TF-A for JTAG DCC console
+```bash
+make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal bl31 VERSAL_CONSOLE=dcc
+```
+
+To build TF-A with Straight-Line Speculation(SLS)
+```bash
+make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal bl31 HARDEN_SLS_ALL=1
+```
+
Xilinx Versal platform specific build options
---------------------------------------------
diff --git a/docs/plat/xilinx-zynqmp.rst b/docs/plat/xilinx-zynqmp.rst
index 5db4488..79c2535 100644
--- a/docs/plat/xilinx-zynqmp.rst
+++ b/docs/plat/xilinx-zynqmp.rst
@@ -22,6 +22,12 @@
make CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp SPD=tspd bl31 bl32
+To build TF-A for JTAG DCC console:
+
+.. code:: bash
+
+ make CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp RESET_TO_BL31=1 bl31 ZYNQMP_CONSOLE=dcc
+
ZynqMP platform specific build options
--------------------------------------
diff --git a/docs/process/coding-style.rst b/docs/process/coding-style.rst
index 94fd85e..be13b14 100644
--- a/docs/process/coding-style.rst
+++ b/docs/process/coding-style.rst
@@ -101,7 +101,7 @@
parentheses.
Control statements (``if``, ``for``, ``switch``, ``while``, etc) must be
-separated from the following open paranthesis by a single space. The previous
+separated from the following open parenthesis by a single space. The previous
example illustrates this for an ``if`` statement.
Line Length
diff --git a/docs/process/contributing.rst b/docs/process/contributing.rst
index 15c2b45..aa050da 100644
--- a/docs/process/contributing.rst
+++ b/docs/process/contributing.rst
@@ -29,6 +29,20 @@
- Make commits of logical units. See these general `Git guidelines`_ for
contributing to a project.
+- Ensure your commit messages comply with the `Conventional Commits`_
+ specification:
+
+ .. code::
+
+ <type>[optional scope]: <description>
+
+ [optional body]
+
+ [optional footer(s)]
+
+ You can use the tooling installed by the optional steps in the
+ :ref:`prerequisites <Prerequisites>` guide to validate this locally.
+
- Keep the commits on topic. If you need to fix another bug or make another
enhancement, please address it on a separate topic branch.
@@ -195,6 +209,65 @@
revert your patches and ask you to resubmit a reworked version of them or
they may ask you to provide a fix-up patch.
+Add Build Configurations
+------------------------
+
+- TF-A uses Jenkins tool for Continuous Integration and testing activities.
+ Various CI Jobs are deployed which run tests on every patch before being
+ merged. So each of your patches go through a series of checks before they
+ get merged on to the master branch.
+
+- ``Coverity Scan analysis`` is one of the tests we perform on our source code
+ at regular intervals. We maintain a build script ``tf-cov-make`` which contains the
+ build configurations of various platforms in order to cover the entire source
+ code being analysed by Coverity.
+
+- When you submit your patches for review containing new source files, please
+ ensure to include them for the ``Coverity Scan analysis`` by adding the
+ respective build configurations in the ``tf-cov-make`` build script.
+
+- In this section you find the details on how to append your new build
+ configurations for Coverity Scan analysis:
+
+#. We maintain a separate repository named `tf-a-ci-scripts repository`_
+ for placing all the test scripts which will be executed by the CI Jobs.
+
+#. In this repository, ``tf-cov-make`` script is located at
+ ``tf-a-ci-scripts/script/tf-coverity/tf-cov-make``
+
+#. Edit `tf-cov-make`_ script by appending all the possible build configurations with
+ the specific ``build-flags`` relevant to your platform, so that newly added
+ source files get built and analysed by Coverity.
+
+#. For better understanding follow the below specified examples listed in the
+ ``tf-cov-make`` script.
+
+.. code:: shell
+
+ Example 1:
+ #Intel
+ make PLAT=stratix10 $(common_flags) all
+ make PLAT=agilex $(common_flags) all
+
+- In the above example there are two different SoCs ``stratix`` and ``agilex``
+ under the Intel platform and the build configurations has been added suitably
+ to include most of their source files.
+
+.. code:: shell
+
+ Example 2:
+ #Hikey
+ make PLAT=hikey $(common_flags) ${TBB_OPTIONS} ENABLE_PMF=1 all
+ make PLAT=hikey960 $(common_flags) ${TBB_OPTIONS} all
+ make PLAT=poplar $(common_flags) all
+
+- In this case for ``Hikey`` boards additional ``build-flags`` has been included
+ along with the ``commom_flags`` to cover most of the files relevant to it.
+
+- Similar to this you can still find many other different build configurations
+ of various other platforms listed in the ``tf-cov-make`` script. Kindly refer
+ them and append your build configurations respectively.
+
Binary Components
-----------------
@@ -214,8 +287,9 @@
--------------
-*Copyright (c) 2013-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.*
+.. _Conventional Commits: https://www.conventionalcommits.org/en/v1.0.0
.. _developer.trustedfirmware.org: https://developer.trustedfirmware.org
.. _review.trustedfirmware.org: https://review.trustedfirmware.org
.. _issue: https://developer.trustedfirmware.org/project/board/1/
@@ -228,3 +302,5 @@
.. _Trusted Firmware binary repository: https://review.trustedfirmware.org/admin/repos/tf-binaries
.. _tf-binaries-readme: https://git.trustedfirmware.org/tf-binaries.git/tree/readme.rst
.. _TF-A mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
+.. _tf-a-ci-scripts repository: https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/
+.. _tf-cov-make: https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tree/script/tf-coverity/tf-cov-make
diff --git a/docs/resources/diagrams/FIP_in_a_GPT_image.png b/docs/resources/diagrams/FIP_in_a_GPT_image.png
new file mode 100644
index 0000000..4bafed9
--- /dev/null
+++ b/docs/resources/diagrams/FIP_in_a_GPT_image.png
Binary files differ
diff --git a/docs/resources/diagrams/MMU-600.png b/docs/resources/diagrams/MMU-600.png
new file mode 100644
index 0000000..9cbc243
--- /dev/null
+++ b/docs/resources/diagrams/MMU-600.png
Binary files differ
diff --git a/docs/resources/diagrams/arm-cca-software-arch.png b/docs/resources/diagrams/arm-cca-software-arch.png
new file mode 100755
index 0000000..979e083
--- /dev/null
+++ b/docs/resources/diagrams/arm-cca-software-arch.png
Binary files differ
diff --git a/docs/resources/diagrams/ff-a-spm-sel2.png b/docs/resources/diagrams/ff-a-spm-sel2.png
index 6479ff5..605fd9b 100644
--- a/docs/resources/diagrams/ff-a-spm-sel2.png
+++ b/docs/resources/diagrams/ff-a-spm-sel2.png
Binary files differ
diff --git a/docs/resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png b/docs/resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png
new file mode 100644
index 0000000..0619cf2
--- /dev/null
+++ b/docs/resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png
Binary files differ
diff --git a/docs/resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png b/docs/resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png
new file mode 100644
index 0000000..f110028
--- /dev/null
+++ b/docs/resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png
Binary files differ
diff --git a/docs/resources/diagrams/ffa-secure-interrupt-handling-nwd.png b/docs/resources/diagrams/ffa-secure-interrupt-handling-nwd.png
new file mode 100755
index 0000000..c318610
--- /dev/null
+++ b/docs/resources/diagrams/ffa-secure-interrupt-handling-nwd.png
Binary files differ
diff --git a/docs/resources/diagrams/ffa-secure-interrupt-handling-swd.png b/docs/resources/diagrams/ffa-secure-interrupt-handling-swd.png
new file mode 100755
index 0000000..b62000d
--- /dev/null
+++ b/docs/resources/diagrams/ffa-secure-interrupt-handling-swd.png
Binary files differ
diff --git a/docs/resources/diagrams/plantuml/fip-secure-partitions.puml b/docs/resources/diagrams/plantuml/fip-secure-partitions.puml
index 40621db..9457e32 100644
--- a/docs/resources/diagrams/plantuml/fip-secure-partitions.puml
+++ b/docs/resources/diagrams/plantuml/fip-secure-partitions.puml
@@ -13,6 +13,7 @@
===
UUID = xxx
load_address = 0xaaa
+ owner = "Sip"
...
]
}
@@ -24,9 +25,26 @@
===
UUID = yyy
load_address = 0xbbb
+ owner = "Plat"
]
}
+artifact tb_fw_config.dts [
+ tb_fw_config.dts
+ ----
+ secure-partitions
+ ===
+ spkg_1 UUID
+ spkg_1 load_address
+ ---
+ spkg_2 UUID
+ spkg_2 load_address
+ ---
+ ...
+ ===
+ ...<rest of the nodes>
+]
+
artifact config.json [
SP_LAYOUT.json
===
@@ -41,31 +59,22 @@
control sp_mk_generator
-artifact fconf_node [
- fconf_sp.dts
- ===
- spkg_1 UUID
- spkg_1 load_address
- ---
- spkg_2 UUID
- spkg_2 load_address
-]
-
artifact sp_gen [
sp_gen.mk
===
FDT_SOURCE = ...
SPTOOL_ARGS = ...
- FIP_ARG = ...
+ FIP_ARGS = ...
+ CRT_ARGS = ...
]
control dtc
control sptool
-artifact FW_CONFIG
+artifact tb_fw_config.dtb
artifact spkg_1 [
- spkg_1.bin
+ sp1.pkg
===
<i>header</i>
---
@@ -75,7 +84,7 @@
]
artifact spkg_2 [
- spkg_2.bin
+ sp2.pkg
===
<i>header</i>
---
@@ -84,18 +93,47 @@
binary
]
+artifact signed_tb_fw_config.dtb [
+ tb_fw_config.dtb (signed)
+]
+
+artifact signed_spkg_1 [
+ sp1.pkg (signed)
+ ===
+ <i>header</i>
+ ---
+ manifest
+ ---
+ binary
+ ---
+ <i>signature</I>
+]
+
+artifact signed_spkg_2 [
+ sp2.pkg (signed)
+ ===
+ <i>header</i>
+ ---
+ manifest
+ ---
+ binary
+ ---
+ <i>signature</I>
+]
+
+control crttool
control fiptool
artifact fip [
fip.bin
===
- FW_CONFIG.dtb
+ tb_fw_config.dtb (signed)
---
...
---
- SPKG1
+ sp1.pkg (signed & SiP owned)
---
- SPKG2
+ sp2.pkg (signed & Platform owned)
---
...
]
@@ -103,20 +141,27 @@
config.json .up.> SP_vendor_1
config.json .up.> SP_vendor_2
config.json --> sp_mk_generator
-sp_mk_generator --> fconf_node
sp_mk_generator --> sp_gen
-
+sp_gen --> fiptool
+sp_gen --> cert_create
sp_gen --> sptool
+
sptool --> spkg_1
sptool --> spkg_2
-fconf_node -down-> dtc
-dtc --> FW_CONFIG
+spkg_1 --> cert_create
+spkg_2 --> cert_create
+cert_create --> signed_spkg_1
+cert_create --> signed_spkg_2
-sp_gen --> fiptool
-FW_CONFIG --> fiptool
-spkg_1 -down-> fiptool
-spkg_2 -down-> fiptool
+tb_fw_config.dts --> dtc
+dtc --> tb_fw_config.dtb
+tb_fw_config.dtb --> cert_create
+cert_create --> signed_tb_fw_config.dtb
+
+signed_tb_fw_config.dtb --> fiptool
+signed_spkg_1 -down-> fiptool
+signed_spkg_2 -down-> fiptool
fiptool -down-> fip
@enduml
diff --git a/docs/resources/diagrams/plantuml/spm_dfd.puml b/docs/resources/diagrams/plantuml/spm_dfd.puml
new file mode 100644
index 0000000..ad4996e
--- /dev/null
+++ b/docs/resources/diagrams/plantuml/spm_dfd.puml
@@ -0,0 +1,82 @@
+/'
+ ' Copyright (c) 2021, Arm Limited. All rights reserved.
+ '
+ ' SPDX-License-Identifier: BSD-3-Clause
+ '/
+
+/'
+TF-A SPMC Data Flow Diagram
+'/
+
+@startuml
+digraph tfa_dfd {
+
+ # Allow arrows to end on cluster boundaries
+ compound=true
+
+ # Default settings for edges and nodes
+ edge [minlen=2 color="#8c1b07"]
+ node [fillcolor="#ffb866" style=filled shape=box fixedsize=true width=1.6 height=0.7]
+
+ # Nodes outside of the trust boundary
+ nsec [label="NS Client"]
+ ddr [label="External memory (DDR)"]
+
+ # Trust boundary cluster
+ subgraph cluster_trusted {
+ graph [style=dashed color="#f22430"]
+
+ # HW IPs cluster
+ subgraph cluster_ip {
+ label ="Hardware IPs";
+ graph [style=filled color="#000000" fillcolor="#ffd29e"]
+
+ rank="same"
+ gic [label="GIC" width=1.2 height=0.5]
+ smmu [label="SMMU" width=1.2 height=0.5]
+ uart [label="UART" width=1.2 height=0.5]
+ pe [label="PE" width=1.2 height=0.5]
+ }
+
+ # TF-A cluster
+ subgraph cluster_tfa {
+ label ="EL3 monitor";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ bl31 [label="BL31" fillcolor="#ddffb3"];
+ spmd [label="SPMD" fillcolor="#ddffb3" height=1]
+ }
+
+ # SPMC cluster
+ subgraph cluster_spmc {
+ label ="SPMC";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ spmc [label="SPMC" fillcolor="#ddffb3" height=1]
+ }
+ bl2 [label="BL2" width=1.2 height=0.5]
+ }
+
+ # Secure Partitions cluster
+ subgraph cluster_sp {
+ label ="Secure Partitions";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ sp1 [label="SP1" fillcolor="#ddffb3" height=1]
+ sp2 [label="SP2" fillcolor="#ddffb3" height=1]
+ spn [label="SP..." fillcolor="#ddffb3" height=1]
+ }
+
+ # Interactions between nodes
+ sp1 -> spmc [dir="both" label="DF1"]
+ spmc -> spmd [dir="both" label="DF2"]
+ spmd -> nsec [dir="both" label="DF3"]
+ sp1 -> sp2 [dir="both" label="DF4"]
+ spmc -> smmu [lhead=cluster_spmc label="DF5"]
+ bl2 -> spmc [lhead=cluster_spmc label="DF6"]
+ bl2 -> spn [lhead=cluster_spmc label="DF6"]
+ sp1 -> ddr [dir="both" label="DF7"]
+ spmc -> ddr [dir="both" label="DF7"]
+}
+
+@enduml
diff --git a/docs/resources/diagrams/plantuml/tfa_dfd.puml b/docs/resources/diagrams/plantuml/tfa_dfd.puml
new file mode 100644
index 0000000..0007911
--- /dev/null
+++ b/docs/resources/diagrams/plantuml/tfa_dfd.puml
@@ -0,0 +1,66 @@
+/'
+ ' Copyright (c) 2021, Arm Limited. All rights reserved.
+ '
+ ' SPDX-License-Identifier: BSD-3-Clause
+ '/
+
+/'
+TF-A Data Flow Diagram
+'/
+
+@startuml
+digraph tfa_dfd {
+
+ # Arrange nodes from left to right
+ rankdir="LR"
+
+ # Allow arrows to end on cluster boundaries
+ compound=true
+
+ # Default settings for edges and nodes
+ edge [minlen=2 color="#8c1b07"]
+ node [fillcolor="#ffb866" style=filled shape=box fixedsize=true width=1.6 height=0.7]
+
+ # Nodes outside of the trust boundary
+ nsec [label="Non-secure\nClients"]
+ sec [label="Secure\nClients"]
+ dbg [label="Debug & Trace"]
+ logs [label="Logs\n(UART)"]
+ nvm [label="Non-volatile\nMemory"]
+
+ # Trust boundary cluster
+ subgraph cluster_trusted{
+ graph [style=dashed color="#f22430"]
+
+ # HW IPs cluster
+ subgraph cluster_ip{
+ label ="Hardware IPs";
+ graph [style=filled color="#000000" fillcolor="#ffd29e"]
+
+ rank="same"
+ gic [label="GIC" width=1.2 height=0.5]
+ tzc [label="TZ\nController" width=1.2 height=0.5]
+ etc [label="..." shape=none style=none height=0.5]
+ }
+
+ # TF-A cluster
+ subgraph cluster_tfa{
+ label ="TF-A";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ bl1 [label="Boot ROM\n(BL1)" fillcolor="#ddffb3"];
+ bl2 [label="Trusted Boot\nFirmware\n(BL2)" fillcolor="#ddffb3" height=1]
+ bl31 [label="TF-A Runtime\n(BL31)" fillcolor="#ddffb3"]
+ }
+ }
+
+ # Interactions between nodes
+ nvm -> bl31 [lhead=cluster_tfa label="DF1"]
+ logs -> bl31 [dir="back" lhead=cluster_tfa label="DF2"]
+ dbg -> bl2 [dir="both" lhead=cluster_tfa label="DF3"]
+ sec -> bl2 [dir="both" lhead=cluster_tfa label="DF4"]
+ nsec -> bl1 [dir="both" lhead=cluster_tfa, label="DF5"]
+ bl2 -> tzc [dir="both" ltail=cluster_tfa lhead=cluster_ip label="DF6" minlen=1]
+}
+
+@enduml
diff --git a/docs/resources/diagrams/spm-threat-model-trust-boundaries.png b/docs/resources/diagrams/spm-threat-model-trust-boundaries.png
new file mode 100644
index 0000000..58898c5
--- /dev/null
+++ b/docs/resources/diagrams/spm-threat-model-trust-boundaries.png
Binary files differ
diff --git a/docs/threat_model/index.rst b/docs/threat_model/index.rst
new file mode 100644
index 0000000..b5ede69
--- /dev/null
+++ b/docs/threat_model/index.rst
@@ -0,0 +1,21 @@
+Threat Model
+============
+
+Threat modeling is an important part of Secure Development Lifecycle (SDL)
+that helps us identify potential threats and mitigations affecting a system.
+
+In the next sections, we first give a description of the target of evaluation
+using a data flow diagram. Then we provide a list of threats we have identified
+based on the data flow diagram and potential threat mitigations.
+
+.. toctree::
+ :maxdepth: 1
+ :caption: Contents
+ :numbered:
+
+ threat_model
+ threat_model_spm
+
+--------------
+
+*Copyright (c) 2021, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
new file mode 100644
index 0000000..4a31e79
--- /dev/null
+++ b/docs/threat_model/threat_model.rst
@@ -0,0 +1,788 @@
+Generic threat model
+********************
+
+************************
+Introduction
+************************
+This document provides a generic threat model for TF-A firmware.
+
+.. note::
+
+ This threat model doesn't consider Root and Realm worlds introduced by
+ :ref:`Realm Management Extension (RME)`.
+
+************************
+Target of Evaluation
+************************
+In this threat model, the target of evaluation is the Trusted
+Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1),
+the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as
+shown on Figure 1. Everything else on Figure 1 is outside of the scope of
+the evaluation.
+
+TF-A can be configured in various ways. In this threat model we consider
+only the most basic configuration. To that end we make the following
+assumptions:
+
+- All TF-A images are run from either ROM or on-chip trusted SRAM. This means
+ TF-A is not vulnerable to an attacker that can probe or tamper with off-chip
+ memory.
+
+- Trusted boot is enabled. This means an attacker can't boot arbitrary images
+ that are not approved by platform providers.
+
+- There is no Secure-EL2. We don't consider threats that may come with
+ Secure-EL2 software.
+
+Data Flow Diagram
+======================
+Figure 1 shows a high-level data flow diagram for TF-A. The diagram
+shows a model of the different components of a TF-A-based system and
+their interactions with TF-A. A description of each diagram element
+is given on Table 1. On the diagram, the red broken lines indicate
+trust boundaries. Components outside of the broken lines
+are considered untrusted by TF-A.
+
+.. uml:: ../resources/diagrams/plantuml/tfa_dfd.puml
+ :caption: Figure 1: TF-A Data Flow Diagram
+
+.. table:: Table 1: TF-A Data Flow Diagram Description
+
+ +-----------------+--------------------------------------------------------+
+ | Diagram Element | Description |
+ +=================+========================================================+
+ | ``DF1`` | | At boot time, images are loaded from non-volatile |
+ | | memory and verified by TF-A boot firmware. These |
+ | | images include TF-A BL2 and BL31 images, as well as |
+ | | other secure and non-secure images. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF2`` | | TF-A log system framework outputs debug messages |
+ | | over a UART interface. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF3`` | | Debug and trace IP on a platform can allow access |
+ | | to registers and memory of TF-A. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF4`` | | Secure world software (e.g. trusted OS) interact |
+ | | with TF-A through SMC call interface and/or shared |
+ | | memory. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF5`` | | Non-secure world software (e.g. rich OS) interact |
+ | | with TF-A through SMC call interface and/or shared |
+ | | memory. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF6`` | | This path represents the interaction between TF-A and|
+ | | various hardware IPs such as TrustZone controller |
+ | | and GIC. At boot time TF-A configures/initializes the|
+ | | IPs and interacts with them at runtime through |
+ | | interrupts and registers. |
+ +-----------------+--------------------------------------------------------+
+
+
+*********************
+Threat Analysis
+*********************
+In this section we identify and provide assessment of potential threats to TF-A
+firmware. The threats are identified for each diagram element on the
+data flow diagram above.
+
+For each threat, we identify the *asset* that is under threat, the
+*threat agent* and the *threat type*. Each threat is given a *risk rating*
+that represents the impact and likelihood of that threat. We also discuss
+potential mitigations.
+
+Assets
+==================
+We have identified the following assets for TF-A:
+
+.. table:: Table 2: TF-A Assets
+
+ +--------------------+---------------------------------------------------+
+ | Asset | Description |
+ +====================+===================================================+
+ | ``Sensitive Data`` | | These include sensitive data that an attacker |
+ | | must not be able to tamper with (e.g. the Root |
+ | | of Trust Public Key) or see (e.g. secure logs, |
+ | | debugging information such as crash reports). |
+ +--------------------+---------------------------------------------------+
+ | ``Code Execution`` | | This represents the requirement that the |
+ | | platform should run only TF-A code approved by |
+ | | the platform provider. |
+ +--------------------+---------------------------------------------------+
+ | ``Availability`` | | This represents the requirement that TF-A |
+ | | services should always be available for use. |
+ +--------------------+---------------------------------------------------+
+
+Threat Agents
+=====================
+To understand the attack surface, it is important to identify potential
+attackers, i.e. attack entry points. The following threat agents are
+in scope of this threat model.
+
+.. table:: Table 3: Threat Agents
+
+ +-------------------+-------------------------------------------------------+
+ | Threat Agent | Description |
+ +===================+=======================================================+
+ | ``NSCode`` | | Malicious or faulty code running in the Non-secure |
+ | | world, including NS-EL0 NS-EL1 and NS-EL2 levels |
+ +-------------------+-------------------------------------------------------+
+ | ``SecCode`` | | Malicious or faulty code running in the secure |
+ | | world, including S-EL0 and S-EL1 levels |
+ +-------------------+-------------------------------------------------------+
+ | ``AppDebug`` | | Physical attacker using debug signals to access |
+ | | TF-A resources |
+ +-------------------+-------------------------------------------------------+
+ | ``PhysicalAccess``| | Physical attacker having access to external device |
+ | | communication bus and to external flash |
+ | | communication bus using common hardware |
+ +-------------------+-------------------------------------------------------+
+
+.. note::
+
+ In this threat model an advanced physical attacker that has the capability
+ to tamper with a hardware (e.g. "rewiring" a chip using a focused
+ ion beam (FIB) workstation or decapsulate the chip using chemicals) is
+ considered out-of-scope.
+
+Threat Types
+========================
+In this threat model we categorize threats using the `STRIDE threat
+analysis technique`_. In this technique a threat is categorized as one
+or more of these types: ``Spoofing``, ``Tampering``, ``Repudiation``,
+``Information disclosure``, ``Denial of service`` or
+``Elevation of privilege``.
+
+Threat Risk Ratings
+========================
+For each threat identified, a risk rating that ranges
+from *informational* to *critical* is given based on the likelihood of the
+threat occuring if a mitigation is not in place, and the impact of the
+threat (i.e. how severe the consequences could be). Table 4 explains each
+rating in terms of score, impact and likelihood.
+
+.. table:: Table 4: Rating and score as applied to impact and likelihood
+
+ +-----------------------+-------------------------+---------------------------+
+ | **Rating (Score)** | **Impact** | **Likelihood** |
+ +=======================+=========================+===========================+
+ | ``Critical (5)`` | | Extreme impact to | | Threat is almost |
+ | | entire organization | certain to be exploited.|
+ | | if exploited. | |
+ | | | | Knowledge of the threat |
+ | | | and how to exploit it |
+ | | | are in the public |
+ | | | domain. |
+ +-----------------------+-------------------------+---------------------------+
+ | ``High (4)`` | | Major impact to entire| | Threat is relatively |
+ | | organization or single| easy to detect and |
+ | | line of business if | exploit by an attacker |
+ | | exploited | with little skill. |
+ +-----------------------+-------------------------+---------------------------+
+ | ``Medium (3)`` | | Noticeable impact to | | A knowledgeable insider |
+ | | line of business if | or expert attacker could|
+ | | exploited. | exploit the threat |
+ | | | without much difficulty.|
+ +-----------------------+-------------------------+---------------------------+
+ | ``Low (2)`` | | Minor damage if | | Exploiting the threat |
+ | | exploited or could | would require |
+ | | be used in conjunction| considerable expertise |
+ | | with other | and resources |
+ | | vulnerabilities to | |
+ | | perform a more serious| |
+ | | attack | |
+ +-----------------------+-------------------------+---------------------------+
+ | ``Informational (1)`` | | Poor programming | | Threat is not likely |
+ | | practice or poor | to be exploited on its |
+ | | design decision that | own, but may be used to |
+ | | may not represent an | gain information for |
+ | | immediate risk on its | launching another |
+ | | own, but may have | attack |
+ | | security implications | |
+ | | if multiplied and/or | |
+ | | combined with other | |
+ | | threats. | |
+ +-----------------------+-------------------------+---------------------------+
+
+Aggregate risk scores are assigned to identified threats;
+specifically, the impact score multiplied by the likelihood score.
+For example, a threat with high likelihood and low impact would have an
+aggregate risk score of eight (8); that is, four (4) for high likelihood
+multiplied by two (2) for low impact. The aggregate risk score determines
+the finding's overall risk level, as shown in the following table.
+
+.. table:: Table 5: Overall risk levels and corresponding aggregate scores
+
+ +---------------------+-----------------------------------+
+ | Overall Risk Level | Aggregate Risk Score |
+ | | (Impact multiplied by Likelihood) |
+ +=====================+===================================+
+ | Critical | 20–25 |
+ +---------------------+-----------------------------------+
+ | High | 12–19 |
+ +---------------------+-----------------------------------+
+ | Medium | 6–11 |
+ +---------------------+-----------------------------------+
+ | Low | 2–5 |
+ +---------------------+-----------------------------------+
+ | Informational | 1 |
+ +---------------------+-----------------------------------+
+
+The likelihood and impact of a threat depends on the
+target environment in which TF-A is running. For example, attacks
+that require physical access are unlikely in server environments while
+they are more common in Internet of Things(IoT) environments.
+In this threat model we consider three target environments:
+``Internet of Things(IoT)``, ``Mobile`` and ``Server``.
+
+Threat Assessment
+============================
+The following threats were identified by applying STRIDE analysis on
+each diagram element of the data flow diagram.
+
++------------------------+----------------------------------------------------+
+| ID | 01 |
++========================+====================================================+
+| ``Threat`` | | **An attacker can mangle firmware images to |
+| | execute arbitrary code** |
+| | |
+| | | Some TF-A images are loaded from external |
+| | storage. It is possible for an attacker to access|
+| | the external flash memory and change its contents|
+| | physically, through the Rich OS, or using the |
+| | updating mechanism to modify the non-volatile |
+| | images to execute arbitrary code. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Code Execution |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering, Elevation of Privilege |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Critical (25) | Critical (25) | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | | TF-A implements the `Trusted Board Boot (TBB)`_ |
+| | feature which prevents malicious firmware from |
+| | running on the platform by authenticating all |
+| | firmware images. In addition to this, the TF-A |
+| | boot firmware performs extra checks on |
+| | unauthenticated data, such as FIP metadata, prior|
+| | to use. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 02 |
++========================+====================================================+
+| ``Threat`` | | **An attacker may attempt to boot outdated, |
+| | potentially vulnerable firmware image** |
+| | |
+| | | When updating firmware, an attacker may attempt |
+| | to rollback to an older version that has unfixed |
+| | vulnerabilities. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Code Execution |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Critical (25) | Critical (25) | Critical (25) |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | | TF-A supports anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. After a firmware|
+| | image is validated, the image revision number |
+| | taken from a certificate extension field is |
+| | compared with the corresponding NV counter stored|
+| | in hardware to make sure the new counter value is|
+| | larger or equal to the current counter value. |
+| | Platforms must implement this protection using |
+| | platform specific hardware NV counters. |
++------------------------+----------------------------------------------------+
+
++------------------------+-------------------------------------------------------+
+| ID | 03 |
++========================+=======================================================+
+| ``Threat`` | | **An attacker can use Time-of-Check-Time-of-Use |
+| | (TOCTOU) attack to bypass image authentication |
+| | during the boot process** |
+| | |
+| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur |
+| | when the security check is produced before the time |
+| | the resource is accessed. If an attacker is sitting |
+| | in the middle of the off-chip images, they could |
+| | change the binary containing executable code right |
+| | after the integrity and authentication check has |
+| | been performed. |
++------------------------+-------------------------------------------------------+
+| ``Diagram Elements`` | DF1 |
++------------------------+-------------------------------------------------------+
+| ``Affected TF-A | BL1, BL2 |
+| Components`` | |
++------------------------+-------------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+-------------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| ``Threat Type`` | Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+---------------------+-----------------+---------------+
+| ``Impact`` | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| ``Likelihood`` | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| ``Total Risk Rating`` | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| ``Mitigations`` | | TF-A boot firmware copies image to on-chip |
+| | memory before authenticating an image. |
++------------------------+-------------------------------------------------------+
+
++------------------------+-------------------------------------------------------+
+| ID | 04 |
++========================+=======================================================+
+| ``Threat`` | | **An attacker with physical access can execute |
+| | arbitrary image by bypassing the signature |
+| | verification stage using glitching techniques** |
+| | |
+| | | Glitching (Fault injection) attacks attempt to put |
+| | a hardware into a undefined state by manipulating an|
+| | environmental variable such as power supply. |
+| | |
+| | | TF-A relies on a chain of trust that starts with the|
+| | ROTPK, which is the key stored inside the chip and |
+| | the root of all validation processes. If an attacker|
+| | can break this chain of trust, they could execute |
+| | arbitrary code on the device. This could be |
+| | achieved with physical access to the device by |
+| | attacking the normal execution flow of the |
+| | process using glitching techniques that target |
+| | points where the image is validated against the |
+| | signature. |
++------------------------+-------------------------------------------------------+
+| ``Diagram Elements`` | DF1 |
++------------------------+-------------------------------------------------------+
+| ``Affected TF-A | BL1, BL2 |
+| Components`` | |
++------------------------+-------------------------------------------------------+
+| ``Assets`` | Code Execution |
++------------------------+-------------------------------------------------------+
+| ``Threat Agent`` | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| ``Threat Type`` | Tampering, Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+---------------------+-----------------+---------------+
+| ``Impact`` | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| ``Likelihood`` | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| ``Total Risk Rating`` | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| ``Mitigations`` | | The most effective mitigation is adding glitching |
+| | detection and mitigation circuit at the hardware |
+| | level. However, software techniques, |
+| | such as adding redundant checks when performing |
+| | conditional branches that are security sensitive, |
+| | can be used to harden TF-A against such attacks. |
+| | **At the moment TF-A doesn't implement such |
+| | mitigations.** |
++------------------------+-------------------------------------------------------+
+
++------------------------+---------------------------------------------------+
+| ID | 05 |
++========================+===================================================+
+| ``Threat`` | | **Information leak via UART logs such as |
+| | crashes** |
+| | |
+| | | During the development stages of software it is |
+| | common to include crash reports with detailed |
+| | information of the CPU state including current |
+| | values of the registers, privilege level and |
+| | stack dumps. This information is useful when |
+| | debugging problems before releasing the |
+| | production version, but it could be used by an |
+| | attacker to develop a working exploit if left |
+| | in the production version. |
++------------------------+---------------------------------------------------+
+| ``Diagram Elements`` | DF2 |
++------------------------+---------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+---------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+---------------------------------------------------+
+| ``Threat Agent`` | AppDebug |
++------------------------+---------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+------------------+----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+----------------+---------------+
+| ``Impact`` | N/A | Low (2) | Low (2) |
++------------------------+------------------+----------------+---------------+
+| ``Likelihood`` | N/A | High (4) | High (4) |
++------------------------+------------------+----------------+---------------+
+| ``Total Risk Rating`` | N/A | Medium (8) | Medium (8) |
++------------------------+------------------+----------------+---------------+
+| ``Mitigations`` | | In TF-A, crash reporting is only enabled for |
+| | debug builds by default. Alternatively, the log |
+| | level can be tuned at build time (from verbose |
+| | to no output at all), independently of the |
+| | build type. |
++------------------------+---------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 06 |
++========================+====================================================+
+| ``Threat`` | | **An attacker can read sensitive data and |
+| | execute arbitrary code through the external |
+| | debug and trace interface** |
+| | |
+| | | Arm processors include hardware-assisted debug |
+| | and trace features that can be controlled without|
+| | the need for software operating on the platform. |
+| | If left enabled without authentication, this |
+| | feature can be used by an attacker to inspect and|
+| | modify TF-A registers and memory allowing the |
+| | attacker to read sensitive data and execute |
+| | arbitrary code. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF3 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | AppDebug |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering, Information Disclosure, |
+| | Elevation of privilege |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | N/A | High (4) | High (4) |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | N/A | Critical (5) | Critical (5) |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | N/A | Critical (20) | Critical (20) |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | | Configuration of debug and trace capabilities is |
+| | platform specific. Therefore, platforms must |
+| | disable the debug and trace capability for |
+| | production releases or enable proper debug |
+| | authentication as recommended by [`DEN0034`_]. |
++------------------------+----------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 07 |
++========================+======================================================+
+| ``Threat`` | | **An attacker can perform a denial-of-service |
+| | attack by using a broken SMC call that causes the |
+| | system to reboot or enter into unknown state.** |
+| | |
+| | | Secure and non-secure clients access TF-A services |
+| | through SMC calls. Malicious code can attempt to |
+| | place the TF-A runtime into an inconsistent state |
+| | by calling unimplemented SMC call or by passing |
+| | invalid arguments. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Availability |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Denial of Service |
++------------------------+-------------------+----------------+-----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+----------------+-----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+-----------------+
+| ``Likelihood`` | High (4) | High (4) | High (4) |
++------------------------+-------------------+----------------+-----------------+
+| ``Total Risk Rating`` | High (12) | High (12) | High (12) |
++------------------------+-------------------+----------------+-----------------+
+| ``Mitigations`` | | The generic TF-A code validates SMC function ids |
+| | and arguments before using them. |
+| | Platforms that implement SiP services must also |
+| | validate SMC call arguments. |
++------------------------+------------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 08 |
++========================+======================================================+
+| ``Threat`` | | **Memory corruption due to memory overflows and |
+| | lack of boundary checking when accessing resources |
+| | could allow an attacker to execute arbitrary code, |
+| | modify some state variable to change the normal |
+| | flow of the program, or leak sensitive |
+| | information** |
+| | |
+| | | Like in other software, the Trusted Firmware has |
+| | multiple points where memory corruption security |
+| | errors can arise. Memory corruption is a dangerous |
+| | security issue since it could allow an attacker |
+| | to execute arbitrary code, modify some state |
+| | variable to change the normal flow of the program, |
+| | or leak sensitive information. |
+| | |
+| | | Some of the errors include integer overflow, |
+| | buffer overflow, incorrect array boundary checks, |
+| | and incorrect error management. |
+| | Improper use of asserts instead of proper input |
+| | validations might also result in these kinds of |
+| | errors in release builds. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Tampering, Information Disclosure, |
+| | Elevation of Privilege |
++------------------------+-------------------+-----------------+----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+-----------------+----------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-------------------+-----------------+----------------+
+| ``Likelihood`` | Medium (3 | Medium (3) | Medium (3) |
++------------------------+-------------------+-----------------+----------------+
+| ``Total Risk Rating`` | High (15) | High (15) | High (15) |
++------------------------+-------------------+-----------------+----------------+
+| ``Mitigations`` | | TF-A uses a combination of manual code reviews and |
+| | automated program analysis and testing to detect |
+| | and fix memory corruption bugs. All TF-A code |
+| | including platform code go through manual code |
+| | reviews. Additionally, static code analysis is |
+| | performed using Coverity Scan on all TF-A code. |
+| | The code is also tested with |
+| | `Trusted Firmware-A Tests`_ on Juno and FVP |
+| | platforms. |
+| | |
+| | | Data received from normal world, such as addresses |
+| | and sizes identifying memory regions, are |
+| | sanitized before being used. These security checks |
+| | make sure that the normal world software does not |
+| | access memory beyond its limit. |
+| | |
+| | | By default *asserts* are only used to check for |
+| | programming errors in debug builds. Other types of |
+| | errors are handled through condition checks that |
+| | remain enabled in release builds. See |
+| | `TF-A error handling policy`_. TF-A provides an |
+| | option to use *asserts* in release builds, however |
+| | we recommend using proper runtime checks instead |
+| | of relying on asserts in release builds. |
++------------------------+------------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 09 |
++========================+======================================================+
+| ``Threat`` | | **Improperly handled SMC calls can leak register |
+| | contents** |
+| | |
+| | | When switching between secure and non-secure |
+| | states, register contents of Secure world or |
+| | register contents of other normal world clients |
+| | can be leaked. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+-----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+----------------+-----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+-----------------+
+| ``Likelihood`` | High (4) | High (4) | High (4) |
++------------------------+-------------------+----------------+-----------------+
+| ``Total Risk Rating`` | High (12) | High (12) | High (12) |
++------------------------+-------------------+----------------+-----------------+
+| ``Mitigations`` | | TF-A saves and restores registers |
+| | by default when switching contexts. Build options |
+| | are also provided to save/restore additional |
+| | registers such as floating-point registers. |
++------------------------+------------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| ID | 10 |
++========================+=====================================================+
+| ``Threat`` | | **SMC calls can leak sensitive information from |
+| | TF-A memory via microarchitectural side channels**|
+| | |
+| | | Microarchitectural side-channel attacks such as |
+| | `Spectre`_ can be used to leak data across |
+| | security boundaries. An attacker might attempt to |
+| | use this kind of attack to leak sensitive |
+| | data from TF-A memory. |
++------------------------+-----------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+-----------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| ``Threat Agent`` | SecCode, NSCode |
++------------------------+-----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+----------------+----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Total Risk Rating`` | Medium (9) | Medium (9) | Medium (9) |
++------------------------+-------------------+----------------+----------------+
+| ``Mitigations`` | | TF-A implements software mitigations for Spectre |
+| | type attacks as recommended by `Cache Speculation |
+| | Side-channels`_ for the generic code. SiPs should |
+| | implement similar mitigations for code that is |
+| | deemed to be vulnerable to such attacks. |
++------------------------+-----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| ``Threat`` | | **Misconfiguration of the Memory Management Unit |
+| | (MMU) may allow a normal world software to |
+| | access sensitive data or execute arbitrary |
+| | code** |
+| | |
+| | | A misconfiguration of the MMU could |
+| | lead to an open door for software running in the |
+| | normal world to access sensitive data or even |
+| | execute code if the proper security mechanisms |
+| | are not in place. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF5, DF6 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Sensitive Data, Code execution |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure, Elevation of Privilege |
++------------------------+-----------------+-----------------+----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-----------------+-----------------+----------------+
+| ``Impact`` | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-----------------+-----------------+----------------+
+| ``Likelihood`` | High (4) | High (4) | High (4) |
++------------------------+-----------------+-----------------+----------------+
+| ``Total Risk Rating`` | Critical (20) | Critical (20) | Critical (20) |
++------------------------+-----------------+-----------------+----------------+
+| ``Mitigations`` | | In TF-A, configuration of the MMU is done |
+| | through a translation tables library. The |
+| | library provides APIs to define memory regions |
+| | and assign attributes including memory types and |
+| | access permissions. Memory configurations are |
+| | platform specific, therefore platforms need make |
+| | sure the correct attributes are assigned to |
+| | memory regions. When assigning access |
+| | permissions, principle of least privilege ought |
+| | to be enforced, i.e. we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, RO data should |
+| | be read-only XN, and so on. |
++------------------------+----------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| ID | 12 |
++========================+=====================================================+
+| ``Threat`` | | **Incorrect configuration of Performance Monitor |
+| | Unit (PMU) counters can allow an attacker to |
+| | mount side-channel attacks using information |
+| | exposed by the counters** |
+| | |
+| | | Non-secure software can configure PMU registers |
+| | to count events at any exception level and in |
+| | both Secure and Non-secure states. This allows |
+| | a Non-secure software (or a lower-level Secure |
+| | software) to potentially carry out |
+| | side-channel timing attacks against TF-A. |
++------------------------+-----------------------------------------------------+
+| ``Diagram Elements`` | DF5, DF6 |
++------------------------+-----------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+-----------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+-----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Likelihood`` | Low (2) | Low (2) | Low (2) |
++------------------------+-------------------+----------------+----------------+
+| ``Total Risk Rating`` | Medium (6) | Medium (6) | Medium (6) |
++------------------------+-------------------+----------------+----------------+
+| ``Mitigations`` | | TF-A follows mitigation strategies as described |
+| | in `Secure Development Guidelines`_. General |
+| | events and cycle counting in the Secure world is |
+| | prohibited by default when applicable. However, |
+| | on some implementations (e.g. PMUv3) Secure world |
+| | event counting depends on external debug interface|
+| | signals, i.e. Secure world event counting is |
+| | enabled if external debug is enabled. |
+| | Configuration of debug signals is platform |
+| | specific, therefore platforms need to make sure |
+| | that external debug is disabled in production or |
+| | proper debug authentication is in place. |
++------------------------+-----------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
+
+
+.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
+.. _DEN0034: https://developer.arm.com/documentation/den0034/latest
+.. _Cache Speculation Side-channels: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _TBBR-Client specification: https://developer.arm.com/documentation/den0006/d/
+.. _Trusted Board Boot (TBB): https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html
+.. _TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness
+.. _Secure Development Guidelines: https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardening.html#secure-development-guidelines
+.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/
diff --git a/docs/threat_model/threat_model_spm.rst b/docs/threat_model/threat_model_spm.rst
new file mode 100644
index 0000000..82f9916
--- /dev/null
+++ b/docs/threat_model/threat_model_spm.rst
@@ -0,0 +1,617 @@
+SPMC threat model
+*****************
+
+************************
+Introduction
+************************
+This document provides a threat model for the TF-A `Secure Partition Manager`_
+(SPM) implementation or more generally the S-EL2 reference firmware running on
+systems implementing the FEAT_SEL2 (formerly Armv8.4 Secure EL2) architecture
+extension. The SPM implementation is based on the `Arm Firmware Framework for
+Arm A-profile`_ specification.
+
+In brief, the broad FF-A specification and S-EL2 firmware implementation
+provide:
+
+- Isolation of mutually mistrusting SW components, or endpoints in the FF-A
+ terminology.
+- Distinct sandboxes in the secure world called secure partitions. This permits
+ isolation of services from multiple vendors.
+- A standard protocol for communication and memory sharing between FF-A
+ endpoints.
+- Mutual is
