Merge pull request #481 from sandrine-bailleux/sb/fix-doc
Various documentation fixes
This commit is contained in:
commit
af94b08c7b
|
@ -8,7 +8,7 @@ Contents :
|
|||
3. [EL3 runtime services framework](#3--el3-runtime-services-framework)
|
||||
4. [Power State Coordination Interface](#4--power-state-coordination-interface)
|
||||
5. [Secure-EL1 Payloads and Dispatchers](#5--secure-el1-payloads-and-dispatchers)
|
||||
6. [Crash Reporting in BL31](#6--crash-reporting-in-bl3-1)
|
||||
6. [Crash Reporting in BL31](#6--crash-reporting-in-bl31)
|
||||
7. [Guidelines for Reset Handlers](#7--guidelines-for-reset-handlers)
|
||||
8. [CPU specific operations framework](#8--cpu-specific-operations-framework)
|
||||
9. [Memory layout of BL images](#9-memory-layout-of-bl-images)
|
||||
|
@ -988,11 +988,11 @@ needs to be exported for each type of CPU in the platform. It is defined in
|
|||
`reset_func()`, `core_pwr_dwn()`, `cluster_pwr_dwn()` and `cpu_reg_dump()`.
|
||||
|
||||
The CPU specific files in `lib/cpus` export a `cpu_ops` data structure with
|
||||
suitable handlers for that CPU. For example, `lib/cpus/cortex_a53.S` exports
|
||||
the `cpu_ops` for Cortex-A53 CPU. According to the platform configuration,
|
||||
these CPU specific files must must be included in the build by the platform
|
||||
makefile. The generic CPU specific operations framework code exists in
|
||||
`lib/cpus/aarch64/cpu_helpers.S`.
|
||||
suitable handlers for that CPU. For example, `lib/cpus/aarch64/cortex_a53.S`
|
||||
exports the `cpu_ops` for Cortex-A53 CPU. According to the platform
|
||||
configuration, these CPU specific files must be included in the build by
|
||||
the platform makefile. The generic CPU specific operations framework code exists
|
||||
in `lib/cpus/aarch64/cpu_helpers.S`.
|
||||
|
||||
### CPU specific Reset Handling
|
||||
|
||||
|
@ -1020,12 +1020,12 @@ entry is stored in per-CPU data by `init_cpu_ops()` so that it can be quickly
|
|||
retrieved during power down sequences.
|
||||
|
||||
The PSCI service, upon receiving a power down request, determines the highest
|
||||
affinity level at which to execute power down sequence for a particular CPU and
|
||||
power level at which to execute power down sequence for a particular CPU and
|
||||
invokes the corresponding 'prepare' power down handler in the CPU specific
|
||||
operations framework. For example, when a CPU executes a power down for affinity
|
||||
operations framework. For example, when a CPU executes a power down for power
|
||||
level 0, the `prepare_core_pwr_dwn()` retrieves the `cpu_ops` pointer from the
|
||||
per-CPU data and the corresponding `core_pwr_dwn()` is invoked. Similarly when
|
||||
a CPU executes power down at affinity level 1, the `prepare_cluster_pwr_dwn()`
|
||||
a CPU executes power down at power level 1, the `prepare_cluster_pwr_dwn()`
|
||||
retrieves the `cpu_ops` pointer and the corresponding `cluster_pwr_dwn()` is
|
||||
invoked.
|
||||
|
||||
|
@ -1454,8 +1454,8 @@ The ARM development platforms' policy is to only allow loading of a known set of
|
|||
images. The platform policy can be modified to allow additional images.
|
||||
|
||||
|
||||
11. Use of coherent memory in Trusted Firmware
|
||||
----------------------------------------------
|
||||
11. Use of coherent memory in Trusted Firmware
|
||||
-----------------------------------------------
|
||||
|
||||
There might be loss of coherency when physical memory with mismatched
|
||||
shareability, cacheability and memory attributes is accessed by multiple CPUs
|
||||
|
@ -1739,5 +1739,5 @@ _Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._
|
|||
[Porting Guide]: ./porting-guide.md
|
||||
[Reset Design]: ./reset-design.md
|
||||
[INTRG]: ./interrupt-framework-design.md
|
||||
[CPUBM]: ./cpu-specific-build-macros.md.md
|
||||
[CPUBM]: ./cpu-specific-build-macros.md
|
||||
[Firmware Update]: ./firmware-update.md
|
||||
|
|
|
@ -3,11 +3,11 @@ ARM Trusted Firmware - Firmware Update Design Guide
|
|||
|
||||
Contents :
|
||||
|
||||
1. [Introduction](#1-introduction)
|
||||
2. [FWU Overview](#2-fwu-overview)
|
||||
3. [Image Identification](#3-image-identification)
|
||||
4. [FWU State Machine](#4-fwu-state-machine)
|
||||
5. [SMC Interface](#5-smc-interface)
|
||||
1. [Introduction](#1--introduction)
|
||||
2. [FWU Overview](#2--fwu-overview)
|
||||
3. [Image Identification](#3--image-identification)
|
||||
4. [FWU State Machine](#4--fwu-state-machine)
|
||||
5. [BL1 SMC Interface](#5--bl1-smc-interface)
|
||||
|
||||
- - - - - - - - - - - - - - - - - -
|
||||
|
||||
|
@ -35,8 +35,8 @@ FWU images, please refer to the "Non-Trusted Firmware Updater" requirements in
|
|||
the TBBR.
|
||||
|
||||
|
||||
2. FWU Overview
|
||||
---------------
|
||||
2. FWU Overview
|
||||
----------------
|
||||
|
||||
The FWU boot flow is primarily mediated by BL1. Since BL1 executes in ROM, and
|
||||
it is usually desirable to minimize the amount of ROM code, the design allows
|
||||
|
@ -73,8 +73,8 @@ use all defined FWU images. Other platforms may use a subset of these.
|
|||
![Flow Diagram](diagrams/fwu_flow.png?raw=true)
|
||||
|
||||
|
||||
3. Image Identification
|
||||
-----------------------
|
||||
3. Image Identification
|
||||
------------------------
|
||||
|
||||
Each FWU image and certificate is identified by a unique ID, defined by the
|
||||
platform, which BL1 uses to fetch an image descriptor (`image_desc_t`) via a
|
||||
|
@ -135,7 +135,7 @@ The following is a brief description of the supported states:
|
|||
|
||||
|
||||
5. BL1 SMC Interface
|
||||
-----------------
|
||||
---------------------
|
||||
|
||||
### BL1_SMC_CALL_COUNT
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ Contents :
|
|||
- [Valid Routing Models](#113-valid-routing-models)
|
||||
+ [Secure-EL1 Interrupts](#1131-secure-el1-interrupts)
|
||||
+ [Non-secure Interrupts](#1132-non-secure-interrupts)
|
||||
+ [EL3 interrupts](#1133-el3_interrupts)
|
||||
+ [EL3 interrupts](#1133-el3-interrupts)
|
||||
- [Mapping of Interrupt Type to Signal](#114-mapping-of-interrupt-type-to-signal)
|
||||
+ [Effect of mapping of several interrupt types to one signal](#1141-effect-of-mapping-of-several-interrupt-types-to-one-signal)
|
||||
- [Assumptions in Interrupt Management Framework](#12-assumptions-in-interrupt-management-framework)
|
||||
|
|
Loading…
Reference in New Issue