GitLab

The GIC driver initialization currently allows an array of interrupts to
be configured as secure. Future use cases would require more interrupt
configuration other than just security, such as priority.

This patch introduces a new interrupt property array as part of both
GICv2 and GICv3 driver data. The platform can populate the array with
interrupt numbers and respective properties. The corresponding driver
initialization iterates through the array, and applies interrupt
configuration as required.

This capability, and the current way of supplying array (or arrays, in
case of GICv3) of secure interrupts, are however mutually exclusive.
Henceforth, the platform should supply either:

  - A list of interrupts to be mapped as secure (the current way).
    Platforms that do this will continue working as they were. With this
    patch, this scheme is deprecated.

  - A list of interrupt properties (properties include interrupt group).
    Individual interrupt properties are specified via. descriptors of
    type 'interrupt_prop_desc_t', which can be populated with the macro
    INTR_PROP_DESC().

A run time assert checks that the platform doesn't specify both.

Henceforth the old scheme of providing list of secure interrupts is
deprecated. When built with ERROR_DEPRECATED=1, GIC drivers will require
that the interrupt properties are supplied instead of an array of secure
interrupts.

Add a section to firmware design about configuring secure interrupts.

Fixes ARM-software/tf-issues#262

Change-Id: I8eec29e72eb69dbb6bce77879febf32c95376942
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Update DEN0006B-5(2013) to DEN0006C-1(2015)

Change-Id: I753a14214dde827d004fd04c47b5ba112df38d73
Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>

This patch adds documentation about the new PCSI API to the porting guide
and it also update the version and function list in the firmware design.

Change-Id: Ie4edd190926a501922c061f5fcad53c9b389e331
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

This patch enables the CnP (Common not Private) bit for secure page
tables so that multiple PEs in the same Inner Shareable domain can use
the same translation table entries for a given stage of translation in
a particular translation regime. This only takes effect when ARM
Trusted Firmware is built with ARM_ARCH_MINOR >= 2.

ARM Trusted Firmware Design has been updated to include a description
of this feature usage.

Change-Id: I698305f047400119aa1900d34c65368022e410b8
Signed-off-by: Isla Mitchell <isla.mitchell@arm.com>

The format conversion wrongly formatted a couple of sections. These were
also missing from the Table of Contents.

Change-Id: I324216c27e7b4711e6cc5e25782f4b53842140cc
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Change-Id: I00fae047dea0eaf7e60037598af020817c66f659
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>

The documentation describes the design of the translation tables
library version 2 used by the ARM Trusted Firmware.

The diagram file has been created with Dia version 0.97.2. This tool
can be obtained from: https://wiki.gnome.org/Apps/Dia/Download



Inkscape has been used to generate the *.png file from the *.dia file
to work around a bug in the generation of *.png files in some versions
of Dia.

Change-Id: Ie67d9998d4ae881b2c060200a318ad3ac2fa5e91
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

Non-automated fixes to the converted documentation.

Change-Id: I61f3d37c7a8d6a56a7351048060b970c5b3751e4
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Due to recent issues in the rendering of the documentation on GitHub and
some long-standing issues like the lack of automatic table of content in
Markdown, the documentation has been converted to reStructuredText.
Basic constructs looks pretty similar to Markdown.

Automatically convert GitHub markdown documentation to reStructuredText
using pandoc.

Change-Id: If20b695acedc6d1b49c8d9fb64efd6b6ba23f4a9
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Change some hard-to-convert constructs to cleaner ones.
Fix a broken link.

Change-Id: Ida70aa1da0af7a107b0e05eb20b8d46669a0380b
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Without the additional newlines all the text becomes a single paragraph
and next newlines are ignored.

Change-Id: I783198477f654e3923fcabb21248f2bc62c33e9d
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>

This patch updates the el3_arch_init_common macro so that it fully
initialises essential control registers rather then relying on hardware
to set the reset values.

The context management functions are also updated to fully initialise
the appropriate control registers when initialising the non-secure and
secure context structures and when preparing to leave EL3 for a lower
EL.

This gives better alignement with the ARM ARM which states that software
must initialise RES0 and RES1 fields with 0 / 1.

This patch also corrects the following typos:

"NASCR definitions" -> "NSACR definitions"

Change-Id: Ia8940b8351dc27bc09e2138b011e249655041cfc
Signed-off-by: David Cunado <david.cunado@arm.com>

Change-Id: Ic0a9b3c6d212e7171b37f944e11f079282dcce87
Signed-off-by: Summer Qin <summer.qin@arm.com>

Since Issue B (November 2016) of the SMC Calling Convention document
standard SMC calls are renamed to yielding SMC calls to help avoid
confusion with the standard service SMC range, which remains unchanged.

http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf



This patch adds a new define for yielding SMC call type and deprecates
the current standard SMC call type. The tsp is migrated to use this new
terminology and, additionally, the documentation and code comments are
updated to use this new terminology.

Change-Id: I0d7cc0224667ee6c050af976745f18c55906a793
Signed-off-by: David Cunado <david.cunado@arm.com>

Fixes ARM-software/tf-issues#463

Change-Id: I73e0c5fbd87004953df8b1fa19319ad562ecc867
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

The ARMv8v.1 architecture extension has introduced support for far
atomics, which includes compare-and-swap. Compare and Swap instruction
is only available for AArch64.

Introduce build options to choose the architecture versions to target
ARM Trusted Firmware:

  - ARM_ARCH_MAJOR: selects the major version of target ARM
    Architecture. Default value is 8.

  - ARM_ARCH_MINOR: selects the minor version of target ARM
    Architecture. Default value is 0.

When:

  (ARM_ARCH_MAJOR > 8) || ((ARM_ARCH_MAJOR == 8) && (ARM_ARCH_MINOR >= 1)),

for AArch64, Compare and Swap instruction is used to implement spin
locks. Otherwise, the implementation falls back to using
load-/store-exclusive instructions.

Update user guide, and introduce a section in Firmware Design guide to
summarize support for features introduced in ARMv8 Architecture
Extensions.

Change-Id: I73096a0039502f7aef9ec6ab3ae36680da033f16
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Introduce zeromem_dczva function on AArch64 that can handle unaligned
addresses and make use of DC ZVA instruction to zero a whole block at a
time. This zeroing takes place directly in the cache to speed it up
without doing external memory access.

Remove the zeromem16 function on AArch64 and replace it with an alias to
zeromem. This zeromem16 function is now deprecated.

Remove the 16-bytes alignment constraint on __BSS_START__ in
firmware-design.md as it is now not mandatory anymore (it used to comply
with zeromem16 requirements).

Change the 16-bytes alignment constraints in SP min's linker script to a
8-bytes alignment constraint as the AArch32 zeromem implementation is now
more efficient on 8-bytes aligned addresses.

Introduce zero_normalmem and zeromem helpers in platform agnostic header
that are implemented this way:
* AArch32:
	* zero_normalmem: zero using usual data access
	* zeromem: alias for zero_normalmem
* AArch64:
	* zero_normalmem: zero normal memory  using DC ZVA instruction
	                  (needs MMU enabled)
	* zeromem: zero using usual data access

Usage guidelines: in most cases, zero_normalmem should be preferred.

There are 2 scenarios where zeromem (or memset) must be used instead:
* Code that must run with MMU disabled (which means all memory is
  considered device memory for data accesses).
* Code that fills device memory with null bytes.

Optionally, the following rule can be applied if performance is
important:
* Code zeroing small areas (few bytes) that are not secrets should use
  memset to take advantage of compiler optimizations.

  Note: Code zeroing security-related critical information should use
  zero_normalmem/zeromem instead of memset to avoid removal by
  compilers' optimizations in some cases or misbehaving versions of GCC.

Fixes ARM-software/tf-issues#408

Change-Id: Iafd9663fc1070413c3e1904e54091cf60effaa82
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

The errata reporting policy is as follows:

  - If an errata workaround is enabled:

    - If it applies (i.e. the CPU is affected by the errata), an INFO
      message is printed, confirming that the errata workaround has been
      applied.

    - If it does not apply, a VERBOSE message is printed, confirming
      that the errata workaround has been skipped.

  - If an errata workaround is not enabled, but would have applied had
    it been, a WARN message is printed, alerting that errata workaround
    is missing.

The CPU errata messages are printed by both BL1 (primary CPU only) and
runtime firmware on debug builds, once for each CPU/errata combination.

Relevant output from Juno r1 console when ARM Trusted Firmware is built
with PLAT=juno LOG_LEVEL=50 DEBUG=1:

  VERBOSE: BL1: cortex_a57: errata workaround for 806969 was not applied
  VERBOSE: BL1: cortex_a57: errata workaround for 813420 was not applied
  INFO:    BL1: cortex_a57: errata workaround for disable_ldnp_overread was applied
  WARNING: BL1: cortex_a57: errata workaround for 826974 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 826977 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 828024 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 829520 was missing!
  WARNING: BL1: cortex_a57: errata workaround for 833471 was missing!
  ...
  VERBOSE: BL31: cortex_a57: errata workaround for 806969 was not applied
  VERBOSE: BL31: cortex_a57: errata workaround for 813420 was not applied
  INFO:    BL31: cortex_a57: errata workaround for disable_ldnp_overread was applied
  WARNING: BL31: cortex_a57: errata workaround for 826974 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 826977 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 828024 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 829520 was missing!
  WARNING: BL31: cortex_a57: errata workaround for 833471 was missing!
  ...
  VERBOSE: BL31: cortex_a53: errata workaround for 826319 was not applied
  INFO:    BL31: cortex_a53: errata workaround for disable_non_temporal_hint was applied

Also update documentation.

Change-Id: Iccf059d3348adb876ca121cdf5207bdbbacf2aba
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Various CPU drivers in ARM Trusted Firmware register functions to handle
power-down operations. At present, separate functions are registered to
power down individual cores and clusters.

This scheme operates on the basis of core and cluster, and doesn't cater
for extending the hierarchy for power-down operations. For example,
future CPUs might support multiple threads which might need powering
down individually.

This patch therefore reworks the CPU operations framework to allow for
registering power down handlers on specific level basis. Henceforth:

  - Generic code invokes CPU power down operations by the level
    required.

  - CPU drivers explicitly mention CPU_NO_RESET_FUNC when the CPU has no
    reset function.

  - CPU drivers register power down handlers as a list: a mandatory
    handler for level 0, and optional handlers for higher levels.

All existing CPU drivers are adapted to the new CPU operations framework
without needing any functional changes within.

Also update firmware design guide.

Change-Id: I1826842d37a9e60a9e85fdcee7b4b8f6bc1ad043
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

Fix a link broken by a missing space that turned
it into a link to an non-existent anchor.

Change-Id: Ie863e963db28afa3a28b69d3f63bd7638bdf5af9
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>

Add a Performance Measurement Framework (PMF) section
to the firmware design document.

Change-Id: I5953bd3b1067501f190164c8827d2b0d8022fc0b
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

This patch updates the firmware-design.md for AArch32 related changes.

Change-Id: Idf392a44861ab9c1f59f3de4f3435f508b17c678

This patch adds the PSCI library integration guide for AArch32 ARMv8-A
systems `psci-lib-integration-guide.md` to the documentation. The
patch also adds appropriate reference to the new document in
the `firmware-design.md` document.

Change-Id: I2d5b5c6b612452371713399702e318e3c73a8ee0

This patch adds support for NODE_HW_STATE PSCI API by introducing a new
PSCI platform hook (get_node_hw_state). The implementation validates
supplied arguments, and then invokes this platform-defined hook and
returns its result to the caller. PSCI capabilities are updated
accordingly.

Also updates porting and firmware design guides.

Change-Id: I808e55bdf0c157002a7c104b875779fe50a68a30

fiptool provides a more consistent and intuitive interface compared to
the fip_create program.  It serves as a better base to build on more
features in the future.

fiptool supports various subcommands.  Below are the currently
supported subcommands:

1) info   - List the images contained in a FIP file.
2) create - Create a new FIP file with the given images.
3) update - Update an existing FIP with the given images.
4) unpack - Extract a selected set or all the images from a FIP file.
5) remove - Remove images from a FIP file.  This is a new command that
   was not present in fip_create.

To create a new FIP file, replace "fip_create" with "fiptool create".

To update a FIP file, replace "fip_create" with "fiptool update".

To dump the contents of a FIP file, replace "fip_create --dump" with
"fiptool info".

A compatibility script that emulates the basic functionality of
fip_create is provided.  Existing scripts might or might not work with
the compatibility script.  Users are strongly encouraged to migrate to
fiptool.

Fixes ARM-Software/tf-issues#87
Fixes ARM-Software/tf-issues#108
Fixes ARM-Software/tf-issues#361

Change-Id: I7ee4da7ac60179cc83cf46af890fd8bc61a53330

This patch documents the effect, cost and benefits of the
SEPARATE_CODE_AND_RODATA build flag.

Change-Id: Ic8daf0563fa6335930ad6c70b9c35f678e84d39d

This patch moves the PSCI services and BL31 frameworks like context
management and per-cpu data into new library components `PSCI` and
`el3_runtime` respectively. This enables PSCI to be built independently from
BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant
PSCI library sources and gets included by `bl31.mk`. Other changes which
are done as part of this patch are:

* The runtime services framework is now moved to the `common/` folder to
  enable reuse.
* The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture
  specific folder.
* The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder
  to `plat/common` folder. The original file location now has a stub which
  just includes the file from new location to maintain platform compatibility.

Most of the changes wouldn't affect platform builds as they just involve
changes to the generic bl1.mk and bl31.mk makefiles.

NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT
THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR
MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION.

Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86

At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.

This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.

This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.

 - When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
   the read-only section still looks like this (padding omitted):

   |        ...        |
   +-------------------+
   | Exception vectors |
   +-------------------+
   |  Read-only data   |
   +-------------------+
   |       Code        |
   +-------------------+ BLx_BASE

   In this case, the linker script provides the limits of the whole
   read-only section.

 - When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
   read-only data are swapped, such that the code and exception
   vectors are contiguous, followed by the read-only data. This
   gives the following new layout (padding omitted):

   |        ...        |
   +-------------------+
   |  Read-only data   |
   +-------------------+
   | Exception vectors |
   +-------------------+
   |       Code        |
   +-------------------+ BLx_BASE

   In this case, the linker script now exports 2 sets of addresses
   instead: the limits of the code and the limits of the read-only
   data. Refer to the Firmware Design guide for more details. This
   provides platform code with a finer-grained view of the image
   layout and allows it to map these 2 regions with the appropriate
   access permissions.

Note that SEPARATE_CODE_AND_RODATA applies to all BL images.

Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49

This patch adds a new linker symbol in BL1's linker script named
'__BL1_ROM_END__', which marks the end of BL1's ROM content. This
covers BL1's code, read-only data and read-write data to relocate
in Trusted SRAM. The address of this new linker symbol is exported
to C code through the 'BL1_ROM_END' macro.

The section related to linker symbols in the Firmware Design guide
has been updated and improved.

Change-Id: I5c442ff497c78d865ffba1d7d044511c134e11c7

This patch adds following optional PSCI STAT functions:

- PSCI_STAT_RESIDENCY: This call returns the amount of time spent
  in power_state in microseconds, by the node represented by the
  `target_cpu` and the highest level of `power_state`.

- PSCI_STAT_COUNT: This call returns the number of times a
  `power_state` has been used by the node represented by the
  `target_cpu` and the highest power level of `power_state`.

These APIs provides residency statistics for power states that has
been used by the platform. They are implemented according to v1.0
of the PSCI specification.

By default this optional feature is disabled in the PSCI
implementation. To enable it, set the boolean flag
`ENABLE_PSCI_STAT` to 1. This also sets `ENABLE_PMF` to 1.

Change-Id: Ie62e9d37d6d416ccb1813acd7f616d1ddd3e8aff

This patch enables the SCR_EL3.SIF (Secure Instruction Fetch) bit in BL1 and
BL31 common architectural setup code. When in secure state, this disables
instruction fetches from Non-secure memory.

NOTE: THIS COULD BREAK PLATFORMS THAT HAVE SECURE WORLD CODE EXECUTING FROM
NON-SECURE MEMORY, BUT THIS IS CONSIDERED UNLIKELY AND IS A SERIOUS SECURITY
RISK.

Fixes ARM-Software/tf-issues#372

Change-Id: I684e84b8d523c3b246e9a5fabfa085b6405df319

Asynchronous abort exceptions generated by the platform during cold boot are
not taken in EL3 unless SCR_EL3.EA is set.

Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture
initialisation. Further write accesses to SCR_EL3 preserve these bits during
cold boot.

A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions
being trapped by EL3 after cold boot or not.

For further reference SError Interrupts are also known as asynchronous external
aborts.

On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in
EL3 whatever the SCR_EL3.EA value is.

Fixes arm-software/tf-issues#368
Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>

The Firmware Design document is meant to provide a general overview
of the Trusted Firmware code. Although it is useful to provide some
guidance around the responsibilities of the platform layer, it should
not provide too much platform specific implementation details. Right
now, some sections are too tied to the implementation on ARM
platforms. This makes the Firmware Design document harder to digest.

This patch simplifies this aspect of the Firmware Design document.
The sections relating the platform initialisations performed by the
different BL stages have been simplified and the extra details about
the ARM platforms implementation have been moved to the Porting Guide
when appropriate.

This patch also provides various documentation fixes and additions
in the Firmware Design and Platform Porting Guide. In particular:

 - Update list of SMCs supported by BL1.

 - Remove MMU setup from architectural inits, as it is actually
   performed by platform code.

 - Similarly, move runtime services initialisation, BL2 image
   initialization and BL33 execution out of the platform
   initialisation paragraph.

 - List SError interrupt unmasking as part of BL1 architectural
   initialization.

 - Mention Trusted Watchdog enabling in BL1 on ARM platforms.

 - Fix order of steps in "BL2 image load and execution" section.

 - Refresh section about GICv3/GICv2 drivers initialisation on
   ARM platforms.

Change-Id: I32113c4ffdc26687042629cd8bbdbb34d91e3c14

This patch adds a brief explanation of the top/bottom load approach
to the Firmware Design guide and how Trusted Firmware keeps track of
the free memory at boot time. This will help platform developers to
avoid unexpected results in the memory layout.

Fixes ARM-software/tf-issues#319

Change-Id: I04be7e24c1f3b54d28cac29701c24bf51a5c00ad

Since commit 804040d1, the Juno port has moved from per-CPU mailboxes
to a single shared one. This patch updates an out-dated reference to
the former per-CPU mailboxes mechanism in the Firmware Design.

Change-Id: I355b54156b1ace1b3df4c4416e1e8625211677fc

Change-Id: I4fcdb8e813e0392c2cd3d0623698e8319b3b0593

This patch fixes a couple of issues in the "CPU specific operations
framework" section in the Firmware Design document.

 * Fix broken link to the CPU Specific Build Macros document.

 * Fix the path to the cortex_a53.S file.

 * Fix power levels terminology.

Change-Id: Ib610791eaba13dab2823b7699bb63534bcd1c8fb

Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b

This patch adds design documentation for the Firmware Update (FWU)
feature in `firmware-update.md`. It provides an overview of FWU,
describes the BL1 SMC interface, and includes diagrams showing
an example FWU boot flow and the FWU state machine.

This patch also updates the existing TF documents where needed:

*   `porting-guide.md`
*   `user-guide.md`
*   `firmware-design.md`
*   `rt-svc-writers-guide.md`
*   `trusted_board_boot.md`

Change-Id: Ie6de31544429b18f01327bd763175e218299a4ce
Co-Authored-By: Dan Handley <dan.handley@arm.com>

This patch introduces a new document presenting the ARM Trusted
Firmware Reset Design. It shows the reset code flow, lists the
different build options that affect it, in which case to use them
and what their exact effect is.

The section about using BL31 entrypoint as the reset address has
been moved from the general firmware design document to this one.
It's also been improved to explain why the FVP port supports the
RESET_TO_BL31 configuration, even though the reset vector address
can't be programmed dynamically.

This document includes some images, which have been generated using
Dia version 0.97.2. This tool can be obtained from:
https://wiki.gnome.org/Apps/Dia/Download
This patch provides:
 - the image files describing the different reset flow diagrams;
 - the source '.dia' file;
 - a script automating the generation of the images from the '.dia'
   file.
Note that the 2 latter files are not actually needed for the document
and are provided for convenience only, in case the reset images need
to be modified.

Change-Id: Ib6302e8209d418a5b31c4e85e55fd9e83caf2ca2