5f654975bb
At the moment, the memory translation library allows to create memory mappings of 2 types: - Device nGnRE memory (named MT_DEVICE in the library); - Normal, Inner Write-back non-transient, Outer Write-back non-transient memory (named MT_MEMORY in the library). As a consequence, the library code treats the memory type field as a boolean: everything that is not device memory is normal memory and vice-versa. In reality, the ARMv8 architecture allows up to 8 types of memory to be used at a single time for a given exception level. This patch reworks the memory attributes such that the memory type is now defined as an integer ranging from 0 to 7 instead of a boolean. This makes it possible to extend the list of memory types supported by the memory translation library. The priority system dictating memory attributes for overlapping memory regions has been extended to cope with these changes but the algorithm at its core has been preserved. When a memory region is re-mapped with different memory attributes, the memory translation library examines the former attributes and updates them only if the new attributes create a more restrictive mapping. This behaviour is unchanged, only the manipulation of the value has been modified to cope with the new format. This patch also introduces a new type of memory mapping in the memory translation library: MT_NON_CACHEABLE, meaning Normal, Inner Non-cacheable, Outer Non-cacheable memory. This can be useful to map a non-cacheable memory region, such as a DMA buffer for example. The rules around the Execute-Never (XN) bit in a translation table for an MT_NON_CACHEABLE memory mapping have been aligned on the rules used for MT_MEMORY mappings: - If the memory is read-only then it is also executable (XN = 0); - If the memory is read-write then it is not executable (XN = 1). The shareability field for MT_NON_CACHEABLE mappings is always set as 'Outer-Shareable'. Note that this is not strictly needed since shareability is only relevant if the memory is a Normal Cacheable memory type, but this is to align with the existing device memory mappings setup. All Device and Normal Non-cacheable memory regions are always treated as Outer Shareable, regardless of the translation table shareability attributes. This patch also removes the 'ATTR_SO' and 'ATTR_SO_INDEX' #defines. They were introduced to map memory as Device nGnRnE (formerly called "Strongly-Ordered" memory in the ARMv7 architecture) but were not used anywhere in the code base. Removing them avoids any confusion about the memory types supported by the library. Upstream platforms do not currently use the MT_NON_CACHEABLE memory type. NOTE: THIS CHANGE IS SOURCE COMPATIBLE BUT PLATFORMS THAT RELY ON THE BINARY VALUES OF `mmap_attr_t` or the `attr` argument of `mmap_add_region()` MAY BE BROKEN. Change-Id: I717d6ed79b4c845a04e34132432f98b93d661d79 |
||
---|---|---|
bl1 | ||
bl2 | ||
bl2u | ||
bl31 | ||
bl32/tsp | ||
common | ||
docs | ||
drivers | ||
fdts | ||
include | ||
lib | ||
make_helpers | ||
plat | ||
services | ||
tools | ||
.gitignore | ||
acknowledgements.md | ||
contributing.md | ||
license.md | ||
Makefile | ||
readme.md |
ARM Trusted Firmware - version 1.2
ARM Trusted Firmware provides a reference implementation of secure world software for ARMv8-A, including a [Secure Monitor] TEE-SMC executing at Exception Level 3 (EL3). It implements various ARM interface standards, such as the Power State Coordination Interface (PSCI), Trusted Board Boot Requirements (TBBR, ARM DEN0006C-1) and SMC Calling Convention. As far as possible the code is designed for reuse or porting to other ARMv8-A model and hardware platforms.
ARM will continue development in collaboration with interested parties to provide a full reference implementation of PSCI, TBBR and Secure Monitor code to the benefit of all developers working with ARMv8-A TrustZone technology.
License
The software is provided under a BSD 3-Clause license. Certain source files are derived from FreeBSD code: the original license is included in these source files.
This Release
This release provides a suitable starting point for productization of secure world boot and runtime firmware. Future versions will contain new features, optimizations and quality improvements.
Users are encouraged to do their own security validation, including penetration testing, on any secure world code derived from ARM Trusted Firmware.
Functionality
-
Initialization of the secure world (for example, exception vectors, control registers, interrupt controller and interrupts for the platform), before transitioning into the normal world at the Exception Level and Register Width specified by the platform.
-
Library support for CPU specific reset and power down sequences. This includes support for errata workarounds.
-
Drivers for both the version 2.0 and version 3.0 ARM Generic Interrupt Controller specifications (GICv2 and GICv3). The latter also enables GICv3 hardware systems that do not contain legacy GICv2 support.
-
Drivers to enable standard initialization of ARM System IP, for example Cache Coherent Interconnect (CCI), Cache Coherent Network (CCN), Network Interconnect (NIC) and TrustZone Controller (TZC).
-
SMC (Secure Monitor Call) handling, conforming to the SMC Calling Convention using an EL3 runtime services framework.
-
SMC handling relating to PSCI for the Secondary CPU Boot, CPU Hotplug, CPU Idle and System Shutdown/Reset/Suspend use-cases.
-
Secure Monitor library code such as world switching, EL1 context management and interrupt routing. This must be integrated with a Secure-EL1 Payload Dispatcher (SPD) component to customize the interaction with a Secure-EL1 Payload (SP), for example a Secure OS.
-
A Test Secure-EL1 Payload and Dispatcher to demonstrate Secure Monitor functionality and Secure-EL1 interaction with PSCI.
-
SPDs for the OP-TEE Secure OS and [NVidia Trusted Little Kernel] NVidia TLK.
-
A Trusted Board Boot implementation, conforming to all mandatory TBBR requirements. This includes image authentication using certificates, a Firmware Update (or recovery mode) boot flow, and packaging of the various firmware images into a Firmware Image Package (FIP) to be loaded from non-volatile storage.
-
Support for alternative boot flows. Some platforms have their own boot firmware and only require the ARM Trusted Firmware Secure Monitor functionality. Other platforms require minimal initialization before booting into an arbitrary EL3 payload.
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
This release of the Trusted Firmware has been tested on variants r0 and r1 of the [Juno ARM Development Platform] Juno with [Linaro Release 15.10] Linaro Release Notes.
The Trusted Firmware has also been tested on the 64-bit Linux versions of the following ARM FVPs:
Foundation_Platform
(Version 9.4, Build 9.4.59)FVP_Base_AEMv8A-AEMv8A
(Version 7.0, Build 0.8.7004)FVP_Base_Cortex-A57x4-A53x4
(Version 7.0, Build 0.8.7004)FVP_Base_Cortex-A57x1-A53x1
(Version 7.0, Build 0.8.7004)FVP_Base_Cortex-A57x2-A53x4
(Version 7.0, Build 0.8.7004)
The Foundation FVP can be downloaded free of charge. The Base FVPs can be licensed from ARM: see [www.arm.com/fvp] FVP.
This release also contains the following platform support:
- NVidia T210 and T132 SoCs
- MediaTek MT8173 SoC
Still to Come
-
Complete implementation of the PSCI v1.0 specification.
-
Support for new CPUs and System IP.
-
More platform support.
-
Optimization and quality improvements.
For a full list of detailed issues in the current code, please see the Change Log and the GitHub issue tracker.
Getting Started
Get the Trusted Firmware source code from GitHub.
See the User Guide for instructions on how to install, build and use the Trusted Firmware with the ARM FVPs.
See the Firmware Design for information on how the ARM Trusted Firmware works.
See the Porting Guide as well for information about how to use this software on another 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.
Feedback and support
ARM welcomes any feedback on the Trusted Firmware. Please send feedback using the GitHub issue tracker.
ARM licensees may contact ARM directly via their partner managers.
Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.