diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/cpu-specific-build-macros.md (renamed from docs/cpu-errata-workarounds.md) | 48 | ||||
| -rw-r--r-- | docs/firmware-design.md | 100 | ||||
| -rw-r--r-- | docs/user-guide.md | 15 |
3 files changed, 100 insertions, 63 deletions
diff --git a/docs/cpu-errata-workarounds.md b/docs/cpu-specific-build-macros.md index 8285d89d..246381a8 100644 --- a/docs/cpu-errata-workarounds.md +++ b/docs/cpu-specific-build-macros.md @@ -1,11 +1,28 @@ -ARM CPU Errata Workarounds -========================== +ARM CPU Specific Build Macros +============================= + +Contents +-------- + +1. Introduction +2. CPU Errata Workarounds +3. CPU Specific optimizations + +1. Introduction +---------------- + +This document describes the various build options present in the CPU specific +operations framework to enable errata workarounds and to enable optimizations +for a specific CPU on a platform. + +2. CPU Errata Workarounds +-------------------------- ARM Trusted Firmware exports a series of build flags which control the errata workarounds that are applied to each CPU by the reset handler. The errata details can be found in the CPU specifc errata documents published by ARM. The errata workarounds are implemented for a particular revision -or a set of processor revisions. This check is done in the debug build. +or a set of processor revisions. This is checked by reset handler at runtime. Each errata workaround is identified by its `ID` as specified in the processor's errata notice document. The format of the define used to enable/disable the errata is `ERRATA_<Processor name>_<ID>` where the `Processor name` @@ -13,7 +30,10 @@ is either `A57` for the `Cortex_A57` CPU or `A53` for `Cortex_A53` CPU. All workarounds are disabled by default. The platform is reponsible for enabling these workarounds according to its requirement by defining the -errata workaround build flags in the platform specific makefile. +errata workaround build flags in the platform specific makefile. In case +these workarounds are enabled for the wrong CPU revision then the errata +workaround is not applied. In the DEBUG build, this is indicated by +printing a warning to the crash console. In the current implementation, a platform which has more than 1 variant with different revisions of a processor has no runtime mechanism available @@ -22,14 +42,28 @@ for it to specify which errata workarounds should be enabled or not. The value of the build flags are 0 by default, that is, disabled. Any other value will enable it. -For Cortex A57, following errata build flags are defined : +For Cortex-A57, following errata build flags are defined : -* `ERRATA_A57_806969`: This applies errata 806969 workaround to cortex a57 +* `ERRATA_A57_806969`: This applies errata 806969 workaround to Cortex-A57 CPU. This needs to be enabled only for revision r0p0 of the CPU. -* `ERRATA_A57_813420`: This applies errata 813420 workaround to cortex a57 +* `ERRATA_A57_813420`: This applies errata 813420 workaround to Cortex-A57 CPU. This needs to be enabled only for revision r0p0 of the CPU. +3. CPU Specific optimizations +------------------------------ + +This section describes some of the optimizations allowed by the CPU micro +architecture that can be enabled by the platform as desired. + +* `SKIP_A57_L1_FLUSH_PWR_DWN`: This flag enables an optimization in the + Cortex-A57 cluster power down sequence by not flushing the Level 1 data + cache. The L1 data cache and the L2 unified cache are inclusive. A flush + of the L2 by set/way flushes any dirty lines from the L1 as well. This + is a known safe deviation from the Cortex-A57 TRM defined power down + sequence. Each Cortex-A57 based platform must make its own decision on + whether to use the optimization. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - _Copyright (c) 2014, ARM Limited and Contributors. All rights reserved._ diff --git a/docs/firmware-design.md b/docs/firmware-design.md index e952617b..bc075da3 100644 --- a/docs/firmware-design.md +++ b/docs/firmware-design.md @@ -982,9 +982,10 @@ Please note that only 2. is mandated by the TRM. The CPU specific operations framework scales to accommodate a large number of different CPUs during power down and reset handling. The platform can specify +any CPU optimization it wants to enable for each CPU. It can also specify the CPU errata workarounds to be applied for each CPU type during reset handling by defining CPU errata compile time macros. Details on these macros -can be found in the [cpu-errata-workarounds.md][ERRW] file. +can be found in the [cpu-specific-build-macros.md][CPUBM] file. The CPU specific operations framework depends on the `cpu_ops` structure which needs to be exported for each type of CPU in the platform. It is defined in @@ -1199,16 +1200,12 @@ sections must not overstep. The platform code must provide those. The following list describes the memory layout on the FVP: * A 4KB page of shared memory is used to store the entrypoint mailboxes - and the parameters passed between bootloaders. The shared memory can be - allocated either at the top of Trusted SRAM or at the base of Trusted - DRAM at build time. When allocated in Trusted SRAM, the amount of Trusted - SRAM available to load the bootloader images will be reduced by the size - of the shared memory. + and the parameters passed between bootloaders. The shared memory is located + at the base of the Trusted SRAM. The amount of Trusted SRAM available to + load the bootloader images will be reduced by the size of the shared memory. * BL1 is originally sitting in the Trusted ROM at address `0x0`. Its read-write data are relocated at the top of the Trusted SRAM at runtime. - If the shared memory is allocated in Trusted SRAM, the BL1 read-write data - is relocated just below the shared memory. * BL3-1 is loaded at the top of the Trusted SRAM, such that its NOBITS sections will overwrite BL1 R/W data. @@ -1217,21 +1214,17 @@ The following list describes the memory layout on the FVP: * The TSP is loaded as the BL3-2 image at the base of either the Trusted SRAM or Trusted DRAM. When loaded into Trusted SRAM, its NOBITS sections - are allowed to overlay BL2. When loaded into Trusted DRAM, an offset - corresponding to the size of the shared memory is applied to avoid - overlap. + are allowed to overlay BL2. This memory layout is designed to give the BL3-2 image as much memory as possible when it is loaded into Trusted SRAM. Depending on the location of the -shared memory page and the TSP, it will result in different memory maps, -illustrated by the following diagrams. +TSP, it will result in different memory maps, illustrated by the following +diagrams. -**Shared data & TSP in Trusted SRAM (default option):** +**TSP in Trusted SRAM (default option):** Trusted SRAM - 0x04040000 +----------+ - | Shared | - 0x0403F000 +----------+ loaded by BL2 ------------------ + 0x04040000 +----------+ loaded by BL2 ------------------ | BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS | |----------| <<<<<<<<<<<<< |----------------| | | <<<<<<<<<<<<< | BL3-1 PROGBITS | @@ -1239,7 +1232,9 @@ illustrated by the following diagrams. | BL2 | <<<<<<<<<<<<< | BL3-2 NOBITS | |----------| <<<<<<<<<<<<< |----------------| | | <<<<<<<<<<<<< | BL3-2 PROGBITS | - 0x04000000 +----------+ ------------------ + 0x04001000 +----------+ ------------------ + | Shared | + 0x04000000 +----------+ Trusted ROM 0x04000000 +----------+ @@ -1247,15 +1242,11 @@ illustrated by the following diagrams. 0x00000000 +----------+ -**Shared data & TSP in Trusted DRAM:** +**TSP in Trusted DRAM:** Trusted DRAM 0x08000000 +----------+ - | | | BL3-2 | - | | - 0x06001000 |----------| - | Shared | 0x06000000 +----------+ Trusted SRAM @@ -1267,6 +1258,8 @@ illustrated by the following diagrams. | BL2 | |----------| | | + 0x04001000 +----------+ + | Shared | 0x04000000 +----------+ Trusted ROM @@ -1274,37 +1267,46 @@ illustrated by the following diagrams. | BL1 (ro) | 0x00000000 +----------+ -**Shared data in Trusted DRAM, TSP in Trusted SRAM:** +Loading the TSP image in Trusted DRAM doesn't change the memory layout of the +other boot loader images in Trusted SRAM. - Trusted DRAM +#### Memory layout on Juno ARM development platform + +**TSP in Trusted SRAM (default option):** + + Flash0 + 0x0C000000 +----------+ + : : + 0x0BED0000 |----------| + | BL1 (ro) | + 0x0BEC0000 |----------| + : : + | Bypass | 0x08000000 +----------+ - | | - | | - | | - 0x06001000 |----------| - | Shared | - 0x06000000 +----------+ Trusted SRAM - 0x04040000 +----------+ loaded by BL2 ------------------ - | BL1 (rw) | <<<<<<<<<<<<< | BL3-1 NOBITS | - |----------| <<<<<<<<<<<<< |----------------| - | | <<<<<<<<<<<<< | BL3-1 PROGBITS | - |----------| ------------------ - | BL2 | <<<<<<<<<<<<< | BL3-2 NOBITS | - |----------| <<<<<<<<<<<<< |----------------| - | | <<<<<<<<<<<<< | BL3-2 PROGBITS | - 0x04000000 +----------+ ------------------ - - Trusted ROM + 0x04040000 +----------+ + | BL2 | BL3-1 is loaded + 0x04033000 |----------| after BL3-0 has + | BL3-2 | been sent to SCP + 0x04023000 |----------| ------------------ + | BL3-0 | <<<<<<<<<<<<< | BL3-1 | + 0x04009000 |----------| ------------------ + | BL1 (rw) | + 0x04001000 |----------| + | MHU | 0x04000000 +----------+ - | BL1 (ro) | - 0x00000000 +----------+ -Loading the TSP image in Trusted DRAM doesn't change the memory layout of the -other boot loader images in Trusted SRAM. +**TSP in the secure region of DRAM:** -#### Memory layout on Juno ARM development platform + DRAM + 0xFFE00000 +----------+ + | BL3-2 | + 0xFF000000 |----------| + | | + : : + | | + 0x80000000 +----------+ Flash0 0x0C000000 +----------+ @@ -1320,7 +1322,7 @@ other boot loader images in Trusted SRAM. 0x04040000 +----------+ | BL2 | BL3-1 is loaded 0x04033000 |----------| after BL3-0 has - | BL3-2 | been sent to SCP + | | been sent to SCP 0x04023000 |----------| ------------------ | BL3-0 | <<<<<<<<<<<<< | BL3-1 | 0x04009000 |----------| ------------------ @@ -1484,4 +1486,4 @@ _Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved._ [User Guide]: ./user-guide.md [Porting Guide]: ./porting-guide.md [INTRG]: ./interrupt-framework-design.md -[ERRW]: ./cpu-errata-workarounds.md +[CPUBM]: ./cpu-specific-build-macros.md.md diff --git a/docs/user-guide.md b/docs/user-guide.md index d3a92f9b..0b95a1bf 100644 --- a/docs/user-guide.md +++ b/docs/user-guide.md @@ -244,18 +244,19 @@ performed. #### FVP specific build options -* `FVP_SHARED_DATA_LOCATION`: location of the shared memory page. Available - options: - - `tsram` (default) : top of Trusted SRAM - - `tdram` : base of Trusted DRAM - * `FVP_TSP_RAM_LOCATION`: location of the TSP binary. Options: - - `tsram` (default) : base of Trusted SRAM - - `tdram` : Trusted DRAM (above shared data) + - `tsram` (default) : Trusted SRAM + - `tdram` : Trusted DRAM For a better understanding of FVP options, the FVP memory map is explained in the [Firmware Design]. +#### Juno specific build options + +* `PLAT_TSP_LOCATION`: location of the TSP binary. Options: + - `tsram` : Trusted SRAM (default option) + - `dram` : Secure region in DRAM (set by the TrustZone controller) + ### Creating a Firmware Image Package FIPs are automatically created as part of the build instructions described in |