Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-18 02:24:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge changes from topic "sb/doc-updates" into integration

Browse source 
* changes:
  docs(porting): refer the reader back to the threat model
  docs(porting): move porting guide upper in table of contents
This commit is contained in:
Sandrine Bailleux 2023-04-11 10:14:24 +02:00 • committed by TrustedFirmware Code Review
commit 07c594c518
3 changed files with 14 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
docs/getting_started/index.rst
View file

@ -12,10 +12,9 @@ Getting Started
build-options build-options
build-internals build-internals
image-terminology image-terminology
porting-guide
psci-lib-integration-guide psci-lib-integration-guide
rt-svc-writers-guide rt-svc-writers-guide
-------------- --------------
*Copyright (c) 2019, Arm Limited. All rights reserved.* *Copyright (c) 2019-2023, Arm Limited. All rights reserved.*

3
docs/index.rst
View file

@ -11,6 +11,7 @@ Trusted Firmware-A Documentation
process/index process/index
components/index components/index
design/index design/index
porting-guide
plat/index plat/index
perf/index perf/index
security_advisories/index security_advisories/index
@ -84,7 +85,7 @@ have previously been raised against the software.
-------------- --------------
*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.* *Copyright (c) 2013-2023, Arm Limited and Contributors. All rights reserved.*
.. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile .. _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 .. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php

15
docs/getting_started/porting-guide.rst → docs/porting-guide.rst
View file

@ -26,6 +26,13 @@ provide their own implementation if the default implementation is inadequate.
defined. We intend to convert existing weak functions over time. Until defined. We intend to convert existing weak functions over time. Until
then, you will find references to *weak* functions in this document. then, you will find references to *weak* functions in this document.
Please review the :ref:`Threat Model` documents as part of the porting
effort. Some platform interfaces play a key role in mitigating against some of
the threats. Failing to fulfill these expectations could undermine the security
guarantees offered by TF-A. These platform responsibilities are highlighted in
the threat assessment section, under the "`Mitigations implemented?`" box for
each threat.
Some modifications are common to all Boot Loader (BL) stages. Section 2 Some modifications are common to all Boot Loader (BL) stages. Section 2
discusses these in detail. The subsequent sections discuss the remaining discusses these in detail. The subsequent sections discuss the remaining
modifications for each BL stage in detail. modifications for each BL stage in detail.
@ -3578,7 +3585,7 @@ layer is used to load data from non-volatile platform storage. Currently
storage access is only required by BL1 and BL2 phases and performed inside the storage access is only required by BL1 and BL2 phases and performed inside the
``load_image()`` function in ``bl_common.c``. ``load_image()`` function in ``bl_common.c``.
.. uml:: ../resources/diagrams/plantuml/io_framework_usage_overview.puml .. uml:: resources/diagrams/plantuml/io_framework_usage_overview.puml
It is mandatory to implement at least one storage driver. For the Arm It is mandatory to implement at least one storage driver. For the Arm
development platforms the Firmware Image Package (FIP) driver is provided as development platforms the Firmware Image Package (FIP) driver is provided as
@ -3588,7 +3595,7 @@ The storage layer is described in the header file
in ``drivers/io/io_storage.c`` and the driver files are located in in ``drivers/io/io_storage.c`` and the driver files are located in
``drivers/io/``. ``drivers/io/``.
.. uml:: ../resources/diagrams/plantuml/io_arm_class_diagram.puml .. uml:: resources/diagrams/plantuml/io_arm_class_diagram.puml
Each IO driver must provide ``io_dev_*`` structures, as described in Each IO driver must provide ``io_dev_*`` structures, as described in
``drivers/io/io_driver.h``. These are returned via a mandatory registration ``drivers/io/io_driver.h``. These are returned via a mandatory registration
@ -3599,12 +3606,12 @@ Each platform should register devices and their drivers via the storage
abstraction layer. These drivers then need to be initialized by bootloader abstraction layer. These drivers then need to be initialized by bootloader
phases as required in their respective ``blx_platform_setup()`` functions. phases as required in their respective ``blx_platform_setup()`` functions.
.. uml:: ../resources/diagrams/plantuml/io_dev_registration.puml .. uml:: resources/diagrams/plantuml/io_dev_registration.puml
The storage abstraction layer provides mechanisms (``io_dev_init()``) to The storage abstraction layer provides mechanisms (``io_dev_init()``) to
initialize storage devices before IO operations are called. initialize storage devices before IO operations are called.
.. uml:: ../resources/diagrams/plantuml/io_dev_init_and_check.puml .. uml:: resources/diagrams/plantuml/io_dev_init_and_check.puml
The basic operations supported by the layer The basic operations supported by the layer
include ``open()``, ``close()``, ``read()``, ``write()``, ``size()`` and ``seek()``. include ``open()``, ``close()``, ``read()``, ``write()``, ``size()`` and ``seek()``.