diff options
| -rw-r--r-- | Makefile | 2 | ||||
| -rw-r--r-- | docs/change-log.md | 235 | ||||
| -rw-r--r-- | docs/firmware-design.md | 430 | ||||
| -rw-r--r-- | docs/porting-guide.md | 4 | ||||
| -rw-r--r-- | docs/user-guide.md | 211 | ||||
| -rw-r--r-- | fdts/fvp-base-gicv2-psci-aarch32.dtb | bin | 0 -> 10336 bytes | |||
| -rw-r--r-- | fdts/fvp-base-gicv2-psci-aarch32.dts | 331 | ||||
| -rw-r--r-- | fdts/fvp-base-gicv3-psci-aarch32.dtb | bin | 0 -> 10803 bytes | |||
| -rw-r--r-- | fdts/fvp-base-gicv3-psci-aarch32.dts | 340 | ||||
| -rw-r--r-- | fdts/fvp-base-gicv3-psci.dtb | bin | 10996 -> 10835 bytes | |||
| -rw-r--r-- | fdts/fvp-base-gicv3-psci.dts | 4 | ||||
| -rw-r--r-- | fdts/fvp-foundation-gicv3-psci.dtb | bin | 8301 -> 8140 bytes | |||
| -rw-r--r-- | fdts/fvp-foundation-gicv3-psci.dts | 4 | ||||
| -rw-r--r-- | fdts/fvp-foundation-motherboard-no_psci.dtsi | 197 | ||||
| -rw-r--r-- | fdts/rtsm_ve-motherboard-no_psci.dtsi | 264 | ||||
| -rw-r--r-- | plat/rockchip/rk3399/drivers/soc/soc.c | 13 | ||||
| -rw-r--r-- | plat/rockchip/rk3399/drivers/soc/soc.h | 2 | ||||
| -rw-r--r-- | readme.md | 97 |
18 files changed, 1530 insertions, 604 deletions
@@ -32,7 +32,7 @@ # Trusted Firmware Version # VERSION_MAJOR := 1 -VERSION_MINOR := 2 +VERSION_MINOR := 3 # Default goal is build all images .DEFAULT_GOAL := all diff --git a/docs/change-log.md b/docs/change-log.md index 627b1c2c..74edf988 100644 --- a/docs/change-log.md +++ b/docs/change-log.md @@ -1,3 +1,229 @@ + +ARM Trusted Firmware - version 1.3 +================================== + +New features +------------ + +* Added support for running Trusted Firmware in AArch32 execution state. + + The PSCI library has been refactored to allow integration with **EL3 Runtime + Software**. This is software that is executing at the highest secure + privilege which is EL3 in AArch64 or Secure SVC/Monitor mode in AArch32. See + [PSCI Integration Guide]. + + Included is a minimal AArch32 Secure Payload, **SP-MIN**, that illustrates + the usage and integration of the PSCI library with EL3 Runtime Software + running in AArch32 state. + + Booting to the BL1/BL2 images as well as booting straight to the Secure + Payload is supported. + +* Improvements to the initialization framework for the PSCI service and ARM + Standard Services in general. + + The PSCI service is now initialized as part of ARM Standard Service + initialization. This consolidates the initializations of any ARM Standard + Service that may be added in the future. + + A new function `get_arm_std_svc_args()` is introduced to get arguments + corresponding to each standard service and must be implemented by the EL3 + Runtime Software. + + For PSCI, a new versioned structure `psci_lib_args_t` is introduced to + initialize the PSCI Library. **Note** this is a compatibility break due to + the change in the prototype of `psci_setup()`. + +* To support AArch32 builds of BL1 and BL2, implemented a new, alternative + firmware image loading mechanism that adds flexibility. + + The current mechanism has a hard-coded set of images and execution order + (BL31, BL32, etc). The new mechanism is data-driven by a list of image + descriptors provided by the platform code. + + ARM platforms have been updated to support the new loading mechanism. + + The new mechanism is enabled by a build flag (`LOAD_IMAGE_V2`) which is + currently off by default for the AArch64 build. + + **Note** `TRUSTED_BOARD_BOOT` is currently not supported when + `LOAD_IMAGE_V2` is enabled. + +* Updated requirements for making contributions to ARM TF. + + Commits now must have a 'Signed-off-by:' field to certify that the + contribution has been made under the terms of the + [Developer Certificate of Origin]. + + A signed CLA is no longer required. + + The [Contribution Guide] has been updated to reflect this change. + +* Introduced Performance Measurement Framework (PMF) which provides support + for capturing, storing, dumping and retrieving time-stamps to measure the + execution time of critical paths in the firmware. This relies on defining + fixed sample points at key places in the code. + +* To support the QEMU platform port, imported libfdt v1.4.1 from + https://git.kernel.org/cgit/utils/dtc/dtc.git + +* Updated PSCI support: + + * Added support for PSCI NODE_HW_STATE API for ARM platforms. + + * New optional platform hook, `pwr_domain_pwr_down_wfi()`, in + `plat_psci_ops` to enable platforms to perform platform-specific actions + needed to enter powerdown, including the 'wfi' invocation. + + * PSCI STAT residency and count functions have been added on ARM platforms + by using PMF. + +* Enhancements to the translation table library: + + * Limited memory mapping support for region overlaps to only allow regions + to overlap that are identity mapped or have the same virtual to physical + address offset, and overlap completely but must not cover the same area. + + This limitation will enable future enhancements without having to + support complex edge cases that may not be necessary. + + * The initial translation lookup level is now inferred from the virtual + address space size. Previously, it was hard-coded. + + * Added support for mapping Normal, Inner Non-cacheable, Outer + Non-cacheable memory in the translation table library. + + This can be useful to map a non-cacheable memory region, such as a DMA + buffer. + + * Introduced the MT_EXECUTE/MT_EXECUTE_NEVER memory mapping attributes to + specify the access permissions for instruction execution of a memory + region. + +* Enabled support to isolate code and read-only data on separate memory pages, + allowing independent access control to be applied to each. + +* Enabled SCR_EL3.SIF (Secure Instruction Fetch) bit in BL1 and BL31 common + architectural setup code, preventing fetching instructions from non-secure + memory when in secure state. + +* Enhancements to FIP support: + + * Replaced `fip_create` with `fiptool` which provides a more consistent + and intuitive interface as well as additional support to remove an image + from a FIP file. + + * Enabled printing the SHA256 digest with info command, allowing quick + verification of an image within a FIP without having to extract the + image and running sha256sum on it. + + * Added support for unpacking the contents of an existing FIP file into + the working directory. + + * Aligned command line options for specifying images to use same naming + convention as specified by TBBR and already used in cert_create tool. + +* Refactored the TZC-400 driver to also support memory controllers that + integrate TZC functionality, for example ARM CoreLink DMC-500. Also added + DMC-500 specific support. + +* Implemented generic delay timer based on the system generic counter and + migrated all platforms to use it. + +* Enhanced support for ARM platforms: + + * Updated image loading support to make SCP images (SCP_BL2 and SCP_BL2U) + optional. + + * Enhanced topology description support to allow multi-cluster topology + definitions. + + * Added interconnect abstraction layer to help platform ports select the + right interconnect driver, CCI or CCN, for the platform. + + * Added support to allow loading BL31 in the TZC-secured DRAM instead of + the default secure SRAM. + + * Added support to use a System Security Control (SSC) Registers Unit + enabling ARM TF to be compiled to support multiple ARM platforms and + then select one at runtime. + + * Restricted mapping of Trusted ROM in BL1 to what is actually needed by + BL1 rather than entire Trusted ROM region. + + * Flash is now mapped as execute-never by default. This increases security + by restricting the executable region to what is strictly needed. + +* Applied following erratum workarounds for Cortex-A57: 833471, 826977, + 829520, 828024 and 826974. + +* Added support for Mediatek MT6795 platform. + +* Added support for QEMU virtualization ARMv8-A target. + +* Added support for Rockchip RK3368 and RK3399 platforms. + +* Added support for Xilinx Zynq UltraScale+ MPSoC platform. + +* Added support for ARM Cortex-A73 MPCore Processor. + +* Added support for ARM Cortex-A72 processor. + +* Added support for ARM Cortex-A35 processor. + +* Added support for ARM Cortex-A32 MPCore Processor. + +* Enabled preloaded BL33 alternative boot flow, in which BL2 does not load + BL33 from non-volatile storage and BL31 hands execution over to a preloaded + BL33. The User Guide has been updated with an example of how to use this + option with a bootwrapped kernel. + +* Added support to build ARM TF on a Windows-based host machine. + +* Updated Trusted Board Boot prototype implementation: + + * Enabled the ability for a production ROM with TBBR enabled to boot test + software before a real ROTPK is deployed (e.g. manufacturing mode). + Added support to use ROTPK in certificate without verifying against the + platform value when `ROTPK_NOT_DEPLOYED` bit is set. + + * Added support for non-volatile counter authentication to the + Authentication Module to protect against roll-back. + +* Updated GICv3 support: + + * Enabled processor power-down and automatic power-on using GICv3. + + * Enabled G1S or G0 interrupts to be configured independently. + + * Changed FVP default interrupt driver to be the GICv3-only driver. + **Note** the default build of Trusted Firmware will not be able to boot + Linux kernel with GICv2 FDT blob. + + * Enabled wake-up from CPU_SUSPEND to stand-by by temporarily re-routing + interrupts and then restoring after resume. + +Issues resolved since last release +---------------------------------- + +Known issues +------------ + +* The version of the AEMv8 Base FVP used in this release resets the model + instead of terminating its execution in response to a shutdown request using + the PSCI `SYSTEM_OFF` API. This issue will be fixed in a future version of + the model. + +* Building TF with compiler optimisations disabled (`-O0`) fails. + + +* ARM TF cannot be built with mbed TLS version v2.3.0 due to build warnings + that the ARM TF build system interprets as errors. + +* TBBR is not currently supported when running Trusted Firmware in AArch32 + state. + + ARM Trusted Firmware - version 1.2 ================================== @@ -860,7 +1086,7 @@ releases of the ARM Trusted Firmware. - - - - - - - - - - - - - - - - - - - - - - - - - - -_Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._ +_Copyright (c) 2013-2016, ARM Limited and Contributors. All rights reserved._ [OP-TEE Dispatcher]: optee-dispatcher.md [Power Domain Topology Design]: psci-pd-tree.md @@ -868,3 +1094,10 @@ _Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._ [Authentication Framework]: auth-framework.md [Firmware Update]: firmware-update.md [TF Reset Design]: reset-design.md +[PSCI Integration Guide]: psci-lib-integration-guide.md +[Firmware Design]: firmware-design.md +[CPU Specific Build Macros]: cpu-specific-build-macros.md +[User Guide]: user-guide.md +[Porting Guide]: porting-guide.md +[Developer Certificate of Origin]: ../dco.txt +[Contribution Guide]: ../contributing.md diff --git a/docs/firmware-design.md b/docs/firmware-design.md index 52667e2e..abe7dc5a 100644 --- a/docs/firmware-design.md +++ b/docs/firmware-design.md @@ -15,8 +15,9 @@ Contents : 10. [Firmware Image Package (FIP)](#10--firmware-image-package-fip) 11. [Use of coherent memory in Trusted Firmware](#11--use-of-coherent-memory-in-trusted-firmware) 12. [Isolating code and read-only data on separate memory pages](#12--isolating-code-and-read-only-data-on-separate-memory-pages) -13. [Code Structure](#13--code-structure) -14. [References](#14--references) +13. [Performance Measurement Framework](#13--performance-measurement-framework) +14. [Code Structure](#14--code-structure) +15. [References](#15--references) 1. Introduction @@ -41,6 +42,9 @@ interrupts generated in either security state. The details of the interrupt management framework and its design can be found in [ARM Trusted Firmware Interrupt Management Design guide][INTRG] [4]. +The ARM Trusted Firmware can be built to support either AArch64 or AArch32 +execution state. + 2. Cold boot ------------- @@ -55,15 +59,23 @@ the primary CPU has performed enough initialization to boot them. Refer to the [Reset Design] for more information on the effect of the `COLD_BOOT_SINGLE_CPU` platform build option. -The cold boot path in this implementation of the ARM Trusted Firmware is divided -into five steps (in order of execution): +The cold boot path in this implementation of the ARM Trusted Firmware, +depends on the execution state. +For AArch64, it is divided into five steps (in order of execution): * Boot Loader stage 1 (BL1) _AP Trusted ROM_ * Boot Loader stage 2 (BL2) _Trusted Boot Firmware_ -* Boot Loader stage 3-1 (BL31) _EL3 Runtime Firmware_ +* Boot Loader stage 3-1 (BL31) _EL3 Runtime Software_ * Boot Loader stage 3-2 (BL32) _Secure-EL1 Payload_ (optional) * Boot Loader stage 3-3 (BL33) _Non-trusted Firmware_ +For AArch32, it is divided into four steps (in order of execution): + +* Boot Loader stage 1 (BL1) _AP Trusted ROM_ +* Boot Loader stage 2 (BL2) _Trusted Boot Firmware_ +* Boot Loader stage 3-2 (BL32) _EL3 Runtime Software_ +* Boot Loader stage 3-3 (BL33) _Non-trusted Firmware_ + ARM development platforms (Fixed Virtual Platforms (FVPs) and Juno) implement a combination of the following types of memory regions. Each bootloader stage uses one or more of these memory regions. @@ -80,8 +92,9 @@ one or more of these memory regions. The sections below provide the following details: * initialization and execution of the first three stages during cold boot -* specification of the BL31 entrypoint requirements for use by alternative - Trusted Boot Firmware in place of the provided BL1 and BL2 +* specification of the EL3 Runtime Software (BL31 for AArch64 and BL32 for + AArch32) entrypoint requirements for use by alternative Trusted Boot + Firmware in place of the provided BL1 and BL2 ### BL1 @@ -119,10 +132,11 @@ BL1 performs minimal architectural initialization as follows. BL1 sets up simple exception vectors for both synchronous and asynchronous exceptions. The default behavior upon receiving an exception is to populate - a status code in the general purpose register `X0` and call the + a status code in the general purpose register `X0/R0` and call the `plat_report_exception()` function (see the [Porting Guide]). The status code is one of: + For AArch64: 0x0 : Synchronous exception from Current EL with SP_EL0 0x1 : IRQ exception from Current EL with SP_EL0 0x2 : FIQ exception from Current EL with SP_EL0 @@ -140,12 +154,24 @@ BL1 performs minimal architectural initialization as follows. 0xe : FIQ exception from Lower EL using aarch32 0xf : System Error exception from Lower EL using aarch32 + For AArch32: + 0x10 : User mode + 0x11 : FIQ mode + 0x12 : IRQ mode + 0x13 : SVC mode + 0x16 : Monitor mode + 0x17 : Abort mode + 0x1a : Hypervisor mode + 0x1b : Undefined mode + 0x1f : System mode + The `plat_report_exception()` implementation on the ARM FVP port programs the Versatile Express System LED register in the following format to indicate the occurence of an unexpected exception: SYS_LED[0] - Security state (Secure=0/Non-Secure=1) SYS_LED[2:1] - Exception Level (EL3=0x3, EL2=0x2, EL1=0x1, EL0=0x0) + For AArch32 it is always 0x0 SYS_LED[7:3] - Exception Class (Sync/Async & origin). This is the value of the status code @@ -155,11 +181,12 @@ BL1 performs minimal architectural initialization as follows. BL1 does not expect to receive any exceptions other than the SMC exception. For the latter, BL1 installs a simple stub. The stub expects to receive a limited set of SMC types (determined by their function IDs in the general - purpose register `X0`): + purpose register `X0/R0`): - `BL1_SMC_RUN_IMAGE`: This SMC is raised by BL2 to make BL1 pass control - to BL31 (loaded by BL2) at EL3. + to EL3 Runtime Software. - All SMCs listed in section "BL1 SMC Interface" in the [Firmware Update] - Design Guide. + Design Guide are supported for AArch64 only. These SMCs are currently + not supported when BL1 is built for AArch32. Any other SMC leads to an assertion failure. @@ -169,7 +196,7 @@ BL1 performs minimal architectural initialization as follows. specific reset handler function (see the section: "CPU specific operations framework"). -* Control register setup +* Control register setup (for AArch64) - `SCTLR_EL3`. Instruction cache is enabled by setting the `SCTLR_EL3.I` bit. Alignment and stack alignment checking is enabled by setting the `SCTLR_EL3.A` and `SCTLR_EL3.SA` bits. Exception endianness is set to @@ -192,6 +219,29 @@ BL1 performs minimal architectural initialization as follows. - `DAIF`. The SError interrupt is enabled by clearing the SError interrupt mask bit. +* Control register setup (for AArch32) + - `SCTLR`. Instruction cache is enabled by setting the `SCTLR.I` bit. + Alignment checking is enabled by setting the `SCTLR.A` bit. + Exception endianness is set to little-endian by clearing the + `SCTLR.EE` bit. + + - `SCR`. The `SCR.SIF` bit is set to disable instruction fetches from + Non-secure memory when in secure state. + + - `CPACR`. Allow execution of Advanced SIMD instructions at PL0 and PL1, + by clearing the `CPACR.ASEDIS` bit. Access to the trace functionality + is configured not to trap to undefined mode by clearing the + `CPACR.TRCDIS` bit. + + - `NSACR`. Enable non-secure access to Advanced SIMD functionality and + system register access to implemented trace registers. + + - `FPEXC`. Enable access to the Advanced SIMD and floating-point + functionality from all Exception levels. + + - `CPSR.A`. The Asynchronous data abort interrupt is enabled by clearing + the Asynchronous data abort interrupt mask bit. + #### Platform initialization On ARM platforms, BL1 performs the following platform initializations: @@ -233,14 +283,13 @@ In the normal boot flow, BL1 execution continues as follows: "Failed to load BL2 firmware." - If the load is successful, BL1 updates the limits of the remaining free - trusted SRAM. It also populates information about the amount of trusted - SRAM used by the BL2 image. The exact load location of the image is - provided as a base address in the platform header. Further description of - the memory layout can be found later in this document. + BL1 calculates the amount of Trusted SRAM that can be used by the BL2 + image. The exact load location of the image is provided as a base address + in the platform header. Further description of the memory layout can be + found later in this document. -3. BL1 passes control to the BL2 image at Secure EL1, starting from its load - address. +3. BL1 passes control to the BL2 image at Secure EL1 (for AArch64) or at + Secure SVC mode (for AArch32), starting from its load address. 4. BL1 also passes information about the amount of trusted SRAM used and available for use. This information is populated at a platform-specific @@ -249,16 +298,21 @@ In the normal boot flow, BL1 execution continues as follows: ### BL2 -BL1 loads and passes control to BL2 at Secure-EL1. BL2 is linked against and -loaded at a platform-specific base address (more information can be found later -in this document). The functionality implemented by BL2 is as follows. +BL1 loads and passes control to BL2 at Secure-EL1 (for AArch64) or at Secure +SVC mode (for AArch32) . BL2 is linked against and loaded at a platform-specific +base address (more information can be found later in this document). +The functionality implemented by BL2 is as follows. #### Architectural initialization -BL2 performs minimal architectural initialization required for subsequent -stages of the ARM Trusted Firmware and normal world software. EL1 and EL0 are -given access to Floating Point & Advanced SIMD registers by clearing the -`CPACR.FPEN` bits. +For AArch64, BL2 performs the minimal architectural initialization required +for subsequent stages of the ARM Trusted Firmware and normal world software. +EL1 and EL0 are given access to Floating Point and Advanced SIMD registers +by clearing the `CPACR.FPEN` bits. + +For AArch32, the minimal architectural initialization required for subsequent +stages of the ARM Trusted Firmware and normal world software is taken care of +in BL1 as both BL1 and BL2 execute at PL1. #### Platform initialization @@ -270,10 +324,20 @@ On ARM platforms, BL2 performs the following platform initializations: * Enable the MMU and map the memory it needs to access. * Perform platform security setup to allow access to controlled components. * Reserve some memory for passing information to the next bootloader image - (BL31) and populate it. + EL3 Runtime Software and populate it. * Define the extents of memory available for loading each subsequent bootloader image. +#### Image loading in BL2 + +Image loading scheme in BL2 depends on `LOAD_IMAGE_V2` build option. If the +flag is disabled, the BLxx images are loaded, by calling the respective +load_blxx() function from BL2 generic code. If the flag is enabled, the BL2 +generic code loads the images based on the list of loadable images provided +by the platform. BL2 passes the list of executable images provided by the +platform to the next handover BL image. By default, this flag is disabled for +AArch64 and the AArch32 build is supported only if this flag is enabled. + #### SCP_BL2 (System Control Processor Firmware) image load Some systems have a separate System Control Processor (SCP) for power, clock, @@ -285,15 +349,16 @@ using the Boot Over MHU (BOM) protocol after being loaded in the trusted SRAM memory. The SCP executes SCP_BL2 and signals to the Application Processor (AP) for BL2 execution to continue. -#### BL31 (EL3 Runtime Firmware) image load +#### EL3 Runtime Software image load -BL2 loads the BL31 image from platform storage into a platform-specific address -in trusted SRAM. If there is not enough memory to load the image or image is -missing it leads to an assertion failure. If the BL31 image loads successfully, -BL2 updates the amount of trusted SRAM used and available for use by BL31. -This information is populated at a platform-specific memory address. +BL2 loads the EL3 Runtime Software image from platform storage into a platform- +specific address in trusted SRAM. If there is not enough memory to load the +image or image is missing it leads to an assertion failure. If `LOAD_IMAGE_V2` +is disabled and if image loads successfully, BL2 updates the amount of trusted +SRAM used and available for use by EL3 Runtime Software. This information is +populated at a platform-specific memory address. -#### BL32 (Secure-EL1 Payload) image load +#### AArch64 BL32 (Secure-EL1 Payload) image load BL2 loads the optional BL32 image from platform storage into a platform- specific region of secure memory. The image executes in the secure world. BL2 @@ -309,14 +374,14 @@ managing interaction with BL32. This information is passed to BL31. BL2 loads the BL33 image (e.g. UEFI or other test or boot software) from platform storage into non-secure memory as defined by the platform. -BL2 relies on BL31 to pass control to BL33 once secure state initialization is -complete. Hence, BL2 populates a platform-specific area of memory with the -entrypoint and Saved Program Status Register (`SPSR`) of the normal world -software image. The entrypoint is the load address of the BL33 image. The -`SPSR` is determined as specified in Section 5.13 of the [PSCI PDD] [PSCI]. This -information is passed to BL31. +BL2 relies on EL3 Runtime Software to pass control to BL33 once secure state +initialization is complete. Hence, BL2 populates a platform-specific area of +memory with the entrypoint and Saved Program Status Register (`SPSR`) of the +normal world software image. The entrypoint is the load address of the BL33 +image. The `SPSR` is determined as specified in Section 5.13 of the [PSCI PDD] +[PSCI]. This information is passed to the EL3 Runtime Software. -#### BL31 (EL3 Runtime Firmware) execution +#### AArch64 BL31 (EL3 Runtime Software) execution BL2 execution continues as follows: @@ -331,7 +396,7 @@ BL2 execution continues as follows: 3. BL1 passes control to BL31 at the specified entrypoint at EL3. -### BL31 +### AArch64 BL31 The image for this stage is loaded by BL2 and BL1 passes control to BL31 at EL3. BL31 executes solely in trusted SRAM. BL31 is linked against and @@ -394,29 +459,30 @@ detail in the "EL3 runtime services framework" section below. Details about the status of the PSCI implementation are provided in the "Power State Coordination Interface" section below. -#### BL32 (Secure-EL1 Payload) image initialization +#### AArch64 BL32 (Secure-EL1 Payload) image initialization If a BL32 image is present then there must be a matching Secure-EL1 Payload Dispatcher (SPD) service (see later for details). During initialization that service must register a function to carry out initialization of BL32 once the runtime services are fully initialized. BL31 invokes such a -registered function to initialize BL32 before running BL33. +registered function to initialize BL32 before running BL33. This initialization +is not necessary for AArch32 SPs. Details on BL32 initialization and the SPD's role are described in the "Secure-EL1 Payloads and Dispatchers" section below. #### BL33 (Non-trusted Firmware) execution -BL31 initializes the EL2 or EL1 processor context for normal-world cold -boot, ensuring that no secure state information finds its way into the -non-secure execution state. BL31 uses the entrypoint information provided -by BL2 to jump to the Non-trusted firmware image (BL33) at the highest -available Exception Level (EL2 if available, otherwise EL1). +EL3 Runtime Software initializes the EL2 or EL1 processor context for normal- +world cold boot, ensuring that no secure state information finds its way into +the non-secure execution state. EL3 Runtime Software uses the entrypoint +information provided by BL2 to jump to the Non-trusted firmware image (BL33) +at the highest available Exception Level (EL2 if available, otherwise EL1). -### Using alternative Trusted Boot Firmware in place of BL1 and BL2 +### Using alternative Trusted Boot Firmware in place of BL1 & BL2 (AArch64 only) Some platforms have existing implementations of Trusted Boot Firmware that -would like to use ARM Trusted Firmware BL31 for the EL3 Runtime Firmware. To +would like to use ARM Trusted Firmware BL31 for the EL3 Runtime Software. To enable this firmware architecture it is important to provide a fully documented and stable interface between the Trusted Boot Firmware and BL31. @@ -521,6 +587,85 @@ The PSCI implementation will initialize the processor state and ensure that the platform power management code is then invoked as required to initialize all necessary system, cluster and CPU resources. +### AArch32 EL3 Runtime Software entrypoint interface + +To enable this firmware architecture it is important to provide a fully +documented and stable interface between the Trusted Boot Firmware and the +AArch32 EL3 Runtime Software. + +Future changes to the entrypoint interface will be done in a backwards +compatible way, and this enables these firmware components to be independently +enhanced/updated to develop and exploit new functionality. + +#### Required CPU state when entering during cold boot + +This function must only be called by the primary CPU. + +On entry to this function the calling primary CPU must be executing in AArch32 +EL3, little-endian data access, and all interrupt sources masked: + + PSTATE.AIF = 0x7 + SCTLR.EE = 0 + +R0 and R1 are used to pass information from the Trusted Boot Firmware to the +platform code in AArch32 EL3 Runtime Software: + + R0 : Reserved for common Trusted Firmware information + R1 : Platform specific information + +##### Use of the R0 and R1 parameters + +The parameters are platform specific and the convention is that `R0` conveys +information regarding the BL3x images from the Trusted Boot firmware and `R1` +can be used for other platform specific purpose. This convention allows +platforms which use ARM Trusted Firmware's BL1 and BL2 images to transfer +additional platform specific information from Secure Boot without conflicting +with future evolution of the Trusted Firmware using `R0` to pass a `bl_params` +structure. + +The AArch32 EL3 Runtime Software is responsible for entry into BL33. This +information can be obtained in a platform defined manner, e.g. compiled into +the AArch32 EL3 Runtime Software, or provided in a platform defined memory +location by the Trusted Boot firmware, or passed from the Trusted Boot Firmware +via the Cold boot Initialization parameters. This data may need to be cleaned +out of the CPU caches if it is provided by an earlier boot stage and then +accessed by AArch32 EL3 Runtime Software before the caches are enabled. + +When using AArch32 EL3 Runtime Software, the ARM development platforms pass a +`bl_params` structure in `R0` from BL2 to be interpreted by AArch32 EL3 Runtime +Software platform code. + +##### MMU, Data caches & Coherency + +AArch32 EL3 Runtime Software must not depend on the enabled state of the MMU, +data caches or interconnect coherency in its entrypoint. They must be explicitly +enabled if required. + +##### Data structures used in cold boot interface + +The AArch32 EL3 Runtime Software cold boot interface uses `bl_params` instead +of `bl31_params`. The `bl_params` structure is based on the convention +described in AArch64 BL31 cold boot interface section. + +#### Required CPU state for warm boot initialization + +When requesting a CPU power-on, or suspending a running CPU, AArch32 EL3 +Runtime Software must ensure execution of a warm boot initialization entrypoint. +If ARM Trusted Firmware BL1 is used and the PROGRAMMABLE_RESET_ADDRESS build +flag is false, then AArch32 EL3 Runtime Software must ensure that BL1 branches +to the warm boot entrypoint by arranging for the BL1 platform function, +plat_get_my_entrypoint(), to return a non-zero value. + +In this case, the warm boot entrypoint must be in AArch32 EL3, little-endian +data access and all interrupt sources masked: + + PSTATE.AIF = 0x7 + SCTLR.EE = 0 + +The warm boot entrypoint may be implemented by using the ARM Trusted Firmware +`psci_warmboot_entrypoint()` function. In that case, the platform must fulfil +the pre-requisites mentioned in the [PSCI Library integration guide] +[PSCI Lib guide]. 3. EL3 runtime services framework ---------------------------------- @@ -536,7 +681,7 @@ The EL3 runtime services framework enables the development of services by different providers that can be easily integrated into final product firmware. The following sections describe the framework which facilitates the registration, initialization and use of runtime services in EL3 Runtime -Firmware (BL31). +Software (BL31). The design of the runtime services depends heavily on the concepts and definitions described in the [SMCCC], in particular SMC Function IDs, Owning @@ -562,7 +707,7 @@ not all been instantiated in the current implementation. [SMCCC] provides for such SMCs with the Trusted OS Call and Trusted Application Call OEN ranges. - The interface between the EL3 Runtime Firmware and the Secure-EL1 Payload is + The interface between the EL3 Runtime Software and the Secure-EL1 Payload is not defined by the [SMCCC] or any other standard. As a result, each Secure-EL1 Payload requires a specific Secure Monitor that runs as a runtime service - within ARM Trusted Firmware this service is referred to as the @@ -1192,13 +1337,13 @@ Additionally, if the platform memory layout implies some image overlaying like on FVP, BL31 and TSP need to know the limit address that their PROGBITS sections must not overstep. The platform code must provide those. -Trusted Firmware provides a mechanism to verify at boot time that the memory -to load a new image is free to prevent overwriting a previously loaded image. -For this mechanism to work, the platform must specify the memory available in -the system as regions, where each region consists of base address, total size -and the free area within it (as defined in the `meminfo_t` structure). Trusted -Firmware retrieves these memory regions by calling the corresponding platform -API: +When LOAD_IMAGE_V2 is disabled, Trusted Firmware provides a mechanism to +verify at boot time that the memory to load a new image is free to prevent +overwriting a previously loaded image. For this mechanism to work, the platform +must specify the memory available in the system as regions, where each region +consists of base address, total size and the free area within it (as defined +in the `meminfo_t` structure). Trusted Firmware retrieves these memory regions +by calling the corresponding platform API: * `meminfo_t *bl1_plat_sec_mem_layout(void)` * `meminfo_t *bl2_plat_sec_mem_layout(void)` @@ -1259,6 +1404,17 @@ And the following diagram is an example of an image loaded in the top part: +----------+ +When LOAD_IMAGE_V2 is enabled, Trusted Firmware does not provide any mechanism +to verify at boot time that the memory to load a new image is free to prevent +overwriting a previously loaded image. The platform must specify the memory +available in the system for all the relevant BL images to be loaded. + +For example, in the case of BL1 loading BL2, `bl1_plat_sec_mem_layout()` will +return the region defined by the platform where BL1 intends to load BL2. The +`load_image()` function performs bounds check for the image size based on the +base and maximum image size provided by the platforms. Platforms must take +this behaviour into account when defining the base/size for each of the images. + #### Memory layout on ARM development platforms The following list describes the memory layout on the ARM development platforms: @@ -1276,29 +1432,31 @@ The following list describes the memory layout on the ARM development platforms: Juno, BL1 resides in flash memory at address `0x0BEC0000`. BL1 read-write data are relocated to the top of Trusted SRAM at runtime. -* BL31 is loaded at the top of the Trusted SRAM, such that its NOBITS - sections will overwrite BL1 R/W data. This implies that BL1 global variables - remain valid only until execution reaches the BL31 entry point during - a cold boot. +* EL3 Runtime Software, BL31 for AArch64 and BL32 for AArch32 (e.g. SP_MIN), + is loaded at the top of the Trusted SRAM, such that its NOBITS sections will + overwrite BL1 R/W data. This implies that BL1 global variables remain valid + only until execution reaches the EL3 Runtime Software entry point during a + cold boot. -* BL2 is loaded below BL31. +* BL2 is loaded below EL3 Runtime Software. -* On Juno, SCP_BL2 is loaded temporarily into the BL31 memory region and - transfered to the SCP before being overwritten by BL31. +* On Juno, SCP_BL2 is loaded temporarily into the EL3 Runtime Software memory + region and transfered to the SCP before being overwritten by EL3 Runtime + Software. -* BL32 can be loaded in one of the following locations: +* BL32 (for AArch64) can be loaded in one of the following locations: * Trusted SRAM * Trusted DRAM (FVP only) * Secure region of DRAM (top 16MB of DRAM configured by the TrustZone controller) - When BL32 is loaded into Trusted SRAM, its NOBITS sections are allowed to - overlay BL2. This memory layout is designed to give the BL32 image as much - memory as possible when it is loaded into Trusted SRAM. + When BL32 (for AArch64) is loaded into Trusted SRAM, its NOBITS sections + are allowed to overlay BL2. This memory layout is designed to give the + BL32 image as much memory as possible when it is loaded into Trusted SRAM. -The memory regions for the overlap detection mechanism at boot time are -defined as follows (shown per API): +When LOAD_IMAGE_V2 is disabled the memory regions for the overlap detection +mechanism at boot time are defined as follows (shown per API): * `meminfo_t *bl1_plat_sec_mem_layout(void)` @@ -1343,6 +1501,7 @@ Note: Loading the BL32 image in TZC secured DRAM doesn't change the memory layout of the other images in Trusted SRAM. **FVP with TSP in Trusted SRAM (default option):** +(These diagrams only cover the AArch64 case) Trusted SRAM 0x04040000 +----------+ loaded by BL2 ------------------ @@ -1858,7 +2017,128 @@ This build flag is disabled by default, minimising memory footprint. On ARM platforms, it is enabled. -13. Code Structure +13. Performance Measurement Framework +-------------------------------------- + +The Performance Measurement Framework (PMF) facilitates collection of +timestamps by registered services and provides interfaces to retrieve +them from within the ARM Trusted Firmware. A platform can choose to +expose appropriate SMCs to retrieve these collected timestamps. + +By default, the global physical counter is used for the timestamp +value and is read via `CNTPCT_EL0`. The framework allows to retrieve +timestamps captured by other CPUs. + +### Timestamp identifier format + +A PMF timestamp is uniquely identified across the system via the +timestamp ID or `tid`. The `tid` is composed as follows: + + Bits 0-7: The local timestamp identifier. + Bits 8-9: Reserved. + Bits 10-15: The service identifier. + Bits 16-31: Reserved. + +1. The service identifier. Each PMF service is identified by a + service name and a service identifier. Both the service name and + identifier are unique within the system as a whole. + +2. The local timestamp identifier. This identifier is unique within a given + service. + +### Registering a PMF service + +To register a PMF service, the `PMF_REGISTER_SERVICE()` macro from `pmf.h` +is used. The arguments required are the service name, the service ID, +the total number of local timestamps to be captured and a set of flags. + +The `flags` field can be specified as a bitwise-OR of the following values: + + PMF_STORE_ENABLE: The timestamp is stored in memory for later retrieval. + PMF_DUMP_ENABLE: The timestamp is dumped on the serial console. + +The `PMF_REGISTER_SERVICE()` reserves memory to store captured +timestamps in a PMF specific linker section at build time. +Additionally, it defines necessary functions to capture and +retrieve a particular timestamp for the given service at runtime. + +The macro `PMF_REGISTER_SERVICE()` only enables capturing PMF +timestamps from within ARM Trusted Firmware. In order to retrieve +timestamps from outside of ARM Trusted Firmware, the +`PMF_REGISTER_SERVICE_SMC()` macro must be used instead. This macro +accepts the same set of arguments as the `PMF_REGISTER_SERVICE()` +macro but additionally supports retrieving timestamps using SMCs. + +### Capturing a timestamp + +PMF timestamps are stored in a per-service timestamp region. On a +system with multiple CPUs, each timestamp is captured and stored +in a per-CPU cache line aligned memory region. + +Having registered the service, the `PMF_CAPTURE_TIMESTAMP()` macro can be +used to capture a timestamp at the location where it is used. The macro +takes the service name, a local timestamp identifier and a flag as arguments. + +The `flags` field argument can be zero, or `PMF_CACHE_MAINT` which +instructs PMF to do cache maintenance following the capture. Cache +maintenance is required if any of the service's timestamps are captured +with data cache disabled. + +To capture a timestamp in assembly code, the caller should use +`pmf_calc_timestamp_addr` macro (defined in `pmf_asm_macros.S`) to +calculate the address of where the timestamp would be stored. The +caller should then read `CNTPCT_EL0` register to obtain the timestamp +and store it at the determined address for later retrieval. + +### Retrieving a timestamp + +From within ARM Trusted Firmware, timestamps for individual CPUs can +be retrieved using either `PMF_GET_TIMESTAMP_BY_MPIDR()` or +`PMF_GET_TIMESTAMP_BY_INDEX()` macros. These macros accept the CPU's MPIDR +value, or its ordinal position, respectively. + +From outside ARM Trusted Firmware, timestamps for individual CPUs can be +retrieved by calling into `pmf_smc_handler()`. + + Interface : pmf_smc_handler() + Argument : unsigned int smc_fid, u_register_t x1, + u_register_t x2, u_register_t x3, + u_register_t x4, void *cookie, + void *handle, u_register_t flags + Return : uintptr_t + + smc_fid: Holds the SMC identifier which is either `PMF_SMC_GET_TIMESTAMP_32` + when the caller of the SMC is running in AArch32 mode + or `PMF_SMC_GET_TIMESTAMP_64` when the caller is running in AArch64 mode. + x1: Timestamp identifier. + x2: The `mpidr` of the CPU for which the timestamp has to be retrieved. + This can be the `mpidr` of a different core to the one initiating + the SMC. In that case, service specific cache maintenance may be + required to ensure the updated copy of the timestamp is returned. + x3: A flags value that is either 0 or `PMF_CACHE_MAINT`. If + `PMF_CACHE_MAINT` is passed, then the PMF code will perform a + cache invalidate before reading the timestamp. This ensures + an updated copy is returned. + +The remaining arguments, `x4`, `cookie`, `handle` and `flags` are unused +in this implementation. + +### PMF code structure + +1. `pmf_main.c` consists of core functions that implement service registration, + initialization, storing, dumping and retrieving timestamps. + +2. `pmf_smc.c` contains the SMC handling for registered PMF services. + +3. `pmf.h` contains the public interface to Performance Measurement Framework. + +4. `pmf_asm_macros.S` consists of macros to facilitate capturing timestamps in + assembly code. + +5. `pmf_helpers.h` is an internal header used by `pmf.h`. + + +14. Code Structure ------------------- Trusted Firmware code is logically divided between the three boot loader @@ -1902,7 +2182,7 @@ FDTs provide a description of the hardware platform and are used by the Linux kernel at boot time. These can be found in the `fdts` directory. -14. References +15. References --------------- 1. Trusted Board Boot Requirements CLIENT PDD (ARM DEN 0006B-5). Available diff --git a/docs/porting-guide.md b/docs/porting-guide.md index 93c0169a..8e913b90 100644 --- a/docs/porting-guide.md +++ b/docs/porting-guide.md @@ -8,7 +8,7 @@ Contents 2. [Common Modifications](#2--common-modifications) * [Common mandatory modifications](#21-common-mandatory-modifications) * [Handling reset](#22-handling-reset) - * [Common mandatory modifications](#23-common-mandatory-modifications) + * [Common mandatory function modifications](#23-common-mandatory-function-modifications) * [Common optional modifications](#24-common-optional-modifications) 3. [Boot Loader stage specific modifications](#3--modifications-specific-to-a-boot-loader-stage) * [Boot Loader stage 1 (BL1)](#31-boot-loader-stage-1-bl1) @@ -685,7 +685,7 @@ The function returns 0 on success. Any other value means the counter value could not be updated. -2.3 Common mandatory modifications +2.3 Common mandatory function modifications --------------------------------- The following functions are mandatory functions which need to be implemented diff --git a/docs/user-guide.md b/docs/user-guide.md index a07185d4..5b73b663 100644 --- a/docs/user-guide.md +++ b/docs/user-guide.md @@ -89,23 +89,46 @@ Download the Trusted Firmware source code from Github: --------------------------------- * Before building Trusted Firmware, the environment variable `CROSS_COMPILE` - must point to the Linaro cross compiler: + must point to the Linaro cross compiler. + + For AArch64: export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-linux-gnu- -* Change to the root directory of the Trusted Firmware source tree and build: + For AArch32: + + export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf- + +* Change to the root directory of the Trusted Firmware source tree and build. + + For AArch64: make PLAT=<platform> all - Notes: + For AArch32: + + make PLAT=<platform> ARCH=aarch32 AARCH32_SP=sp_min all + + + Notes: * If `PLAT` is not specified, `fvp` is assumed by default. See the "Summary of build options" for more information on available build options. - * The TSP (Test Secure Payload), corresponding to the BL32 image, is not - compiled in by default. Refer to the "Building the Test Secure Payload" - section below. + * (AArch32 only) Currently only `PLAT=fvp` is supported. + + * (AArch32 only) `AARCH32_SP` is the AArch32 EL3 Runtime Software and it + corresponds to the BL32 image. A minimal `AARCH32_SP`, sp_min, is + provided by ARM Trusted Firmware to demonstrate how PSCI Library can + be integrated with an AArch32 EL3 Runtime Software. Some AArch32 EL3 + Runtime Software may include other runtime services, for example + Trusted OS services. A guide to integrate PSCI library with AArch32 + EL3 Runtime Software can be found [here][PSCI Lib Integration]. + + * (AArch64 only) The TSP (Test Secure Payload), corresponding to the BL32 + image, is not compiled in by default. Refer to the "Building the Test + Secure Payload" section below. * By default this produces a release version of the build. To produce a debug version instead, refer to the "Debugging options" section below. @@ -117,7 +140,8 @@ Download the Trusted Firmware source code from Github: * `build/<platform>/<build-type>/bl1.bin` * `build/<platform>/<build-type>/bl2.bin` - * `build/<platform>/<build-type>/bl31.bin` + * `build/<platform>/<build-type>/bl31.bin` (AArch64 only) + * `build/<platform>/<build-type>/bl32.bin` (mandatory for AArch32) where `<platform>` is the name of the chosen platform and `<build-type>` is either `debug` or `release`. The actual number of images might differ @@ -238,6 +262,12 @@ performed. entrypoint) or 1 (CPU reset to BL31 entrypoint). The default value is 0. +* `RESET_TO_SP_MIN`: SP_MIN is the minimal AArch32 Secure Payload provided in + ARM Trusted Firmware. This flag configures SP_MIN entrypoint as the CPU + reset vector instead of the BL1 entrypoint. It can take the value 0 (CPU + reset to BL1 entrypoint) or 1 (CPU reset to SP_MIN entrypoint). The default + value is 0. + * `CRASH_REPORTING`: A non-zero value enables a console dump of processor register state when an unexpected exception occurs during execution of BL31. This option defaults to the value of `DEBUG` - i.e. by default @@ -598,8 +628,7 @@ BL31 binary. Then to build the TSP image use: An additional boot loader binary file is created in the `build` directory: - `build/<platform>/<build-type>/bl32.bin` - + build/<platform>/<build-type>/bl32.bin ### Checking source code style @@ -634,14 +663,26 @@ platforms require a BL33 image which corresponds to the normal world bootloader (e.g. UEFI or U-Boot). The TF build system provides the make target `fip` to create a FIP file for the -specified platform using the FIP creation tool included in the TF project. For -example, to build a FIP file for FVP, packaging TF images and a BL33 image: +specified platform using the FIP creation tool included in the TF project. +Examples below show how to build a FIP file for FVP, packaging TF images and a +BL33 image. + +For AArch64: make PLAT=fvp BL33=<path/to/bl33.bin> fip +For AArch32: + + make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=<path/to/bl33.bin> fip + +Note that AArch32 support for Normal world boot loader (BL33), like U-boot or +UEFI, on FVP is not available upstream. Hence custom solutions are required to +allow Linux boot on FVP. These instructions assume such a custom boot loader +(BL33) is available. + The resulting FIP may be found in: - `build/fvp/<build-type>/fip.bin` + build/fvp/<build-type>/fip.bin For advanced operations on FIP files, it is also possible to independently build the tool and create or modify FIPs using this tool. To do this, follow these @@ -830,6 +871,9 @@ Firmware, obtain the additional required firmware, and pack it all together in a single FIP binary. It assumes that a [Linaro Release][Linaro Release Notes] has been installed. +Note currently [Linaro Release][Linaro Release Notes] only includes pre-built +binaries for AArch64. For AArch32, pre-built binaries are not available. + Note: follow the full instructions for one platform before switching to a different one. Mixing instructions for different platforms may result in corrupted binaries. @@ -858,14 +902,20 @@ corrupted binaries. exist in the current directory. If that is the case, either delete those files or use the `--force` option to overwrite. + Note for AArch32, the instructions below assume that nt-fw.bin is a custom + Normal world boot loader that supports AArch32. + 3. Build TF images and create a new FIP # Juno make PLAT=juno SCP_BL2=scp-fw.bin BL33=nt-fw.bin all fip - # FVP + # FVP AArch64 make PLAT=fvp BL33=nt-fw.bin all fip + # FVP AArch32 + make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=nt-fw.bin all fip + The resulting BL1 and FIP images may be found in: # Juno @@ -1034,16 +1084,16 @@ used when compiling the FIP must match the ELF entry point. #### Boot of a preloaded bootwrapped kernel image on Juno The procedure to obtain and compile the boot wrapper is very similar to the case -of the FVP. Once compiled, the `SPIN_ON_BL1_EXIT=1` loading method explained -above in the EL3 payload boot flow section may be used to load the ELF file over -JTAG on Juno. +of the FVP. The execution must be stopped at the end of bl2_main(), and the +loading method explained above in the EL3 payload boot flow section may be used +to load the ELF file over JTAG on Juno. 9. Running the software on FVP ------------------------------- -This version of the ARM Trusted Firmware has been tested on the following ARM -FVPs (64-bit versions only). +The AArch64 build of this version of ARM Trusted Firmware has been tested on +the following ARM FVPs (64-bit host machine only). * `Foundation_Platform` (Version 10.1, Build 10.1.32) * `FVP_Base_AEMv8A-AEMv8A` (Version 7.7, Build 0.8.7701) @@ -1051,6 +1101,12 @@ FVPs (64-bit versions only). * `FVP_Base_Cortex-A57x1-A53x1` (Version 7.7, Build 0.8.7701) * `FVP_Base_Cortex-A57x2-A53x4` (Version 7.7, Build 0.8.7701) +The AArch32 build of this version of ARM Trusted Firmware has been tested on +the following ARM FVPs (64-bit host machine only). + +* `FVP_Base_AEMv8A-AEMv8A` (Version 7.7, Build 0.8.7701) +* `FVP_Base_Cortex-A32x4` (Version 10.1, Build 10.1.32) + NOTE: The build numbers quoted above are those reported by launching the FVP with the `--version` parameter. @@ -1082,11 +1138,21 @@ all FDTs are available from there. For use with both AEMv8 and Cortex-A57-A53 Base FVPs with Base memory map configuration. +* `fvp-base-gicv2-psci-aarch32.dtb` + + For use with AEMv8 and Cortex-A32 Base FVPs running Linux in AArch32 state + with Base memory map configuration. + * `fvp-base-gicv3-psci.dtb` (Default) For use with both AEMv8 and Cortex-A57-A53 Base FVPs with Base memory map configuration and Linux GICv3 support. +* `fvp-base-gicv3-psci-aarch32.dtb` + + For use with AEMv8 and Cortex-A32 Base FVPs running Linux in AArch32 state + with Base memory map configuration and Linux GICv3 support. + * `fvp-foundation-gicv2-psci.dtb` For use with Foundation FVP with Base memory map configuration. @@ -1099,7 +1165,7 @@ all FDTs are available from there. ### Running on the Foundation FVP with reset to BL1 entrypoint The following `Foundation_Platform` parameters should be used to boot Linux with -4 CPUs using the ARM Trusted Firmware. +4 CPUs using the AArch64 build of ARM Trusted Firmware. <path-to>/Foundation_Platform \ --cores=4 \ @@ -1124,7 +1190,7 @@ Notes: ### Running on the AEMv8 Base FVP with reset to BL1 entrypoint The following `FVP_Base_AEMv8A-AEMv8A` parameters should be used to boot Linux -with 8 CPUs using the ARM Trusted Firmware. +with 8 CPUs using the AArch64 build of ARM Trusted Firmware. <path-to>/FVP_Base_AEMv8A-AEMv8A \ -C pctl.startup=0.0.0.0 \ @@ -1139,10 +1205,36 @@ with 8 CPUs using the ARM Trusted Firmware. --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ -C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>" +### Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint + +The following `FVP_Base_AEMv8A-AEMv8A` parameters should be used to boot Linux +with 8 CPUs using the AArch32 build of ARM Trusted Firmware. + + <path-to>/FVP_Base_AEMv8A-AEMv8A \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cluster0.NUM_CORES=4 \ + -C cluster1.NUM_CORES=4 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.CONFIG64=0 \ + -C cluster0.cpu1.CONFIG64=0 \ + -C cluster0.cpu2.CONFIG64=0 \ + -C cluster0.cpu3.CONFIG64=0 \ + -C cluster1.cpu0.CONFIG64=0 \ + -C cluster1.cpu1.CONFIG64=0 \ + -C cluster1.cpu2.CONFIG64=0 \ + -C cluster1.cpu3.CONFIG64=0 \ + -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \ + -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x83000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + -C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>" + ### Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint The following `FVP_Base_Cortex-A57x4-A53x4` model parameters should be used to -boot Linux with 8 CPUs using the ARM Trusted Firmware. +boot Linux with 8 CPUs using the AArch64 build of ARM Trusted Firmware. <path-to>/FVP_Base_Cortex-A57x4-A53x4 \ -C pctl.startup=0.0.0.0 \ @@ -1155,10 +1247,26 @@ boot Linux with 8 CPUs using the ARM Trusted Firmware. --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ -C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>" +### Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint + +The following `FVP_Base_Cortex-A32x4` model parameters should be used to +boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. + + <path-to>/FVP_Base_Cortex-A32x4 \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cache_state_modelled=1 \ + -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \ + -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x83000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + -C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>" + ### Running on the AEMv8 Base FVP with reset to BL31 entrypoint The following `FVP_Base_AEMv8A-AEMv8A` parameters should be used to boot Linux -with 8 CPUs using the ARM Trusted Firmware. +with 8 CPUs using the AArch64 build of ARM Trusted Firmware. <path-to>/FVP_Base_AEMv8A-AEMv8A \ -C pctl.startup=0.0.0.0 \ @@ -1199,10 +1307,47 @@ Notes: `--data="<path-to><bl32-binary>"@<base-address-of-bl32>` to the new value of `BL32_BASE`. +### Running on the AEMv8 Base FVP (AArch32) with reset to SP_MIN entrypoint + +The following `FVP_Base_AEMv8A-AEMv8A` parameters should be used to boot Linux +with 8 CPUs using the AArch32 build of ARM Trusted Firmware. + + <path-to>/FVP_Base_AEMv8A-AEMv8A \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cluster0.NUM_CORES=4 \ + -C cluster1.NUM_CORES=4 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.CONFIG64=0 \ + -C cluster0.cpu1.CONFIG64=0 \ + -C cluster0.cpu2.CONFIG64=0 \ + -C cluster0.cpu3.CONFIG64=0 \ + -C cluster1.cpu0.CONFIG64=0 \ + -C cluster1.cpu1.CONFIG64=0 \ + -C cluster1.cpu2.CONFIG64=0 \ + -C cluster1.cpu3.CONFIG64=0 \ + -C cluster0.cpu0.RVBAR=0x04001000 \ + -C cluster0.cpu1.RVBAR=0x04001000 \ + -C cluster0.cpu2.RVBAR=0x04001000 \ + -C cluster0.cpu3.RVBAR=0x04001000 \ + -C cluster1.cpu0.RVBAR=0x04001000 \ + -C cluster1.cpu1.RVBAR=0x04001000 \ + -C cluster1.cpu2.RVBAR=0x04001000 \ + -C cluster1.cpu3.RVBAR=0x04001000 \ + --data cluster0.cpu0="<path-to>/<bl32-binary>"@0x04001000 \ + --data cluster0.cpu0="<path-to>/<bl33-binary>"@0x88000000 \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x83000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + -C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>" + +Note: The load address of `<bl32-binary>` depends on the value `BL32_BASE`. +It should match the address programmed into the RVBAR register as well. + ### Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint The following `FVP_Base_Cortex-A57x4-A53x4` model parameters should be used to -boot Linux with 8 CPUs using the ARM Trusted Firmware. +boot Linux with 8 CPUs using the AArch64 build of ARM Trusted Firmware. <path-to>/FVP_Base_Cortex-A57x4-A53x4 \ -C pctl.startup=0.0.0.0 \ @@ -1224,6 +1369,25 @@ boot Linux with 8 CPUs using the ARM Trusted Firmware. --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ -C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>" +### Running on the Cortex-A32 Base FVP (AArch32) with reset to SP_MIN entrypoint + +The following `FVP_Base_Cortex-A32x4` model parameters should be used to +boot Linux with 4 CPUs using the AArch32 build of ARM Trusted Firmware. + + <path-to>/FVP_Base_Cortex-A32x4 \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.RVBARADDR=0x04001000 \ + -C cluster0.cpu1.RVBARADDR=0x04001000 \ + -C cluster0.cpu2.RVBARADDR=0x04001000 \ + -C cluster0.cpu3.RVBARADDR=0x04001000 \ + --data cluster0.cpu0="<path-to>/<bl32-binary>"@0x04001000 \ + --data cluster0.cpu0="<path-to>/<bl33-binary>"@0x88000000 \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x83000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + -C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>" 10. Running the software on Juno --------------------------------- @@ -1280,3 +1444,4 @@ _Copyright (c) 2013-2016, ARM Limited and Contributors. All rights reserved._ [PSCI]: http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf "Power State Coordination Interface PDD (ARM DEN 0022C)" [Trusted Board Boot]: trusted-board-boot.md [Firmware Update]: ./firmware-update.md +[PSCI Lib Integration]: ./psci-lib-integration-guide.md diff --git a/fdts/fvp-base-gicv2-psci-aarch32.dtb b/fdts/fvp-base-gicv2-psci-aarch32.dtb Binary files differnew file mode 100644 index 00000000..b044a769 --- /dev/null +++ b/fdts/fvp-base-gicv2-psci-aarch32.dtb diff --git a/fdts/fvp-base-gicv2-psci-aarch32.dts b/fdts/fvp-base-gicv2-psci-aarch32.dts new file mode 100644 index 00000000..3a6007de --- /dev/null +++ b/fdts/fvp-base-gicv2-psci-aarch32.dts @@ -0,0 +1,331 @@ +/* + * Copyright (c) 2016, ARM Limited and Contributors. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * + * Redistributions of source code must retain the above copyright notice, this + * list of conditions and the following disclaimer. + * + * Redistributions in binary form must reproduce the above copyright notice, + * this list of conditions and the following disclaimer in the documentation + * and/or other materials provided with the distribution. + * + * Neither the name of ARM nor the names of its contributors may be used + * to endorse or promote products derived from this software without specific + * prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +/dts-v1/; + +/memreserve/ 0x80000000 0x00010000; + +/ { +}; + +/ { + model = "FVP Base"; + compatible = "arm,vfp-base", "arm,vexpress"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + chosen { }; + + aliases { + serial0 = &v2m_serial0; + serial1 = &v2m_serial1; + serial2 = &v2m_serial2; + serial3 = &v2m_serial3; + }; + + psci { + compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci"; + method = "smc"; + cpu_suspend = <0x84000001>; + cpu_off = <0x84000002>; + cpu_on = <0x84000003>; + sys_poweroff = <0x84000008>; + sys_reset = <0x84000009>; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + core1 { + cpu = <&CPU1>; + }; + core2 { + cpu = <&CPU2>; + }; + core3 { + cpu = <&CPU3>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU4>; + }; + core1 { + cpu = <&CPU5>; + }; + core2 { + cpu = <&CPU6>; + }; + core3 { + cpu = <&CPU7>; + }; + }; + }; + + idle-states { + entry-method = "arm,psci"; + + CPU_SLEEP_0: cpu-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <40>; + exit-latency-us = <100>; + min-residency-us = <150>; + }; + + CLUSTER_SLEEP_0: cluster-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <500>; + exit-latency-us = <1000>; + min-residency-us = <2500>; + }; + }; + + CPU0:cpu@0 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU1:cpu@1 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU2:cpu@2 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x2>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU3:cpu@3 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x3>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU4:cpu@100 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU5:cpu@101 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU6:cpu@102 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x102>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU7:cpu@103 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x103>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + L2_0: l2-cache0 { + compatible = "cache"; + }; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x7F000000>, + <0x00000008 0x80000000 0 0x80000000>; + }; + + gic: interrupt-controller@2f000000 { + compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x0 0x2f000000 0 0x10000>, + <0x0 0x2c000000 0 0x2000>, + <0x0 0x2c010000 0 0x2000>, + <0x0 0x2c02F000 0 0x2000>; + interrupts = <1 9 0xf04>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0xff01>, + <1 14 0xff01>, + <1 11 0xff01>, + <1 10 0xff01>; + clock-frequency = <100000000>; + }; + + timer@2a810000 { + compatible = "arm,armv7-timer-mem"; + reg = <0x0 0x2a810000 0x0 0x10000>; + clock-frequency = <100000000>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + frame@2a830000 { + frame-number = <1>; + interrupts = <0 26 4>; + reg = <0x0 0x2a830000 0x0 0x10000>; + }; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <0 60 4>, + <0 61 4>, + <0 62 4>, + <0 63 4>; + }; + + smb { + compatible = "simple-bus"; + + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0 0x08000000 0x04000000>, + <1 0 0 0x14000000 0x04000000>, + <2 0 0 0x18000000 0x04000000>, + <3 0 0 0x1c000000 0x04000000>, + <4 0 0 0x0c000000 0x04000000>, + <5 0 0 0x10000000 0x04000000>; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 63>; + interrupt-map = <0 0 0 &gic 0 0 4>, + <0 0 1 &gic 0 1 4>, + <0 0 2 &gic 0 2 4>, + <0 0 3 &gic 0 3 4>, + <0 0 4 &gic 0 4 4>, + <0 0 5 &gic 0 5 4>, + <0 0 6 &gic 0 6 4>, + <0 0 7 &gic 0 7 4>, + <0 0 8 &gic 0 8 4>, + <0 0 9 &gic 0 9 4>, + <0 0 10 &gic 0 10 4>, + <0 0 11 &gic 0 11 4>, + <0 0 12 &gic 0 12 4>, + <0 0 13 &gic 0 13 4>, + <0 0 14 &gic 0 14 4>, + <0 0 15 &gic 0 15 4>, + <0 0 16 &gic 0 16 4>, + <0 0 17 &gic 0 17 4>, + <0 0 18 &gic 0 18 4>, + <0 0 19 &gic 0 19 4>, + <0 0 20 &gic 0 20 4>, + <0 0 21 &gic 0 21 4>, + <0 0 22 &gic 0 22 4>, + <0 0 23 &gic 0 23 4>, + <0 0 24 &gic 0 24 4>, + <0 0 25 &gic 0 25 4>, + <0 0 26 &gic 0 26 4>, + <0 0 27 &gic 0 27 4>, + <0 0 28 &gic 0 28 4>, + <0 0 29 &gic 0 29 4>, + <0 0 30 &gic 0 30 4>, + <0 0 31 &gic 0 31 4>, + <0 0 32 &gic 0 32 4>, + <0 0 33 &gic 0 33 4>, + <0 0 34 &gic 0 34 4>, + <0 0 35 &gic 0 35 4>, + <0 0 36 &gic 0 36 4>, + <0 0 37 &gic 0 37 4>, + <0 0 38 &gic 0 38 4>, + <0 0 39 &gic 0 39 4>, + <0 0 40 &gic 0 40 4>, + <0 0 41 &gic 0 41 4>, + <0 0 42 &gic 0 42 4>; + + /include/ "rtsm_ve-motherboard.dtsi" + }; + + panels { + panel@0 { + compatible = "panel"; + mode = "XVGA"; + refresh = <60>; + xres = <1024>; + yres = <768>; + pixclock = <15748>; + left_margin = <152>; + right_margin = <48>; + upper_margin = <23>; + lower_margin = <3>; + hsync_len = <104>; + vsync_len = <4>; + sync = <0>; + vmode = "FB_VMODE_NONINTERLACED"; + tim2 = "TIM2_BCD", "TIM2_IPC"; + cntl = "CNTL_LCDTFT", "CNTL_BGR", "CNTL_LCDVCOMP(1)"; + caps = "CLCD_CAP_5551", "CLCD_CAP_565", "CLCD_CAP_888"; + bpp = <16>; + }; + }; +}; diff --git a/fdts/fvp-base-gicv3-psci-aarch32.dtb b/fdts/fvp-base-gicv3-psci-aarch32.dtb Binary files differnew file mode 100644 index 00000000..474b1888 --- /dev/null +++ b/fdts/fvp-base-gicv3-psci-aarch32.dtb diff --git a/fdts/fvp-base-gicv3-psci-aarch32.dts b/fdts/fvp-base-gicv3-psci-aarch32.dts new file mode 100644 index 00000000..ab699151 --- /dev/null +++ b/fdts/fvp-base-gicv3-psci-aarch32.dts @@ -0,0 +1,340 @@ +/* + * Copyright (c) 2016, ARM Limited and Contributors. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions are met: + * + * Redistributions of source code must retain the above copyright notice, this + * list of conditions and the following disclaimer. + * + * Redistributions in binary form must reproduce the above copyright notice, + * this list of conditions and the following disclaimer in the documentation + * and/or other materials provided with the distribution. + * + * Neither the name of ARM nor the names of its contributors may be used + * to endorse or promote products derived from this software without specific + * prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + * POSSIBILITY OF SUCH DAMAGE. + */ + +/dts-v1/; + +/memreserve/ 0x80000000 0x00010000; + +/ { +}; + +/ { + model = "FVP Base"; + compatible = "arm,vfp-base", "arm,vexpress"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + chosen { }; + + aliases { + serial0 = &v2m_serial0; + serial1 = &v2m_serial1; + serial2 = &v2m_serial2; + serial3 = &v2m_serial3; + }; + + psci { + compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci"; + method = "smc"; + cpu_suspend = <0x84000001>; + cpu_off = <0x84000002>; + cpu_on = <0x84000003>; + sys_poweroff = <0x84000008>; + sys_reset = <0x84000009>; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + core1 { + cpu = <&CPU1>; + }; + core2 { + cpu = <&CPU2>; + }; + core3 { + cpu = <&CPU3>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU4>; + }; + core1 { + cpu = <&CPU5>; + }; + core2 { + cpu = <&CPU6>; + }; + core3 { + cpu = <&CPU7>; + }; + }; + }; + + idle-states { + entry-method = "arm,psci"; + + CPU_SLEEP_0: cpu-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x0010000>; + entry-latency-us = <40>; + exit-latency-us = <100>; + min-residency-us = <150>; + }; + + CLUSTER_SLEEP_0: cluster-sleep-0 { + compatible = "arm,idle-state"; + local-timer-stop; + arm,psci-suspend-param = <0x1010000>; + entry-latency-us = <500>; + exit-latency-us = <1000>; + min-residency-us = <2500>; + }; + }; + + CPU0:cpu@0 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU1:cpu@1 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU2:cpu@2 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x2>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU3:cpu@3 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x3>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU4:cpu@100 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU5:cpu@101 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU6:cpu@102 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x102>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + CPU7:cpu@103 { + device_type = "cpu"; + compatible = "arm,armv8"; + reg = <0x103>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + next-level-cache = <&L2_0>; + }; + + L2_0: l2-cache0 { + compatible = "cache"; + }; + }; + + memory@80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x7F000000>, + <0x00000008 0x80000000 0 0x80000000>; + }; + + gic: interrupt-controller@2f000000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + interrupt-controller; + reg = <0x0 0x2f000000 0 0x10000>, // GICD + <0x0 0x2f100000 0 0x200000>, // GICR + <0x0 0x2c000000 0 0x2000>, // GICC + <0x0 0x2c010000 0 0x2000>, // GICH + <0x0 0x2c02f000 0 0x2000>; // GICV + interrupts = <1 9 4>; + + its: its@2f020000 { + compatible = "arm,gic-v3-its"; + msi-controller; + reg = <0x0 0x2f020000 0x0 0x20000>; // GITS + }; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <1 13 0xff01>, + <1 14 0xff01>, + <1 11 0xff01>, + <1 10 0xff01>; + clock-frequency = <100000000>; + }; + + timer@2a810000 { + compatible = "arm,armv7-timer-mem"; + reg = <0x0 0x2a810000 0x0 0x10000>; + clock-frequency = <100000000>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + frame@2a830000 { + frame-number = <1>; + interrupts = <0 26 4>; + reg = <0x0 0x2a830000 0x0 0x10000>; + }; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <0 60 4>, + <0 61 4>, + <0 62 4>, + <0 63 4>; + }; + + smb { + compatible = "simple-bus"; + + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0 0x08000000 0x04000000>, + <1 0 0 0x14000000 0x04000000>, + <2 0 0 0x18000000 0x04000000>, + <3 0 0 0x1c000000 0x04000000>, + <4 0 0 0x0c000000 0x04000000>, + <5 0 0 0x10000000 0x04000000>; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 63>; + interrupt-map = <0 0 0 &gic 0 0 0 0 4>, + <0 0 1 &gic 0 0 0 1 4>, + <0 0 2 &gic 0 0 0 2 4>, + <0 0 3 &gic 0 0 0 3 4>, + <0 0 4 &gic 0 0 0 4 4>, + <0 0 5 &gic 0 0 0 5 4>, + <0 0 6 &gic 0 0 0 6 4>, + <0 0 7 &gic 0 0 0 7 4>, + <0 0 8 &gic 0 0 0 8 4>, + <0 0 9 &gic 0 0 0 9 4>, + <0 0 10 &gic 0 0 0 10 4>, + <0 0 11 &gic 0 0 0 11 4>, + <0 0 12 &gic 0 0 0 12 4>, + <0 0 13 &gic 0 0 0 13 4>, + <0 0 14 &gic 0 0 0 14 4>, + <0 0 15 &gic 0 0 0 15 4>, + <0 0 16 &gic 0 0 0 16 4>, + <0 0 17 &gic 0 0 0 17 4>, + <0 0 18 &gic 0 0 0 18 4>, + <0 0 19 &gic 0 0 0 19 4>, + <0 0 20 &gic 0 0 0 20 4>, + <0 0 21 &gic 0 0 0 21 4>, + <0 0 22 &gic 0 0 0 22 4>, + <0 0 23 &gic 0 0 0 23 4>, + <0 0 24 &gic 0 0 0 24 4>, + <0 0 25 &gic 0 0 0 25 4>, + <0 0 26 &gic 0 0 0 26 4>, + <0 0 27 &gic 0 0 0 27 4>, + <0 0 28 &gic 0 0 0 28 4>, + <0 0 29 &gic 0 0 0 29 4>, + <0 0 30 &gic 0 0 0 30 4>, + <0 0 31 &gic 0 0 0 31 4>, + <0 0 32 &gic 0 0 0 32 4>, + <0 0 33 &gic 0 0 0 33 4>, + <0 0 34 &gic 0 0 0 34 4>, + <0 0 35 &gic 0 0 0 35 4>, + <0 0 36 &gic 0 0 0 36 4>, + <0 0 37 &gic 0 0 0 37 4>, + <0 0 38 &gic 0 0 0 38 4>, + <0 0 39 &gic 0 0 0 39 4>, + <0 0 40 &gic 0 0 0 40 4>, + <0 0 41 &gic 0 0 0 41 4>, + <0 0 42 &gic 0 0 0 42 4>; + + /include/ "rtsm_ve-motherboard.dtsi" + }; + + panels { + panel@0 { + compatible = "panel"; + mode = "XVGA"; + refresh = <60>; + xres = <1024>; + yres = <768>; + pixclock = <15748>; + left_margin = <152>; + right_margin = <48>; + upper_margin = <23>; + lower_margin = <3>; + hsync_len = <104>; + vsync_len = <4>; + sync = <0>; + vmode = "FB_VMODE_NONINTERLACED"; + tim2 = "TIM2_BCD", "TIM2_IPC"; + cntl = "CNTL_LCDTFT", "CNTL_BGR", "CNTL_LCDVCOMP(1)"; + caps = "CLCD_CAP_5551", "CLCD_CAP_565", "CLCD_CAP_888"; + bpp = <16>; + }; + }; +}; diff --git a/fdts/fvp-base-gicv3-psci.dtb b/fdts/fvp-base-gicv3-psci.dtb Binary files differindex 0acbe17e..e175bf02 100644 --- a/fdts/fvp-base-gicv3-psci.dtb +++ b/fdts/fvp-base-gicv3-psci.dtb diff --git a/fdts/fvp-base-gicv3-psci.dts b/fdts/fvp-base-gicv3-psci.dts index 5d54dbf3..57f35161 100644 --- a/fdts/fvp-base-gicv3-psci.dts +++ b/fdts/fvp-base-gicv3-psci.dts @@ -57,6 +57,8 @@ cpu_suspend = <0xc4000001>; cpu_off = <0x84000002>; cpu_on = <0xc4000003>; + sys_poweroff = <0x84000008>; + sys_reset = <0x84000009>; }; cpus { @@ -310,7 +312,7 @@ <0 0 41 &gic 0 0 0 41 4>, <0 0 42 &gic 0 0 0 42 4>; - /include/ "rtsm_ve-motherboard-no_psci.dtsi" + /include/ "rtsm_ve-motherboard.dtsi" }; panels { diff --git a/fdts/fvp-foundation-gicv3-psci.dtb b/fdts/fvp-foundation-gicv3-psci.dtb Binary files differindex 44024369..34bf8db6 100644 --- a/fdts/fvp-foundation-gicv3-psci.dtb +++ b/fdts/fvp-foundation-gicv3-psci.dtb diff --git a/fdts/fvp-foundation-gicv3-psci.dts b/fdts/fvp-foundation-gicv3-psci.dts index 45c699a6..2c84559e 100644 --- a/fdts/fvp-foundation-gicv3-psci.dts +++ b/fdts/fvp-foundation-gicv3-psci.dts @@ -57,6 +57,8 @@ cpu_suspend = <0xc4000001>; cpu_off = <0x84000002>; cpu_on = <0xc4000003>; + sys_poweroff = <0x84000008>; + sys_reset = <0x84000009>; }; cpus { @@ -259,6 +261,6 @@ <0 0 41 &gic 0 0 0 41 4>, <0 0 42 &gic 0 0 0 42 4>; - /include/ "fvp-foundation-motherboard-no_psci.dtsi" + /include/ "fvp-foundation-motherboard.dtsi" }; }; diff --git a/fdts/fvp-foundation-motherboard-no_psci.dtsi b/fdts/fvp-foundation-motherboard-no_psci.dtsi deleted file mode 100644 index fd41c8ae..00000000 --- a/fdts/fvp-foundation-motherboard-no_psci.dtsi +++ /dev/null @@ -1,197 +0,0 @@ -/* - * Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions are met: - * - * Redistributions of source code must retain the above copyright notice, this - * list of conditions and the following disclaimer. - * - * Redistributions in binary form must reproduce the above copyright notice, - * this list of conditions and the following disclaimer in the documentation - * and/or other materials provided with the distribution. - * - * Neither the name of the ARM nor the names of its contributors may be used - * to endorse or promote products derived from this software without specific - * prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" - * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE - * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR - * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF - * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS - * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN - * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - * POSSIBILITY OF SUCH DAMAGE. - */ - - motherboard { - arm,v2m-memory-map = "rs1"; - compatible = "arm,vexpress,v2m-p1", "simple-bus"; - #address-cells = <2>; /* SMB chipselect number and offset */ - #size-cells = <1>; - #interrupt-cells = <1>; - ranges; - - ethernet@2,02000000 { - compatible = "smsc,lan91c111"; - reg = <2 0x02000000 0x10000>; - interrupts = <15>; - }; - - v2m_clk24mhz: clk24mhz { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <24000000>; - clock-output-names = "v2m:clk24mhz"; - }; - - v2m_refclk1mhz: refclk1mhz { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <1000000>; - clock-output-names = "v2m:refclk1mhz"; - }; - - v2m_refclk32khz: refclk32khz { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - clock-output-names = "v2m:refclk32khz"; - }; - - iofpga@3,00000000 { - compatible = "arm,amba-bus", "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 3 0 0x200000>; - - v2m_sysreg: sysreg@010000 { - compatible = "arm,vexpress-sysreg"; - reg = <0x010000 0x1000>; - gpio-controller; - #gpio-cells = <2>; - }; - - v2m_sysctl: sysctl@020000 { - compatible = "arm,sp810", "arm,primecell"; - reg = <0x020000 0x1000>; - clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&v2m_clk24mhz>; - clock-names = "refclk", "timclk", "apb_pclk"; - #clock-cells = <1>; - clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3"; - }; - - v2m_serial0: uart@090000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x090000 0x1000>; - interrupts = <5>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - v2m_serial1: uart@0a0000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x0a0000 0x1000>; - interrupts = <6>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - v2m_serial2: uart@0b0000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x0b0000 0x1000>; - interrupts = <7>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - v2m_serial3: uart@0c0000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x0c0000 0x1000>; - interrupts = <8>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - wdt@0f0000 { - compatible = "arm,sp805", "arm,primecell"; - reg = <0x0f0000 0x1000>; - interrupts = <0>; - clocks = <&v2m_refclk32khz>, <&v2m_clk24mhz>; - clock-names = "wdogclk", "apb_pclk"; - }; - - v2m_timer01: timer@110000 { - compatible = "arm,sp804", "arm,primecell"; - reg = <0x110000 0x1000>; - interrupts = <2>; - clocks = <&v2m_sysctl 0>, <&v2m_sysctl 1>, <&v2m_clk24mhz>; - clock-names = "timclken1", "timclken2", "apb_pclk"; - }; - - v2m_timer23: timer@120000 { - compatible = "arm,sp804", "arm,primecell"; - reg = <0x120000 0x1000>; - interrupts = <3>; - clocks = <&v2m_sysctl 2>, <&v2m_sysctl 3>, <&v2m_clk24mhz>; - clock-names = "timclken1", "timclken2", "apb_pclk"; - }; - - rtc@170000 { - compatible = "arm,pl031", "arm,primecell"; - reg = <0x170000 0x1000>; - interrupts = <4>; - clocks = <&v2m_clk24mhz>; - clock-names = "apb_pclk"; - }; - - virtio_block@0130000 { - compatible = "virtio,mmio"; - reg = <0x130000 0x1000>; - interrupts = <0x2a>; - }; - }; - - v2m_fixed_3v3: fixedregulator@0 { - compatible = "regulator-fixed"; - regulator-name = "3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-always-on; - }; - - - mcc { - compatible = "arm,vexpress,config-bus", "simple-bus"; - arm,vexpress,config-bridge = <&v2m_sysreg>; - - reset@0 { - compatible = "arm,vexpress-reset"; - arm,vexpress-sysreg,func = <5 0>; - }; - - muxfpga@0 { - compatible = "arm,vexpress-muxfpga"; - arm,vexpress-sysreg,func = <7 0>; - }; - - shutdown@0 { - compatible = "arm,vexpress-shutdown"; - arm,vexpress-sysreg,func = <8 0>; - }; - - reboot@0 { - compatible = "arm,vexpress-reboot"; - arm,vexpress-sysreg,func = <9 0>; - }; - - dvimode@0 { - compatible = "arm,vexpress-dvimode"; - arm,vexpress-sysreg,func = <11 0>; - }; - }; - }; diff --git a/fdts/rtsm_ve-motherboard-no_psci.dtsi b/fdts/rtsm_ve-motherboard-no_psci.dtsi deleted file mode 100644 index 7ba575ea..00000000 --- a/fdts/rtsm_ve-motherboard-no_psci.dtsi +++ /dev/null @@ -1,264 +0,0 @@ -/* - * Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions are met: - * - * Redistributions of source code must retain the above copyright notice, this - * list of conditions and the following disclaimer. - * - * Redistributions in binary form must reproduce the above copyright notice, - * this list of conditions and the following disclaimer in the documentation - * and/or other materials provided with the distribution. - * - * Neither the name of ARM nor the names of its contributors may be used - * to endorse or promote products derived from this software without specific - * prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" - * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE - * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR - * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF - * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS - * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN - * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) - * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE - * POSSIBILITY OF SUCH DAMAGE. - */ - - motherboard { - arm,v2m-memory-map = "rs1"; - compatible = "arm,vexpress,v2m-p1", "simple-bus"; - #address-cells = <2>; /* SMB chipselect number and offset */ - #size-cells = <1>; - #interrupt-cells = <1>; - ranges; - - flash@0,00000000 { - compatible = "arm,vexpress-flash", "cfi-flash"; - reg = <0 0x00000000 0x04000000>, - <4 0x00000000 0x04000000>; - bank-width = <4>; - }; - - vram@2,00000000 { - compatible = "arm,vexpress-vram"; - reg = <2 0x00000000 0x00800000>; - }; - - ethernet@2,02000000 { - compatible = "smsc,lan91c111"; - reg = <2 0x02000000 0x10000>; - interrupts = <15>; - }; - - v2m_clk24mhz: clk24mhz { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <24000000>; - clock-output-names = "v2m:clk24mhz"; - }; - - v2m_refclk1mhz: refclk1mhz { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <1000000>; - clock-output-names = "v2m:refclk1mhz"; - }; - - v2m_refclk32khz: refclk32khz { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <32768>; - clock-output-names = "v2m:refclk32khz"; - }; - - iofpga@3,00000000 { - compatible = "arm,amba-bus", "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 3 0 0x200000>; - - v2m_sysreg: sysreg@010000 { - compatible = "arm,vexpress-sysreg"; - reg = <0x010000 0x1000>; - gpio-controller; - #gpio-cells = <2>; - }; - - v2m_sysctl: sysctl@020000 { - compatible = "arm,sp810", "arm,primecell"; - reg = <0x020000 0x1000>; - clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&v2m_clk24mhz>; - clock-names = "refclk", "timclk", "apb_pclk"; - #clock-cells = <1>; - clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3"; - }; - - aaci@040000 { - compatible = "arm,pl041", "arm,primecell"; - reg = <0x040000 0x1000>; - interrupts = <11>; - clocks = <&v2m_clk24mhz>; - clock-names = "apb_pclk"; - }; - - mmci@050000 { - compatible = "arm,pl180", "arm,primecell"; - reg = <0x050000 0x1000>; - interrupts = <9 10>; - cd-gpios = <&v2m_sysreg 0 0>; - wp-gpios = <&v2m_sysreg 1 0>; - max-frequency = <12000000>; - vmmc-supply = <&v2m_fixed_3v3>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "mclk", "apb_pclk"; - }; - - kmi@060000 { - compatible = "arm,pl050", "arm,primecell"; - reg = <0x060000 0x1000>; - interrupts = <12>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "KMIREFCLK", "apb_pclk"; - }; - - kmi@070000 { - compatible = "arm,pl050", "arm,primecell"; - reg = <0x070000 0x1000>; - interrupts = <13>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "KMIREFCLK", "apb_pclk"; - }; - - v2m_serial0: uart@090000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x090000 0x1000>; - interrupts = <5>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - v2m_serial1: uart@0a0000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x0a0000 0x1000>; - interrupts = <6>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - v2m_serial2: uart@0b0000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x0b0000 0x1000>; - interrupts = <7>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - v2m_serial3: uart@0c0000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0x0c0000 0x1000>; - interrupts = <8>; - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>; - clock-names = "uartclk", "apb_pclk"; - }; - - wdt@0f0000 { - compatible = "arm,sp805", "arm,primecell"; - reg = <0x0f0000 0x1000>; - interrupts = <0>; - clocks = <&v2m_refclk32khz>, <&v2m_clk24mhz>; - clock-names = "wdogclk", "apb_pclk"; - }; - - v2m_timer01: timer@110000 { - compatible = "arm,sp804", "arm,primecell"; - reg = <0x110000 0x1000>; - interrupts = <2>; - clocks = <&v2m_sysctl 0>, <&v2m_sysctl 1>, <&v2m_clk24mhz>; - clock-names = "timclken1", "timclken2", "apb_pclk"; - }; - - v2m_timer23: timer@120000 { - compatible = "arm,sp804", "arm,primecell"; - reg = <0x120000 0x1000>; - interrupts = <3>; - clocks = <&v2m_sysctl 2>, <&v2m_sysctl 3>, <&v2m_clk24mhz>; - clock-names = "timclken1", "timclken2", "apb_pclk"; - }; - - rtc@170000 { - compatible = "arm,pl031", "arm,primecell"; - reg = <0x170000 0x1000>; - interrupts = <4>; - clocks = <&v2m_clk24mhz>; - clock-names = "apb_pclk"; - }; - - clcd@1f0000 { - compatible = "arm,pl111", "arm,primecell"; - reg = <0x1f0000 0x1000>; - interrupts = <14>; - clocks = <&v2m_oscclk1>, <&v2m_clk24mhz>; - clock-names = "clcdclk", "apb_pclk"; - mode = "XVGA"; - use_dma = <0>; - framebuffer = <0x18000000 0x00180000>; - }; - - virtio_block@0130000 { - compatible = "virtio,mmio"; - reg = <0x130000 0x1000>; - interrupts = <0x2a>; - }; - }; - - v2m_fixed_3v3: fixedregulator@0 { - compatible = "regulator-fixed"; - regulator-name = "3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-always-on; - }; - - mcc { - compatible = "arm,vexpress,config-bus", "simple-bus"; - arm,vexpress,config-bridge = <&v2m_sysreg>; - - v2m_oscclk1: osc@1 { - /* CLCD clock */ - compatible = "arm,vexpress-osc"; - arm,vexpress-sysreg,func = <1 1>; - freq-range = <23750000 63500000>; - #clock-cells = <0>; - clock-output-names = "v2m:oscclk1"; - }; - - reset@0 { - compatible = "arm,vexpress-reset"; - arm,vexpress-sysreg,func = <5 0>; - }; - - muxfpga@0 { - compatible = "arm,vexpress-muxfpga"; - arm,vexpress-sysreg,func = <7 0>; - }; - - shutdown@0 { - compatible = "arm,vexpress-shutdown"; - arm,vexpress-sysreg,func = <8 0>; - }; - - reboot@0 { - compatible = "arm,vexpress-reboot"; - arm,vexpress-sysreg,func = <9 0>; - }; - - dvimode@0 { - compatible = "arm,vexpress-dvimode"; - arm,vexpress-sysreg,func = <11 0>; - }; - }; - }; diff --git a/plat/rockchip/rk3399/drivers/soc/soc.c b/plat/rockchip/rk3399/drivers/soc/soc.c index 29bf6dda..6af7a2e2 100644 --- a/plat/rockchip/rk3399/drivers/soc/soc.c +++ b/plat/rockchip/rk3399/drivers/soc/soc.c @@ -325,9 +325,16 @@ void plls_resume_finish(void) { int i; - for (i = 0; i < CRU_CLKSEL_COUNT; i++) - mmio_write_32((CRU_BASE + CRU_CLKSEL_CON(i)), - REG_SOC_WMSK | slp_data.cru_clksel_con[i]); + for (i = 0; i < CRU_CLKSEL_COUNT; i++) { + /* CRU_CLKSEL_CON96~107 the high 16-bit isb't write_mask */ + if (i > 95) + mmio_write_32((CRU_BASE + CRU_CLKSEL_CON(i)), + slp_data.cru_clksel_con[i]); + else + mmio_write_32((CRU_BASE + CRU_CLKSEL_CON(i)), + REG_SOC_WMSK | + slp_data.cru_clksel_con[i]); + } for (i = 0; i < PMUCRU_CLKSEL_CONUT; i++) mmio_write_32((PMUCRU_BASE + PMUCRU_CLKSEL_OFFSET + i * REG_SIZE), diff --git a/plat/rockchip/rk3399/drivers/soc/soc.h b/plat/rockchip/rk3399/drivers/soc/soc.h index 906452a3..d99b380e 100644 --- a/plat/rockchip/rk3399/drivers/soc/soc.h +++ b/plat/rockchip/rk3399/drivers/soc/soc.h @@ -65,7 +65,7 @@ #define PLL_CON_COUNT 0x06 #define CRU_CLKSEL_COUNT 0x108 -#define CRU_CLKSEL_CON(n) (0x80 + (n) * 4) +#define CRU_CLKSEL_CON(n) (0x100 + (n) * 4) #define PMUCRU_CLKSEL_CONUT 0x06 #define PMUCRU_CLKSEL_OFFSET 0x080 @@ -1,4 +1,4 @@ -ARM Trusted Firmware - version 1.2 +ARM Trusted Firmware - version 1.3 ================================== ARM Trusted Firmware provides a reference implementation of secure world @@ -17,17 +17,25 @@ 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. +The software is provided under a BSD-3-Clause [license]. Contributions to this +project are accepted under the same license with developer sign-off as +described in the [Contributing Guidelines]. + +This project contains code from other projects as listed below. The original +license text is included in those source files. + +* The stdlib source code is derived from FreeBSD code. + +* The libfdt source code is dual licensed. It is used by this project under + the terms of the BSD-2-Clause license. 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. +world boot and runtime firmware, executing in either the AArch32 or AArch64 +execution state. Users are encouraged to do their own security validation, including penetration testing, on any secure world code derived from ARM Trusted Firmware. @@ -42,7 +50,7 @@ testing, on any secure world code derived from ARM Trusted Firmware. * 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 +* Drivers for both versions 2.0 and 3.0 of the ARM Generic Interrupt Controller specifications (GICv2 and GICv3). The latter also enables GICv3 hardware systems that do not contain legacy GICv2 support. @@ -53,18 +61,26 @@ testing, on any secure world code derived from ARM Trusted Firmware. * SMC (Secure Monitor Call) handling, conforming to the [SMC Calling Convention][SMCCC] 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. +* [PSCI] library support for the Secondary CPU Boot, CPU Hotplug, CPU Idle + and System Shutdown/Reset/Suspend use-cases. + This library is pre-integrated with the provided AArch64 EL3 Runtime + Software, and is also suitable for integration into other EL3 Runtime + Software. + +* A minimal AArch32 Secure Payload to demonstrate [PSCI] library integration + on platforms with AArch32 EL3 Runtime Software. * 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. + and interrupt routing. + When using the provided AArch64 EL3 Runtime Software, 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. +* A Test Secure-EL1 Payload and Dispatcher to demonstrate AArch64 Secure + Monitor functionality and Secure-EL1 interaction with PSCI. -* SPDs for the [OP-TEE Secure OS] and [NVidia Trusted Little Kernel] +* AArch64 SPDs for the [OP-TEE Secure OS] and [NVidia Trusted Little Kernel] [NVidia TLK]. * A Trusted Board Boot implementation, conforming to all mandatory TBBR @@ -72,11 +88,12 @@ testing, on any secure world code derived from ARM Trusted Firmware. 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. + The TBBR implementation is currently only supported in the AArch64 build. * 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. + firmware and only require the AArch64 EL3 Runtime Software provided by this + project. 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] @@ -84,36 +101,46 @@ 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 AArch64 build of this release has been tested on variants r0, r1 and r2 +of the [Juno ARM Development Platform] [Juno] with [Linaro Release 16.06]. + +The AArch64 build of this release has been tested on the following ARM +[FVP]s (64-bit host machine only): -The Trusted Firmware has also been tested on the 64-bit Linux versions of the -following ARM [FVP]s: +* `Foundation_Platform` (Version 10.1, Build 10.1.32) +* `FVP_Base_AEMv8A-AEMv8A` (Version 7.7, Build 0.8.7701) +* `FVP_Base_Cortex-A57x4-A53x4` (Version 7.7, Build 0.8.7701) +* `FVP_Base_Cortex-A57x1-A53x1` (Version 7.7, Build 0.8.7701) +* `FVP_Base_Cortex-A57x2-A53x4` (Version 7.7, Build 0.8.7701) -* `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 AArch32 build of this release has been tested on the following ARM +[FVP]s (64-bit host machine only): + +* `FVP_Base_AEMv8A-AEMv8A` (Version 7.7, Build 0.8.7701) +* `FVP_Base_Cortex-A32x4` (Version 10.1, Build 10.1.32) 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: +* MediaTek MT6795 and MT8173 SoCs * NVidia T210 and T132 SoCs -* MediaTek MT8173 SoC +* QEMU emulator +* RockChip RK3368 and RK3399 SoCs +* Xilinx Zynq UltraScale + MPSoC ### Still to Come -* Complete implementation of the [PSCI] v1.0 specification. - -* Support for new CPUs and System IP. +* AArch32 TBBR support and ongoing TBBR alignment. * More platform support. -* Optimization and quality improvements. +* Ongoing support for new architectural features, CPUs and System IP. + +* Ongoing [PSCI] alignment and feature support. + +* Ongoing security hardening, 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]. @@ -147,7 +174,7 @@ ARM licensees may contact ARM directly via their partner managers. - - - - - - - - - - - - - - - - - - - - - - - - - - -_Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._ +_Copyright (c) 2013-2016, ARM Limited and Contributors. All rights reserved._ [License]: ./license.md "BSD license for ARM Trusted Firmware" @@ -167,4 +194,4 @@ _Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved._ [GitHub issue tracker]: https://github.com/ARM-software/tf-issues/issues [OP-TEE Secure OS]: https://github.com/OP-TEE/optee_os [NVidia TLK]: http://nv-tegra.nvidia.com/gitweb/?p=3rdparty/ote_partner/tlk.git;a=summary -[Linaro Release Notes]: https://community.arm.com/docs/DOC-10952#jive_content_id_Linaro_Release_1510 +[Linaro Release 16.06]: https://community.arm.com/docs/DOC-10952#jive_content_id_Linaro_Release_1606 |