From fcb22cf0f46a75f7c1a50035f5215b7caa1ed4c7 Mon Sep 17 00:00:00 2001 From: Sandrine Bailleux Date: Fri, 8 Jan 2016 14:12:55 +0000 Subject: [PATCH] Documentation: Fix broken links in ToCs Change-Id: I4fcdb8e813e0392c2cd3d0623698e8319b3b0593 --- docs/firmware-design.md | 6 +++--- docs/firmware-update.md | 20 ++++++++++---------- docs/interrupt-framework-design.md | 2 +- 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/firmware-design.md b/docs/firmware-design.md index 015ffe560..7ae1de325 100644 --- a/docs/firmware-design.md +++ b/docs/firmware-design.md @@ -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) @@ -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 diff --git a/docs/firmware-update.md b/docs/firmware-update.md index 419ac85c7..97df8cf42 100644 --- a/docs/firmware-update.md +++ b/docs/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 diff --git a/docs/interrupt-framework-design.md b/docs/interrupt-framework-design.md index 060bbf2e1..e50d17587 100644 --- a/docs/interrupt-framework-design.md +++ b/docs/interrupt-framework-design.md @@ -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)