Skip to content

GitLab

"vscode:/vscode.git/clone" did not exist on "8c95c52353118643ac3dbd9b0c185a3129b84bf8"
Commit f8e3340c authored by Paul Beesley's avatar Paul Beesley Committed by TrustedFirmware Code Review
Browse files

Merge changes from topic "pb/readthedocs" into integration 

* changes:
  doc: Add guide for building the docs locally
  doc: De-duplicate readme and license files
  doc: Convert internal links to RST format
parents 4fdad60c 862c764a
Show whitespace changes
Inline Side-by-side
docs/getting_started/user-guide.rst
View file @ f8e3340c
......@@ -22,7 +22,7 @@ the different software components required to boot a Linux system:
This document also assumes that the user is familiar with the `FVP models`_ and
the different command line options available to launch the model.
This document should be used in conjunction with the `Firmware Design`_.
This document should be used in conjunction with the :ref:`Firmware Design`.
Host machine requirements
-------------------------
......@@ -86,8 +86,8 @@ Trusted Firmware follows the `Linux Coding Style`_ . When making changes to the
source, for submission to the project, the source must be in compliance with
this style guide.
Additional, project-specific guidelines are defined in the `Trusted Firmware-A
Coding Guidelines`_ document.
Additional, project-specific guidelines are defined in the
:ref:`Coding Style & Guidelines` document.
To assist with coding style compliance, the project Makefile contains two
targets which both utilise the `checkpatch.pl` script that ships with the Linux
......@@ -196,7 +196,7 @@ Building TF-A
an AArch32 EL3 Runtime Software. Some AArch32 EL3 Runtime Software may
include other runtime services, for example Trusted OS services. A guide
to integrate PSCI library with AArch32 EL3 Runtime Software can be found
`here`_.
at :ref:`PSCI Library Integration guide for Armv8-A AArch32 systems`.
- (AArch64 only) The TSP (Test Secure Payload), corresponding to the BL32
image, is not compiled in by default. Refer to the
......@@ -262,11 +262,11 @@ Common build options
- ``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
`Firmware Design`_.
:ref:`Firmware Design`.
- ``ARM_ARCH_MINOR``: The minor version of Arm Architecture to target when
compiling TF-A. Its value must be a numeric, and defaults to 0. See also,
*Armv8 Architecture Extensions* in `Firmware Design`_.
*Armv8 Architecture Extensions* in :ref:`Firmware Design`.
- ``BL2``: This is an optional build option which specifies the path to BL2
image for the ``fip`` target. In this case, the BL2 in the TF-A will not be
......@@ -479,7 +479,7 @@ Common build options
is AArch32.
- ``ENABLE_SPM`` : Boolean option to enable the Secure Partition Manager (SPM).
Refer to the `Secure Partition Manager Design guide`_ for more details about
Refer to :ref:`Secure Partition Manager` for more details about
this feature. Default is 0.
- ``ENABLE_SVE_FOR_NS``: Boolean option to enable Scalable Vector Extension
......@@ -527,7 +527,7 @@ Common build options
- ``GENERATE_COT``: Boolean flag used to build and execute the ``cert_create``
tool to create certificates as per the Chain of Trust described in
`Trusted Board Boot`_. The build system then calls ``fiptool`` to
:ref:`Trusted Board Boot`. The build system then calls ``fiptool`` to
include the certificates in the FIP and FWU_FIP. Default value is '0'.
Specify both ``TRUSTED_BOARD_BOOT=1`` and ``GENERATE_COT=1`` to include support
......@@ -745,8 +745,8 @@ Common build options
- ``SEPARATE_CODE_AND_RODATA``: Whether code and read-only data should be
isolated on separate memory pages. This is a trade-off between security and
memory usage. See "Isolating code and read-only data on separate memory
pages" section in `Firmware Design`_. This flag is disabled by default and
affects all BL images.
pages" section in :ref:`Firmware Design`. This flag is disabled by default
and affects all BL images.
- ``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
......@@ -784,7 +784,7 @@ Common build options
- ``TSP_INIT_ASYNC``: Choose BL32 initialization method as asynchronous or
synchronous, (see "Initializing a BL32 Image" section in
`Firmware Design`_). It can take the value 0 (BL32 is initialized using
:ref:`Firmware Design`). It can take the value 0 (BL32 is initialized using
synchronous method) or 1 (BL32 is initialized using asynchronous method).
Default is 0.
......@@ -808,14 +808,14 @@ Common build options
- ``USE_COHERENT_MEM``: This flag determines whether to include the coherent
memory region in the BL memory map or not (see "Use of Coherent memory in
TF-A" section in `Firmware Design`_). It can take the value 1
TF-A" section in :ref:`Firmware Design`). It can take the value 1
(Coherent memory region is included) or 0 (Coherent memory region is
excluded). Default is 1.
- ``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
reduces SRAM usage. Refer to `Library at ROM`_ for further details. Default
is 0.
reduces SRAM usage. Refer to :ref:`Library at ROM` for further details.
Default is 0.
- ``USE_SPINLOCK_CAS``: Setting this build flag to 1 selects the spinlock
implementation variant using the ARMv8.1-LSE compare-and-swap instruction.
......@@ -924,7 +924,7 @@ Arm development platform specific build options
SBROM library must be specified via ``CCSBROM_LIB_PATH`` flag.
For a better understanding of these options, the Arm development platform memory
map is explained in the `Firmware Design`_.
map is explained in the :ref:`Firmware Design`.
Arm CSS platform specific build options
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
......@@ -978,14 +978,14 @@ Arm FVP platform specific build options
The default value is 0.
- ``FVP_HW_CONFIG_DTS`` : Specify the path to the DTS file to be compiled
to DTB and packaged in FIP as the HW_CONFIG. See `Firmware Design`_ for
to DTB and packaged in FIP as the HW_CONFIG. See :ref:`Firmware Design` for
details on HW_CONFIG. By default, this is initialized to a sensible DTS
file in ``fdts/`` folder depending on other build options. But some cases,
like shifted affinity format for MPIDR, cannot be detected at build time
and this option is needed to specify the appropriate DTS file.
- ``FVP_HW_CONFIG`` : Specify the path to the HW_CONFIG blob to be packaged in
FIP. See `Firmware Design`_ for details on HW_CONFIG. This option is
FIP. See :ref:`Firmware Design` for details on HW_CONFIG. This option is
similar to the ``FVP_HW_CONFIG_DTS`` option, but it directly specifies the
HW_CONFIG blob instead of the DTS file. This option is useful to override
the default HW_CONFIG selected by the build system.
......@@ -1017,7 +1017,7 @@ optimizations by using ``-O0``.
.. warning::
Using ``-O0`` could cause output images to be larger and base addresses
might need to be recalculated (see the **Memory layout on Arm development
platforms** section in the `Firmware Design`_).
platforms** section in the :ref:`Firmware Design`).
Extra debug options can be passed to the build system by setting ``CFLAGS`` or
``LDFLAGS``:
......@@ -1058,7 +1058,8 @@ Building the Test Secure Payload
The TSP is coupled with a companion runtime service in the BL31 firmware,
called the TSPD. Therefore, if you intend to use the TSP, the BL31 image
must be recompiled as well. For more information on SPs and SPDs, see the
`Secure-EL1 Payloads and Dispatchers`_ section in the `Firmware Design`_.
:ref:`Secure-EL1 Payloads and Dispatchers <firmware_design_sel1_spd>` section
in the :ref:`Firmware Design` document.
First clean the TF-A build directory to get rid of any previous BL31 binary.
Then to build the TSP image use:
......@@ -1176,15 +1177,15 @@ remove operations will automatically overwrite it.
The unpack operation will fail if the images already exist at the
destination. In that case, use -f or --force to continue.
More information about FIP can be found in the `Firmware Design`_ document.
More information about FIP can be found in the :ref:`Firmware Design` document.
Building FIP images with support for Trusted Board Boot
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trusted Board Boot primarily consists of the following two features:
- Image Authentication, described in `Trusted Board Boot`_, and
- Firmware Update, described in `Firmware Update`_
- Image Authentication, described in :ref:`Trusted Board Boot`, and
- Firmware Update, described in :ref:`Firmware Update (FWU)`
The following steps should be followed to build FIP and (optionally) FWU_FIP
images with support for these features:
......@@ -1250,9 +1251,9 @@ images with support for these features:
in the output build directory.
#. The optional FWU_FIP contains any additional images to be loaded from
Non-Volatile storage during the `Firmware Update`_ process. To build the
FWU_FIP, any FWU images required by the platform must be specified on the
command line. On Arm development platforms like Juno, these are:
Non-Volatile storage during the :ref:`Firmware Update (FWU)` process. To
build the FWU_FIP, any FWU images required by the platform must be specified
on the command line. On Arm development platforms like Juno, these are:
- NS_BL2U. The AP non-secure Firmware Updater image.
- SCP_BL2U. The SCP Firmware Update Configuration image.
......@@ -1731,6 +1732,8 @@ The Trusted Firmware must be compiled in a similar way as for FVP explained
above. The process to load binaries to memory is the one explained in
`Booting an EL3 payload on Juno`_.
.. _user_guide_run_fvp:
Running the software on FVP
---------------------------
......@@ -1903,7 +1906,7 @@ Notes:
- BL1 is loaded at the start of the Trusted ROM.
- The Firmware Image Package is loaded at the start of NOR FLASH0.
- The firmware loads the FDT packaged in FIP to the DRAM. The FDT load address
is specified via the ``hw_config_addr`` property in `TB_FW_CONFIG for FVP`_.
is specified via the ``hw_config_addr`` property in ``TB_FW_CONFIG`` for FVP.
- The default use-case for the Foundation FVP is to use the ``--gicv3`` option
and enable the GICv3 device in the model. Note that without this option,
the Foundation FVP defaults to legacy (Versatile Express) memory map which
......@@ -2204,18 +2207,9 @@ wakeup interrupt from RTC.
.. _`Linux Coding Style`: https://www.kernel.org/doc/html/latest/process/coding-style.html
.. _Linux master tree: https://github.com/torvalds/linux/tree/master/
.. _Dia: https://wiki.gnome.org/Apps/Dia/Download
.. _here: psci-lib-integration-guide.rst
.. _Trusted Board Boot: ../design/trusted-board-boot.rst
.. _TB_FW_CONFIG for FVP: ../../plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts
.. _Secure-EL1 Payloads and Dispatchers: ../design/firmware-design.rst#user-content-secure-el1-payloads-and-dispatchers
.. _Firmware Update: ../components/firmware-update.rst
.. _Firmware Design: ../design/firmware-design.rst
.. _mbed TLS Repository: https://github.com/ARMmbed/mbedtls.git
.. _mbed TLS Security Center: https://tls.mbed.org/security
.. _Arm's website: `FVP models`_
.. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-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
.. _Secure Partition Manager Design guide: ../components/secure-partition-manager-design.rst
.. _`Trusted Firmware-A Coding Guidelines`: ../process/coding-guidelines.rst
.. _Library at ROM: ../components/romlib-design.rst
docs/index.rst
View file @ f8e3340c
......@@ -43,10 +43,9 @@ states.
Users are encouraged to do their own security validation, including penetration
testing, on any secure world code derived from TF-A.
Arm will continue development in collaboration with interested parties to
provide a full reference implementation of Secure Monitor code and Arm standards
to the benefit of all developers working with Armv7-A and Armv8-A TrustZone
technology.
In collaboration with interested parties, we will continue to enhance |TF-A|
with reference implementations of Arm standards to benefit developers working
with Armv7-A and Armv8-A TrustZone technology.
Functionality
-------------
......@@ -133,15 +132,16 @@ Functionality
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 ``ENABLE_PAUTH``
build flag to be set.
experimental configuration at this time and requires the
``BRANCH_PROTECTION`` option to be set to non-zero.
- Position-Independent Executable (PIE) support. Initially for BL31 only, with
further support to be added in a future release.
For a full description of functionality and implementation details, please
see the `Firmware Design`_ and supporting documentation. The `Change Log`_
provides details of changes made since the last release.
see :ref:`Firmware Design` and supporting documentation. The
:ref:`Change Log & Release Notes` provides details of changes made since the
last release.
Platforms
---------
......@@ -242,31 +242,32 @@ Still to come
- Ongoing security hardening, optimization and quality improvements.
For a full list of detailed issues in the current code, please see the `Change
Log`_ and the `issue tracker`_.
For a full list of detailed issues in the current code, please see the
:ref:`Change Log & Release Notes` and the `issue tracker`_.
Getting started
---------------
See the `User Guide`_ for instructions on how to download, install, build and
use TF-A with the Arm `FVP`_\ s.
See the :ref:`User Guide` for instructions on how to download, install, build
and use TF-A with the Arm `FVP`_\ s.
See the `Firmware Design`_ for information on how TF-A works.
See the :ref:`Firmware Design` for information on how TF-A works.
See the `Porting Guide`_ as well for information about how to use this
See the :ref:`Porting Guide` as well for information about how to use this
software on another Armv7-A or Armv8-A platform.
See the `Contributing Guidelines`_ for information on how to contribute to this
project and the `Acknowledgments`_ file for a list of contributors to the
project.
See the :ref:`Contributor's Guide` for information on how to contribute to this
project and the :ref:`Contributor Acknowledgements` file for a list of
contributors to the project.
Contact us
Contact Us
~~~~~~~~~~
We welcome any feedback on TF-A. If you think you have found a security
vulnerability, please report this using the process defined in the TF-A
`Security Center`_. For all other feedback, you can use either the
`issue tracker`_ or our `mailing list`_.
:ref:`Security Handling` document.
For all other feedback, please use the `issue tracker`_ or our `mailing list`_.
Arm licensees may contact Arm directly via their partner managers.
......@@ -294,11 +295,3 @@ Arm licensees may contact Arm directly via their partner managers.
.. _trustedfirmware.org: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
.. _issue tracker: https://issues.trustedfirmware.org
.. _mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
.. _Security Center: ./process/security.rst
.. _license: ./license.rst
.. _Contributing Guidelines: ./process/contributing.rst
.. _Acknowledgments: ./acknowledgements.rst
.. _Firmware Design: ./design/firmware-design.rst
.. _Change Log: ./change-log.rst
.. _User Guide: ./getting_started/user-guide.rst
.. _Porting Guide: ./getting_started/porting-guide.rst
docs/license.rst
View file @ f8e3340c
......@@ -3,7 +3,7 @@ License
The software is provided under a BSD-3-Clause license (below). Contributions to
this project are accepted under the same license with developer sign-off as
described in the :ref:`contributor_guide`.
described in the :ref:`Contributor's Guide`.
::
......
docs/plat/socionext-uniphier.rst
View file @ f8e3340c
......@@ -8,10 +8,11 @@ UniPhier SoC family implements its internal boot ROM, which loads 64KB [1]_
image from a non-volatile storage to the on-chip SRAM, and jumps over to it.
TF-A provides a special mode, BL2-AT-EL3, which enables BL2 to execute at EL3.
It is useful for platforms with non-TF-A boot ROM, like UniPhier. Here, a
problem is BL2 does not fit in the 64KB limit if `Trusted Board Boot`_ (TBB)
is enabled. To solve this issue, Socionext provides a first stage loader
called `UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the
DRAM, expands BL2 there, and hands the control over to it. Therefore, all images
problem is BL2 does not fit in the 64KB limit if
:ref:`Trusted Board Boot (TBB) <Trusted Board Boot>` is enabled.
To solve this issue, Socionext provides a first stage loader called
`UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the DRAM,
expands BL2 there, and hands the control over to it. Therefore, all images
of TF-A run in DRAM.
The UniPhier platform works with/without TBB. See below for the build process
......@@ -50,7 +51,7 @@ Boot Flow
4. BL31, BL32, and BL33
They all run in the DRAM. See `Firmware Design`_ for details.
They all run in the DRAM. See :ref:`Firmware Design` for details.
Basic Build
......@@ -79,7 +80,7 @@ Optional features
- Trusted Board Boot
`mbed TLS`_ is needed as the cryptographic and image parser modules.
Refer to the `User Guide`_ for the appropriate version of mbed TLS.
Refer to the :ref:`User Guide` for the appropriate version of mbed TLS.
To enable TBB, add the following options to the build command::
......@@ -109,9 +110,6 @@ Optional features
.. [1] Some SoCs can load 80KB, but the software implementation must be aligned
to the lowest common denominator.
.. _Trusted Board Boot: ../trusted-board-boot.rst
.. _UniPhier BL: https://github.com/uniphier/uniphier-bl
.. _Firmware Design: ../firmware-design.rst
.. _U-Boot: https://www.denx.de/wiki/U-Boot
.. _mbed TLS: https://tls.mbed.org/
.. _User Guide: ../user-guide.rst
docs/process/contributing.rst
View file @ f8e3340c
......@@ -13,8 +13,8 @@ Getting Started
raise a separate `issue`_ for this and ensure that the changes that
include Third Party IP are made on a separate topic branch.
- Clone `Trusted Firmware-A`_ on your own machine as suggested on the
`User Guide`_.
- Clone `Trusted Firmware-A`_ on your own machine as suggested in the
:ref:`User Guide`.
- Create a local topic branch based on the `Trusted Firmware-A`_ ``master``
branch.
......@@ -23,11 +23,11 @@ Making Changes
- Make commits of logical units. See these general `Git guidelines`_ for
contributing to a project.
- Follow the `Coding Guidelines`_.
- Follow the :ref:`Coding Style & Guidelines`.
- Use the checkpatch.pl script provided with the Linux source tree. A
Makefile target is provided for convenience (see the "Checking source code
style" section in the `User Guide`_).
style" section in the :ref:`User Guide`).
- Keep the commits on topic. If you need to fix another bug or make another
enhancement, please create a separate `issue`_ and address it on a separate
......@@ -38,12 +38,12 @@ Making Changes
an `issue`_, include a reference.
- Where appropriate, please update the documentation.
- Consider whether the `User Guide`_, `Porting Guide`_, `Firmware Design`_
or other in-source documentation needs updating.
- Consider whether the :ref:`User Guide`, :ref:`Porting Guide`,
:ref:`Firmware Design` or other in-source documentation needs updating.
- Ensure that each changed file has the correct copyright and license
information. Files that entirely consist of contributions to this
project should have a copyright notice and BSD-3-Clause SPDX license
identifier of the form as shown in `license.rst`_. Files that contain
identifier of the form as shown in :ref:`license`. Files that contain
changes to imported Third Party IP files should retain their original
copyright and license notices. For significant contributions you may
add your own copyright notice in following format:
......@@ -57,13 +57,13 @@ Making Changes
your company name.
- If you are submitting new files that you intend to be the technical
sub-maintainer for (for example, a new platform port), then also update
the `Maintainers`_ file.
the :ref:`maintainers` file.
- For topics with multiple commits, you should make all documentation
changes (and nothing else) in the last commit of the series. Otherwise,
include the documentation changes within the single commit.
- Please test your changes. As a minimum, ensure that Linux boots on the
Foundation FVP. See `Running the software on FVP`_ for more information. For
Foundation FVP. See :ref:`user_guide_run_fvp` for more information. For
more extensive testing, consider running the `TF-A Tests`_ against your
patches.
......@@ -75,13 +75,14 @@ Submitting Changes
``Signed-off-by:`` and ``Author:`` lines must match. If anyone else
contributes to the commit, they must also add their own ``Signed-off-by:``
line. By adding this line the contributor certifies the contribution is made
under the terms of the `Developer Certificate of Origin (DCO)`_.
under the terms of the
:download:`Developer Certificate of Origin <../../dco.txt>`.
More details may be found in the `Gerrit Signed-off-by Lines guidelines`_.
- Ensure that each commit also has a unique ``Change-Id:`` line. If you have
cloned the repository with the "`Clone with commit-msg hook`" clone method
(as advised on the `User Guide`_), this should already be the case.
(as advised on the :ref:`User Guide`), this should already be the case.
More details may be found in the `Gerrit Change-Ids documentation`_.
......@@ -89,22 +90,22 @@ Submitting Changes
targeting the ``integration`` branch.
- The changes will then undergo further review and testing by the
`Maintainers`_. Any review comments will be made directly on your patch.
This may require you to do some rework.
:ref:`maintainers`. Any review comments will be made directly on your
patch. This may require you to do some rework.
Refer to the `Gerrit Uploading Changes documentation`_ for more details.
- When the changes are accepted, the `Maintainers`_ will integrate them.
- When the changes are accepted, the :ref:`maintainers` will integrate them.
- Typically, the `Maintainers`_ will merge the changes into the
- Typically, the :ref:`maintainers` will merge the changes into the
``integration`` branch.
- If the changes are not based on a sufficiently-recent commit, or if they
cannot be automatically rebased, then the `Maintainers`_ may rebase it on
the ``master`` branch or ask you to do so.
cannot be automatically rebased, then the :ref:`maintainers` may rebase it
on the ``master`` branch or ask you to do so.
- After final integration testing, the changes will make their way into the
``master`` branch. If a problem is found during integration, the merge
commit will be removed from the ``integration`` branch and the
`Maintainers`_ will ask you to create a new patch set to resolve the
:ref:`maintainers` will ask you to create a new patch set to resolve the
problem.
Binary Components
......@@ -132,15 +133,6 @@ Binary Components
.. _issue: https://developer.trustedfirmware.org/project/board/1/
.. _Trusted Firmware-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
.. _Git guidelines: http://git-scm.com/book/ch5-2.html
.. _Coding Guidelines: ./coding-guidelines.rst
.. _User Guide: ../getting_started/user-guide.rst
.. _Porting Guide: ../getting_started/porting-guide.rst
.. _Firmware Design: ../design/firmware-design.rst
.. _license.rst: ../license.rst
.. _Acknowledgements: ../acknowledgements.rst
.. _Maintainers: ../maintainers.rst
.. _Running the software on FVP: ../getting_started/user-guide.rst#user-content-running-the-software-on-fvp
.. _Developer Certificate of Origin (DCO): ../../dco.txt
.. _Gerrit Uploading Changes documentation: https://review.trustedfirmware.org/Documentation/user-upload.html
.. _Gerrit Signed-off-by Lines guidelines: https://review.trustedfirmware.org/Documentation/user-signedoffby.html
.. _Gerrit Change-Ids documentation: https://review.trustedfirmware.org/Documentation/user-changeid.html
......
docs/process/faq.rst
View file @ f8e3340c
......@@ -37,7 +37,7 @@ This can vary a lot, depending on:
conflict between the topics.
* If there is a code freeze in place in preparation for the release. Please
refer the `release information`_ for more details.
refer the :ref:`Release Processes` document for more details.
* The workload of the TF maintainers.
......@@ -55,9 +55,9 @@ receiving patches that will not be merged into the release. In this case, the
patches will be merged onto ``integration``, which will temporarily diverge from
the release branch. The ``integration`` branch will be rebased onto ``master``
after the release, and then ``master`` will be fast-forwarded to ``integration``
1-2 days later. This whole process could take up 4 weeks. Please refer the
`release information`_ for code freeze dates. The TF maintainers will inform the
patch owner if this is going to happen.
1-2 days later. This whole process could take up 4 weeks. Please refer to the
:ref:`Release Processes` document for code freeze dates. The TF maintainers
will inform the patch owner if this is going to happen.
It is OK to create a patch based on commits that are only available in
``integration`` or another patch set, rather than ``master``. There is a risk
......@@ -73,7 +73,10 @@ but would be after the CI has been transitioned to `trustedfirmware.org`_.
Please refer to https://github.com/ARM-software/tf-issues/issues/681 for more
details on the timelines.
.. _release information: release-information.rst
--------------
*Copyright (c) 2019, Arm Limited. All rights reserved.*
.. _Gerrit Upload Patch Set documentation: https://review.trustedfirmware.org/Documentation/intro-user.html#upload-patch-set
.. _Gerrit Replace Changes documentation: https://review.trustedfirmware.org/Documentation/user-upload.html#push_replace
.. _trustedfirmware.org: https://www.trustedfirmware.org/
docs/process/platform-compatibility-policy.rst
View file @ f8e3340c
......@@ -11,7 +11,7 @@ Platform compatibility policy
-----------------------------
Platform compatibility is mainly affected by changes to Platform APIs (as
documented in the `Porting Guide`_), driver APIs (like the GICv3 drivers) or
documented in the :ref:`Porting Guide`), driver APIs (like the GICv3 drivers) or
library interfaces (like xlat_table library). The project will try to maintain
compatibility for upstream platforms. Due to evolving requirements and
enhancements, there might be changes affecting platform compatibility which
......@@ -20,7 +20,7 @@ introduced to replace it. In case the migration to the new interface is trivial,
the contributor of the change is expected to make good effort to migrate the
upstream platforms to the new interface.
The deprecated interfaces are listed inside `Release information`_ as well as
The deprecated interfaces are listed inside :ref:`Release Processes` as well as
the release after which each one will be removed. When an interface is
deprecated, the page must be updated to indicate the release after which the
interface will be removed. This must be at least 1 full release cycle in future.
......@@ -33,6 +33,4 @@ the deprecated interface.
*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.*
.. _Porting Guide: ../getting_started/porting-guide.rst
.. _Release information: ./release-information.rst#removal-of-deprecated-interfaces
.. _TF-A public mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
docs/process/release-information.rst
View file @ f8e3340c
......@@ -42,9 +42,9 @@ depending on project requirement and partner feedback.
Removal of Deprecated Interfaces
--------------------------------
As mentioned in the `Platform compatibility policy`_, this is a live document
cataloging all the deprecated interfaces in TF-A project and the Release version
after which it will be removed.
As mentioned in the :ref:`Platform Compatibility Policy`, this is a live
document cataloging all the deprecated interfaces in TF-A project and the
Release version after which it will be removed.
+--------------------------------+-------------+---------+---------------------------------------------------------+
| Interface | Deprecation | Removed | Comments |
......@@ -54,7 +54,7 @@ after which it will be removed.
| Legacy Console API | Jan '18 | v2.1 | Deprecated in favour of ``MULTI_CONSOLE_API`` |
+--------------------------------+-------------+---------+---------------------------------------------------------+
| Weak default | Oct '18 | v2.1 | The default implementations are defined in |
| ``plat_crash_console_*`` | | | `crash_console_helpers.S`_. The platforms have to |
| ``plat_crash_console_*`` | | | ``crash_console_helpers.S``. The platforms have to |
| APIs | | | define ``plat_crash_console_*``. |
+--------------------------------+-------------+---------+---------------------------------------------------------+
| ``finish_console_register`` | Oct '18 | v2.1 | The old version of the macro is deprecated. See commit |
......@@ -74,9 +74,9 @@ after which it will be removed.
| Makefile in ``INCLUDES``. | | | header files. More information in commit 09d40e0e0828_. |
+--------------------------------+-------------+---------+---------------------------------------------------------+
--------------
*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.*
.. _Platform compatibility policy: platform-compatibility-policy.rst
.. _crash_console_helpers.S: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/common/aarch64/crash_console_helpers.S
.. _cc5859c: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=cc5859ca19ff546c35eb0331000dae090b6eabcf
.. _09d40e0e0828: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=09d40e0e08283a249e7dce0e106c07c5141f9b7e
docs/process/security-hardening.rst
View file @ f8e3340c
......@@ -9,7 +9,7 @@ Build options
-------------
Several build options can be used to check for security issues. Refer to the
`user guide`_ for detailed information on the specific build options.
:ref:`User Guide` for detailed information on the specific build options.
- The ``BRANCH_PROTECTION`` build flag can be used to enable Pointer
Authentication and Branch Target Identification.
......@@ -53,6 +53,6 @@ Several build options can be used to check for security issues. Refer to the
NB: The ``Werror`` flag is enabled by default in TF-A and can be disabled by
setting the ``E`` build flag to 0.
*Copyright (c) 2019, Arm Limited. All rights reserved.*
--------------
.. _user guide: ../getting_started/user-guide.rst
*Copyright (c) 2019, Arm Limited. All rights reserved.*
docs/process/security.rst
View file @ f8e3340c
......@@ -38,9 +38,11 @@ Please include:
- Any additional software or tools required
We recommend using `this PGP/GPG key`_ for encrypting the information. This key
is also available at http://keyserver.pgp.com and LDAP port 389 of the same
server. The fingerprint for this key is:
We recommend using :download:`this PGP/GPG key <./security-reporting.asc>` for
encrypting the information. This key is also available at
http://keyserver.pgp.com and LDAP port 389 of the same server.
The fingerprint for this key is:
::
......@@ -59,7 +61,7 @@ code.
Attribution
-----------
We will name and thank you in the ``change-log.rst`` distributed with the source
We will name and thank you in the :ref:`Change Log & Release Notes` distributed with the source
code and in any published security advisory.
Security Advisories
......@@ -68,38 +70,43 @@ Security Advisories
+-----------+------------------------------------------------------------------+
| ID | Title |
+===========+==================================================================+
| `TFV-1`_ | Malformed Firmware Update SMC can result in copy of unexpectedly |
| |TFV-1| | Malformed Firmware Update SMC can result in copy of unexpectedly |
| | large data into secure memory |
+-----------+------------------------------------------------------------------+
| `TFV-2`_ | Enabled secure self-hosted invasive debug interface can allow |
| |TFV-2| | Enabled secure self-hosted invasive debug interface can allow |
| | normal world to panic secure world |
+-----------+------------------------------------------------------------------+
| `TFV-3`_ | RO memory is always executable at AArch64 Secure EL1 |
| |TFV-3| | RO memory is always executable at AArch64 Secure EL1 |
+-----------+------------------------------------------------------------------+
| `TFV-4`_ | Malformed Firmware Update SMC can result in copy or |
| |TFV-4| | Malformed Firmware Update SMC can result in copy or |
| | authentication of unexpected data in secure memory in AArch32 |
| | state |
+-----------+------------------------------------------------------------------+
| `TFV-5`_ | Not initializing or saving/restoring PMCR_EL0 can leak secure |
| |TFV-5| | Not initializing or saving/restoring PMCR_EL0 can leak secure |
| | world timing information |
+-----------+------------------------------------------------------------------+
| `TFV-6`_ | Trusted Firmware-A exposure to speculative processor |
| |TFV-6| | Trusted Firmware-A exposure to speculative processor |
| | vulnerabilities using cache timing side-channels |
+-----------+------------------------------------------------------------------+
| `TFV-7`_ | Trusted Firmware-A exposure to cache speculation vulnerability |
| |TFV-7| | Trusted Firmware-A exposure to cache speculation vulnerability |
| | Variant 4 |
+-----------+------------------------------------------------------------------+
| `TFV-8`_ | Not saving x0 to x3 registers can leak information from one |
| |TFV-8| | Not saving x0 to x3 registers can leak information from one |
| | Normal World SMC client to another |
+-----------+------------------------------------------------------------------+
.. _issue tracker: https://developer.trustedfirmware.org/project/board/1/
.. _this PGP/GPG key: security-reporting.asc
.. _TFV-1: ../security_advisories/security-advisory-tfv-1.rst
.. _TFV-2: ../security_advisories/security-advisory-tfv-2.rst
.. _TFV-3: ../security_advisories/security-advisory-tfv-3.rst
.. _TFV-4: ../security_advisories/security-advisory-tfv-4.rst
.. _TFV-5: ../security_advisories/security-advisory-tfv-5.rst
.. _TFV-6: ../security_advisories/security-advisory-tfv-6.rst
.. _TFV-7: ../security_advisories/security-advisory-tfv-7.rst
.. _TFV-8: ../security_advisories/security-advisory-tfv-8.rst
.. |TFV-1| replace:: :ref:`Advisory TFV-1 (CVE-2016-10319)`
.. |TFV-2| replace:: :ref:`Advisory TFV-2 (CVE-2017-7564)`
.. |TFV-3| replace:: :ref:`Advisory TFV-3 (CVE-2017-7563)`
.. |TFV-4| replace:: :ref:`Advisory TFV-4 (CVE-2017-9607)`
.. |TFV-5| replace:: :ref:`Advisory TFV-5 (CVE-2017-15031)`
.. |TFV-6| replace:: :ref:`Advisory TFV-6 (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754)`
.. |TFV-7| replace:: :ref:`Advisory TFV-7 (CVE-2018-3639)`
.. |TFV-8| replace:: :ref:`Advisory TFV-8 (CVE-2018-19440)`
--------------
*Copyright (c) 2019, Arm Limited. All rights reserved.*
license.rst
View file @ f8e3340c
Copyright (c) [XXXX-]YYYY, <OWNER>. All rights reserved.
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
- Neither the name of Arm nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--------------
.. note::
Individual files contain the following tag instead of the full license text.
::
SPDX-License-Identifier: BSD-3-Clause
This enables machine processing of license information based on the SPDX
License Identifiers that are here available: http://spdx.org/licenses/
See docs/license.rst
readme.rst
View file @ f8e3340c
Trusted Firmware-A - version 2.1
================================
Trusted Firmware-A
==================
.. section-numbering::
:suffix: .
Trusted Firmware-A is a reference implementation of secure world software for
`Arm A-Profile architectures`_ (Armv8-A and Armv7-A), including an
Exception Level 3 (EL3)`Secure Monitor`_. It provides a suitable starting point
for productization of secure world boot and runtime firmware, in either the
|AArch32| or |AArch64| execution states.
.. contents::
|TF-A| implements Arm interface standards, including:
Trusted Firmware-A (TF-A) provides a reference implementation of secure world
software for `Armv7-A and Armv8-A`_, including a `Secure Monitor`_ executing
at Exception Level 3 (EL3). It implements various Arm interface standards,
such as:
- The `Power State Coordination Interface (PSCI)`_
- `Power State Coordination Interface (PSCI)`_
- `Trusted Board Boot Requirements CLIENT (TBBR-CLIENT)`_
- `SMC Calling Convention`_
- `System Control and Management Interface (SCMI)`_
- `Software Delegated Exception Interface (SDEI)`_
Where possible, the code is designed for reuse or porting to other Armv7-A and
Armv8-A model and hardware platforms.
The code is designed to be portable and reusable across hardware platforms and
software models that are based on the Armv8-A and Armv7-A architectures.
This release provides a suitable starting point for productization of secure
world boot and runtime firmware, in either the AArch32 or AArch64 execution
states.
In collaboration with interested parties, we will continue to enhance |TF-A|
with reference implementations of Arm standards to benefit developers working
with Armv7-A and Armv8-A TrustZone technology.
Users are encouraged to do their own security validation, including penetration
testing, on any secure world code derived from TF-A.
Arm will continue development in collaboration with interested parties to
provide a full reference implementation of Secure Monitor code and Arm standards
to the benefit of all developers working with Armv7-A and Armv8-A TrustZone
technology.
Documentation contents
----------------------
The `Trusted Firmware-A Documentation Contents`_ page contains an overview of
the documentation that is available, with links to facilitate easier browsing.
License
-------
The software is provided under a BSD-3-Clause `license`_. Contributions to this
project are accepted under the same license with developer sign-off as
described in the `Contributing Guidelines`_.
This project contains code from other projects as listed below. The original
license text is included in those source files.
- The libc source code is derived from `FreeBSD`_ and `SCC`_. FreeBSD uses
various BSD licenses, including BSD-3-Clause and BSD-2-Clause. The SCC code
is used under the BSD-3-Clause license with the author's permission.
- The libfdt source code is disjunctively dual licensed
(GPL-2.0+ OR BSD-2-Clause). It is used by this project under the terms of
the BSD-2-Clause license. Any contributions to this code must be made under
the terms of both licenses.
- The LLVM compiler-rt source code is disjunctively dual licensed
(NCSA OR MIT). It is used by this project under the terms of the NCSA
license (also known as the University of Illinois/NCSA Open Source License),
which is a permissive license compatible with BSD-3-Clause. Any
contributions to this code must be made under the terms of both licenses.
- The zlib source code is licensed under the Zlib license, which is a
permissive license compatible with BSD-3-Clause.
- Some STMicroelectronics platform source code is disjunctively dual licensed
(GPL-2.0+ OR BSD-3-Clause). It is used by this project under the terms of the
BSD-3-Clause license. Any contributions to this code must be made under the
terms of both licenses.
Functionality
-------------
- Initialization of the secure world, for example exception vectors, control
registers and interrupts for the platform.
- Library support for CPU specific reset and power down sequences. This
includes support for errata workarounds and the latest Arm DynamIQ CPUs.
- Drivers to enable standard initialization of Arm System IP, for example
Generic Interrupt Controller (GIC), Cache Coherent Interconnect (CCI),
Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone
Controller (TZC).
- A generic `SCMI`_ driver to interface with conforming power controllers, for
example the Arm System Control Processor (SCP).
- SMC (Secure Monitor Call) handling, conforming to the `SMC Calling
Convention`_ using an EL3 runtime services framework.
- `PSCI`_ library support for CPU, cluster and system power management
use-cases.
This library is pre-integrated with the AArch64 EL3 Runtime Software, and
is also suitable for integration with other AArch32 EL3 Runtime Software,
for example an AArch32 Secure OS.
- A minimal AArch32 Secure Payload (SP\_MIN) to demonstrate `PSCI`_ library
integration with AArch32 EL3 Runtime Software.
- Secure Monitor library code such as world switching, EL1 context management
and interrupt routing.
When a Secure-EL1 Payload (SP) is present, for example a Secure OS, the
AArch64 EL3 Runtime Software must be integrated with a Secure Payload
Dispatcher (SPD) component to customize the interaction with the SP.
- A Test SP and SPD to demonstrate AArch64 Secure Monitor functionality and SP
interaction with PSCI.
- SPDs for the `OP-TEE Secure OS`_, `NVIDIA Trusted Little Kernel`_
and `Trusty Secure OS`_.
- A Trusted Board Boot implementation, conforming to all mandatory TBBR
requirements. This includes image authentication, Firmware Update (or
recovery mode), and packaging of the various firmware images into a
Firmware Image Package (FIP).
- Pre-integration of TBB with the Arm CryptoCell product, to take advantage of
its hardware Root of Trust and crypto acceleration services.
- Reliability, Availability, and Serviceability (RAS) functionality, including
- A Secure Partition Manager (SPM) to manage Secure Partitions in
Secure-EL0, which can be used to implement simple management and
security services.
- An SDEI dispatcher to route interrupt-based SDEI events.
- An Exception Handling Framework (EHF) that allows dispatching of EL3
interrupts to their registered handlers, to facilitate firmware-first
error handling.
- A dynamic configuration framework that enables each of the firmware images
to be configured at runtime if required by the platform. It also enables
loading of a hardware configuration (for example, a kernel device tree)
as part of the FIP, to be passed through the firmware stages.
- Support for alternative boot flows, for example to support platforms where
the EL3 Runtime Software is loaded using other firmware or a separate
secure system processor, or where a non-TF-A ROM expects BL2 to be loaded
at EL3.
- Support for the GCC, LLVM and Arm Compiler 6 toolchains.
- Support for combining several libraries into a "romlib" image that may be
shared across images to reduce memory footprint. The romlib image is stored
in ROM but is accessed through a jump-table that may be stored
in read-write memory, allowing for the library code to be patched.
- A prototype implementation of a Secure Partition Manager (SPM) that is based
on the SPCI Alpha 1 and SPRT draft specifications.
- 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.
- Position-Independent Executable (PIE) support. Initially for BL31 only, with
further support to be added in a future release.
For a full description of functionality and implementation details, please
see the `Firmware Design`_ and supporting documentation. The `Change Log`_
provides details of changes made since the last release.
Platforms
Read More
---------
Various AArch32 and AArch64 builds of this release have been tested on r0, r1
and r2 variants of the `Juno Arm Development Platform`_.
The latest version of the AArch64 build of TF-A has been tested on the following
Arm FVPs without shifted affinities, and that do not support threaded CPU cores
(64-bit host machine only).
The FVP models used are Version 11.6 Build 45, unless otherwise stated.
- ``FVP_Base_AEMv8A-AEMv8A``
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502``
- ``FVP_Base_RevC-2xAEMv8A``
- ``FVP_Base_Cortex-A32x4``
- ``FVP_Base_Cortex-A35x4``
- ``FVP_Base_Cortex-A53x4``
- ``FVP_Base_Cortex-A55x4+Cortex-A75x4``
- ``FVP_Base_Cortex-A55x4``
- ``FVP_Base_Cortex-A57x1-A53x1``
- ``FVP_Base_Cortex-A57x2-A53x4``
- ``FVP_Base_Cortex-A57x4-A53x4``
- ``FVP_Base_Cortex-A57x4``
- ``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-A77x4`` (Version 11.7 build 36)
- ``FVP_Base_Neoverse-N1x4``
- ``FVP_CSS_SGI-575`` (Version 11.3 build 42)
- ``FVP_CSS_SGM-775`` (Version 11.3 build 42)
- ``FVP_RD_E1Edge`` (Version 11.3 build 42)
- ``FVP_RD_N1Edge``
- ``Foundation_Platform``
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 CPU cores
(64-bit host machine only).
- ``FVP_Base_AEMv8A-AEMv8A``
- ``FVP_Base_Cortex-A32x4``
NOTE: The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities.
The Foundation FVP can be downloaded free of charge. The Base FVPs can be
licensed from Arm. See the `Arm FVP website`_.
All the above platforms have been tested with `Linaro Release 18.04`_.
This release also contains the following platform support:
- Allwinner sun50i (A64, H5, and H6) SoCs
- Amlogic Meson S905 (GXBB)
- Amlogic Meson S905x (GXL)
- Arm Juno Software Development Platform
- Arm Neoverse N1 System Development Platform (N1SDP)
- Arm Neoverse Reference Design N1 Edge (RD-N1-Edge) FVP
- Arm Neoverse Reference Design E1 Edge (RD-E1-Edge) FVP
- Arm SGI-575 and SGM-775
- Arm Versatile Express FVP
- HiKey, HiKey960 and Poplar boards
- Intel Stratix 10 SoC FPGA
- Marvell Armada 3700 and 8K
- MediaTek MT6795 and MT8173 SoCs
- NVIDIA T132, T186 and T210 SoCs
- NXP QorIQ LS1043A, i.MX8MM, i.MX8MQ, i.MX8QX, i.MX8QM and i.MX7Solo WaRP7
- QEMU
- Raspberry Pi 3
- Renesas R-Car Generation 3
- RockChip RK3328, RK3368 and RK3399 SoCs
- Socionext UniPhier SoC family and SynQuacer SC2A11 SoCs
- STMicroelectronics STM32MP1
- Texas Instruments K3 SoCs
- Xilinx Versal and Zynq UltraScale + MPSoC
Still to come
-------------
- Support for additional platforms.
- Refinements to Position Independent Executable (PIE) support.
- Refinements to the SPCI-based SPM implementation as the draft SPCI and SPRT
specifications continue to evolve.
- Documentation enhancements.
- Ongoing support for new architectural features, CPUs and System IP.
- Ongoing support for new Arm system architecture specifications.
- Ongoing security hardening, optimization and quality improvements.
For a full list of detailed issues in the current code, please see the `Change
Log`_ and the `issue tracker`_.
Getting started
---------------
See the `User Guide`_ for instructions on how to download, install, build and
use TF-A with the Arm `FVP`_\ s.
See the `Firmware Design`_ for information on how TF-A works.
See the `Porting Guide`_ as well for information about how to use this
software on another Armv7-A or Armv8-A platform.
See the `Contributing Guidelines`_ for information on how to contribute to this
project and the `Acknowledgments`_ file for a list of contributors to the
project.
Contact us
~~~~~~~~~~
We welcome any feedback on TF-A. If you think you have found a security
vulnerability, please report this using the process defined in the TF-A
`Security Center`_. For all other feedback, you can use either the
`issue tracker`_ or our `mailing list`_.
Arm licensees may contact Arm directly via their partner managers.
Security advisories
-------------------
- `Security Advisory TFV-1`_
- `Security Advisory TFV-2`_
- `Security Advisory TFV-3`_
- `Security Advisory TFV-4`_
- `Security Advisory TFV-5`_
- `Security Advisory TFV-6`_
- `Security Advisory TFV-7`_
- `Security Advisory TFV-8`_
To find out more about Trusted Firmware-A, please `view the full documentation`_
that is available through `trustedfirmware.org`_.
--------------
......@@ -319,32 +45,7 @@ Security advisories
.. _SCMI: http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf
.. _Software Delegated Exception Interface (SDEI): SDEI_
.. _SDEI: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
.. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php
.. _Arm FVP website: FVP_
.. _FVP: https://developer.arm.com/products/system-design/fixed-virtual-platforms
.. _Linaro Release 18.04: https://community.arm.com/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease18.04
.. _OP-TEE Secure OS: https://github.com/OP-TEE/optee_os
.. _NVIDIA Trusted Little Kernel: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/ote_partner/tlk.git;a=summary
.. _Trusty Secure OS: https://source.android.com/security/trusty
.. _trustedfirmware.org: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
.. _issue tracker: https://developer.trustedfirmware.org/project/board/1/
.. _mailing list: https://lists.trustedfirmware.org/mailman/listinfo/tf-a
.. _Security Center: ./docs/process/security.rst
.. _license: ./license.rst
.. _Contributing Guidelines: ./docs/process/contributing.rst
.. _Acknowledgments: ./docs/acknowledgements.rst
.. _Firmware Design: ./docs/design/firmware-design.rst
.. _Change Log: ./docs/change-log.rst
.. _User Guide: ./docs/getting_started/user-guide.rst
.. _Porting Guide: ./docs/getting_started/porting-guide.rst
.. _FreeBSD: http://www.freebsd.org
.. _SCC: http://www.simple-cc.org/
.. _Security Advisory TFV-1: ./docs/security_advisories/security-advisory-tfv-1.rst
.. _Security Advisory TFV-2: ./docs/security_advisories/security-advisory-tfv-2.rst
.. _Security Advisory TFV-3: ./docs/security_advisories/security-advisory-tfv-3.rst
.. _Security Advisory TFV-4: ./docs/security_advisories/security-advisory-tfv-4.rst
.. _Security Advisory TFV-5: ./docs/security_advisories/security-advisory-tfv-5.rst
.. _Security Advisory TFV-6: ./docs/security_advisories/security-advisory-tfv-6.rst
.. _Security Advisory TFV-7: ./docs/security_advisories/security-advisory-tfv-7.rst
.. _Security Advisory TFV-8: ./docs/security_advisories/security-advisory-tfv-8.rst
.. _Trusted Firmware-A Documentation Contents: ./docs/contents.rst
.. _Arm A-Profile architectures: https://developer.arm.com/architectures/cpu-architecture/a-profile
.. _view the full documentation: https://www.trustedfirmware.org/docs/tf-a
.. _trustedfirmware.org: http://www.trustedfirmware.org
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment