- 30 Oct, 2015 1 commit
-
-
Soby Mathew authored
This patch fixes a compilation issue for platforms that are aligned to ARM Standard platforms and include the `plat_arm.h` header in their platform port. The compilation would fail for such a platform because `xlat_tables.h` which has the definition for `mmap_region_t` is not included in `plat_arm.h`. This patch fixes this by including `xlat_tables.h` in `plat_arm.h` header. Fixes ARM-Software/tf-issues#318 Change-Id: I75f990cfb4078b3996fc353c8cd37c9de61d555e
-
- 28 Oct, 2015 1 commit
-
-
Juan Castillo authored
This patch adds an optional API to the platform port: void plat_error_handler(int err) __dead2; The platform error handler is called when there is a specific error condition after which Trusted Firmware cannot continue. While panic() simply prints the crash report (if enabled) and spins, the platform error handler can be used to hand control over to the platform port so it can perform specific bookeeping or post-error actions (for example, reset the system). This function must not return. The parameter indicates the type of error using standard codes from errno.h. Possible errors reported by the generic code are: -EAUTH : a certificate or image could not be authenticated (when Trusted Board Boot is enabled) -ENOENT : the requested image or certificate could not be found or an IO error was detected -ENOMEM : resources exhausted. Trusted Firmware does not use dynamic memory, so this error is usually an indication of an incorrect array size A default weak implementation of this function has been provided. It simply implements an infinite loop. Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3
-
- 20 Oct, 2015 1 commit
-
-
Soby Mathew authored
This patch does the following reorganization to psci power management (PM) handler setup for ARM standard platform ports : 1. The mailbox programming required during `plat_setup_psci_ops()` is identical for all ARM platforms. Hence the implementation of this API is now moved to the common `arm_pm.c` file. Each ARM platform now must define the PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same as ARM_SHARED_RAM_BASE. 2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be exported via `plat_arm_psci_pm_ops`. This allows the common implementation of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`. In the case of CSS platforms, a default weak implementation of the same is provided in `css_pm.c` which can be overridden by each CSS platform. 3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now made library functions and a new header file `css_pm.h` is added to export these generic PM handlers. This allows the platform to reuse the adequate CSS PM handlers and redefine others which need to be customized when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`. Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
-
- 11 Sep, 2015 3 commits
-
-
Vikram Kanigiri authored
This patch updates ARM platform ports to use the new unified bakery locks API. The caller does not have to use a different bakery lock API depending upon the value of the USE_COHERENT_MEM build option. NOTE: THIS PATCH CAN BE USED AS A REFERENCE TO UPDATE OTHER PLATFORM PORTS. Change-Id: I1b26afc7c9a9808a6040eb22f603d30192251da7
-
Vikram Kanigiri authored
On Juno and FVP platforms, the Non-Secure System timer corresponds to frame 1. However, this is a platform-specific decision and it shouldn't be hard-coded. Hence, this patch introduces PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms to specify the correct non-secure timer frame. Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba
-
Vikram Kanigiri authored
This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to support different TrustZone Controller base addresses across ARM platforms. Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd
-
- 01 Sep, 2015 1 commit
-
-
Vikram Kanigiri authored
ARM TF configures all interrupts as non-secure except those which are present in irq_sec_array. This patch updates the irq_sec_array with the missing secure interrupts for ARM platforms. It also updates the documentation to be inline with the latest implementation. Fixes ARM-software/tf-issues#312 Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
-
- 13 Aug, 2015 11 commits
-
-
Soby Mathew authored
This patch implements the platform power managment handler to verify non secure entrypoint for ARM platforms. The handler ensures that the entry point specified by the normal world during CPU_SUSPEND, CPU_ON or SYSTEM_SUSPEND PSCI API is a valid address within the non secure DRAM. Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
-
Sandrine Bailleux authored
Since there is a unique warm reset entry point, the FVP and Juno port can use a single mailbox instead of maintaining one per core. The mailbox gets programmed only once when plat_setup_psci_ops() is invoked during PSCI initialization. This means mailbox is not zeroed out during wakeup. Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
-
Soby Mathew authored
This patch adds support to the Juno and FVP ports for composite power states with both the original and extended state-id power-state formats. Both the platform ports use the recommended state-id encoding as specified in Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag ARM_RECOM_STATE_ID_ENC is used to include this support. By default, to maintain backwards compatibility, the original power state parameter format is used and the state-id field is expected to be zero. Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
-
Soby Mathew authored
This patch migrates ARM reference platforms, Juno and FVP, to the new platform API mandated by the new PSCI power domain topology and composite power state frameworks. The platform specific makefiles now exports the build flag ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer. Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
-
Soby Mathew authored
This patch defines deprecated platform APIs to enable Trusted Firmware components like Secure Payload and their dispatchers(SPD) to continue to build and run when platform compatibility is disabled. This decouples the migration of platform ports to the new platform API from SPD and enables them to be migrated independently. The deprecated platform APIs defined in this patch are : platform_get_core_pos(), platform_get_stack() and platform_set_stack(). The patch also deprecates MPIDR based context management helpers like cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context(). A mechanism to deprecate APIs and identify callers of these APIs during build is introduced, which is controlled by the build flag WARN_DEPRECATED. If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be flagged either as a link error for assembly files or compile time warning for C files during build. Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613
-
Soby Mathew authored
This commit does the switch to the new PSCI framework implementation replacing the existing files in PSCI folder with the ones in PSCI1.0 folder. The corresponding makefiles are modified as required for the new implementation. The platform.h header file is also is switched to the new one as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults to 1 to enable compatibility layer which let the existing platform ports to continue to build and run with minimal changes. The default weak implementation of platform_get_core_pos() is now removed from platform_helpers.S and is provided by the compatibility layer. Note: The Secure Payloads and their dispatchers still use the old platform and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build flag will remain enabled in subsequent patch. The compatibility for SPDs using the older APIs on platforms migrated to the new APIs will be added in the following patch. Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719
-
Soby Mathew authored
The new PSCI topology framework and PSCI extended State framework introduces a breaking change in the platform port APIs. To ease the migration of the platform ports to the new porting interface, a compatibility layer is introduced which essentially defines the new platform API in terms of the old API. The old PSCI helpers to retrieve the power-state, its associated fields and the highest coordinated physical OFF affinity level of a core are also implemented for compatibility. This allows the existing platform ports to work with the new PSCI framework without significant rework. This layer will be enabled by default once the switch to the new PSCI framework is done and is controlled by the build flag ENABLE_PLAT_COMPAT. Change-Id: I4b17cac3a4f3375910a36dba6b03d8f1700d07e3
-
Sandrine Bailleux authored
There used to be 2 warm reset entry points: - the "on finisher", for when the core has been turned on using a PSCI CPU_ON call; - the "suspend finisher", entered upon resumption from a previous PSCI CPU_SUSPEND call. The appropriate warm reset entry point used to be programmed into the mailboxes by the power management hooks. However, it is not required to provide this information to the PSCI entry point code, as it can figure it out by itself. By querying affinity info state, a core is able to determine on which execution path it is. If the state is ON_PENDING then it means it's been turned on else it is resuming from suspend. This patch unifies the 2 warm reset entry points into a single one: psci_entrypoint(). The patch also implements the necessary logic to distinguish between the 2 types of warm resets in the power up finisher. The plat_setup_psci_ops() API now takes the secure entry point as an additional parameter to enable the platforms to configure their mailbox. The platform hooks `pwr_domain_on` and `pwr_domain_suspend` no longer take secure entry point as a parameter. Change-Id: I7d1c93787b54213aefdbc046b8cd66a555dfbfd9
-
Soby Mathew authored
The state-id field in the power-state parameter of a CPU_SUSPEND call can be used to describe composite power states specific to a platform. The current PSCI implementation does not interpret the state-id field. It relies on the target power level and the state type fields in the power-state parameter to perform state coordination and power management operations. The framework introduced in this patch allows the PSCI implementation to intepret generic global states like RUN, RETENTION or OFF from the State-ID to make global state coordination decisions and reduce the complexity of platform ports. It adds support to involve the platform in state coordination which facilitates the use of composite power states and improves the support for entering standby states at multiple power domains. The patch also includes support for extended state-id format for the power state parameter as specified by PSCIv1.0. The PSCI implementation now defines a generic representation of the power-state parameter. It depends on the platform port to convert the power-state parameter (possibly encoding a composite power state) passed in a CPU_SUSPEND call to this representation via the `validate_power_state()` plat_psci_ops handler. It is an array where each index corresponds to a power level. Each entry contains the local power state the power domain at that power level could enter. The meaning of the local power state values is platform defined, and may vary between levels in a single platform. The PSCI implementation constrains the values only so that it can classify the state as RUN, RETENTION or OFF as required by the specification: * zero means RUN * all OFF state values at all levels must be higher than all RETENTION state values at all levels * the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values to the framework The platform also must define the macros PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power domains have been requested to enter a retention or power down state. The PSCI implementation does not interpret the local power states defined by the platform. The only constraint is that the PLAT_MAX_RET_STATE < PLAT_MAX_OFF_STATE. For a power domain tree, the generic implementation maintains an array of local power states. These are the states requested for each power domain by all the cores contained within the domain. During a request to place multiple power domains in a low power state, the platform is passed an array of requested power-states for each power domain through the plat_get_target_pwr_state() API. It coordinates amongst these states to determine a target local power state for the power domain. A default weak implementation of this API is provided in the platform layer which returns the minimum of the requested power-states back to the PSCI state coordination. Finally, the plat_psci_ops power management handlers are passed the target local power states for each affected power domain using the generic representation described above. The platform executes operations specific to these target states. The platform power management handler for placing a power domain in a standby state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for placing a core power domain into a standby or retention state should now be used to only place the core power domain in a standby or retention state. The extended state-id power state format can be enabled by setting the build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default. Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c
-
Soby Mathew authored
This patch removes the assumption in the current PSCI implementation that MPIDR based affinity levels map directly to levels in a power domain tree. This enables PSCI generic code to support complex power domain topologies as envisaged by PSCIv1.0 specification. The platform interface for querying the power domain topology has been changed such that: 1. The generic PSCI code does not generate MPIDRs and use them to query the platform about the number of power domains at a particular power level. The platform now provides a description of the power domain tree on the SoC through a data structure. The existing platform APIs to provide the same information have been removed. 2. The linear indices returned by plat_core_pos_by_mpidr() and plat_my_core_pos() are used to retrieve core power domain nodes from the power domain tree. Power domains above the core level are accessed using a 'parent' field in the tree node descriptors. The platform describes the power domain tree in an array of 'unsigned char's. The first entry in the array specifies the number of power domains at the highest power level implemented in the system. Each susbsequent entry corresponds to a power domain and contains the number of power domains that are its direct children. This array is exported to the generic PSCI implementation via the new `plat_get_power_domain_tree_desc()` platform API. The PSCI generic code uses this array to populate its internal power domain tree using the Breadth First Search like algorithm. The tree is split into two arrays: 1. An array that contains all the core power domain nodes 2. An array that contains all the other power domain nodes A separate array for core nodes allows certain core specific optimisations to be implemented e.g. remove the bakery lock, re-use per-cpu data framework for storing some information. Entries in the core power domain array are allocated such that the array index of the domain is equal to the linear index returned by plat_core_pos_by_mpidr() and plat_my_core_pos() for the MPIDR corresponding to that domain. This relationship is key to be able to use an MPIDR to find the corresponding core power domain node, traverse to higher power domain nodes and index into arrays that contain core specific information. An introductory document has been added to briefly describe the new interface. Change-Id: I4b444719e8e927ba391cae48a23558308447da13
-
Soby Mathew authored
This patch introduces new platform APIs and context management helper APIs to support the new topology framework based on linear core position. This framework will be introduced in the follwoing patch and it removes the assumption that the MPIDR based affinity levels map directly to levels in a power domain tree. The new platforms APIs and context management helpers based on core position are as described below: * plat_my_core_pos() and plat_core_pos_by_mpidr() These 2 new mandatory platform APIs are meant to replace the existing 'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the linear index of the calling core and 'plat_core_pos_by_mpidr()' returns the linear index of a core specified by its MPIDR. The latter API will also validate the MPIDR passed as an argument and will return an error code (-1) if an invalid MPIDR is passed as the argument. This enables the caller to safely convert an MPIDR of another core to its linear index without querying the PSCI topology tree e.g. during a call to PSCI CPU_ON. Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always platform specific, it is no longer possible to maintain a default implementation of this API. Also it might not be possible for a platform port to verify an MPIDR before the C runtime has been setup or the topology has been initialized. This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to topology setup. As a result, the generic Trusted Firmware code does not call this API before the topology setup has been done. The 'plat_my_core_pos' API should be able to run without a C runtime. Since this API needs to return a core position which is equal to the one returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR, this too cannot have default implementation and is a mandatory API for platform ports. These APIs will be implemented by the ARM reference platform ports later in the patch stack. * plat_get_my_stack() and plat_set_my_stack() These APIs are the stack management APIs which set/return stack addresses appropriate for the calling core. These replace the 'platform_get_stack()' and 'platform_set_stack()' APIs. A default weak MP version and a global UP version of these APIs are provided for the platforms. * Context management helpers based on linear core position A set of new context management(CM) helpers viz cm_get_context_by_index(), cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index() are defined which are meant to replace the old helpers which took MPIDR as argument. The old CM helpers are implemented based on the new helpers to allow for code consolidation and will be deprecated once the switch to the new framework is done. Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
-
- 05 Aug, 2015 3 commits
-
-
Soby Mathew authored
As per Section 4.2.2. in the PSCI specification, the term "affinity" is used in the context of describing the hierarchical arrangement of cores. This often, but not always, maps directly to the processor power domain topology of the system. The current PSCI implementation assumes that this is always the case i.e. MPIDR based levels of affinity always map to levels in a power domain topology tree. This patch is the first in a series of patches which remove this assumption. It removes all occurences of the terms "affinity instances and levels" when used to describe the power domain topology. Only the terminology is changed in this patch. Subsequent patches will implement functional changes to remove the above mentioned assumption. Change-Id: Iee162f051b228828310610c5a320ff9d31009b4e
-
Soby Mathew authored
This patch creates a copy of the existing PSCI files and related psci.h and platform.h header files in a new `PSCI1.0` directory. The changes for the new PSCI power domain topology and extended state-ID frameworks will be added incrementally to these files. This incremental approach will aid in review and in understanding the changes better. Once all the changes have been introduced, these files will replace the existing PSCI files. Change-Id: Ibb8a52e265daa4204e34829ed050bddd7e3316ff
-
Juan Castillo authored
If Trusted Firmware is built with optimizations disabled (-O0), the linker throws the following error: undefined reference to 'xxx' Where 'xxx' is a raw inline function defined in a header file. The reason is that, with optimizations disabled, GCC may decide to skip the inlining. If that is the case, an external definition to the compilation unit must be provided. Because no external definition is present, the linker throws the error. This patch fixes the problem by declaring the following inline functions static, so the internal definition is used: inline void soc_css_security_setup(void) inline const arm_config_t *get_arm_config(void) Change-Id: Id650d6be1b1396bdb48af1ac8a4c7900d212e95f
-
- 09 Jul, 2015 1 commit
-
-
Juan Castillo authored
This patch changes the type of the base address parameter in the ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The uintptr_t type allows coverage of the whole memory space and to perform arithmetic operations on the addresses. ARM platform code has also been updated to use uintptr_t as GIC base address in the configuration. Fixes ARM-software/tf-issues#214 Change-Id: I1b87daedadcc8b63e8f113477979675e07d788f1
-
- 25 Jun, 2015 5 commits
-
-
Juan Castillo authored
The authentication framework deprecates plat_match_rotpk() in favour of plat_get_rotpk_info(). This patch removes plat_match_rotpk() from the platform port. Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
-
Juan Castillo authored
This patch modifies the Trusted Board Boot implementation to use the new authentication framework, making use of the authentication module, the cryto module and the image parser module to authenticate the images in the Chain of Trust. A new function 'load_auth_image()' has been implemented. When TBB is enabled, this function will call the authentication module to authenticate parent images following the CoT up to the root of trust to finally load and authenticate the requested image. The platform is responsible for picking up the right makefiles to build the corresponding cryptographic and image parser libraries. ARM platforms use the mbedTLS based libraries. The platform may also specify what key algorithm should be used to sign the certificates. This is done by declaring the 'KEY_ALG' variable in the platform makefile. FVP and Juno use ECDSA keys. On ARM platforms, BL2 and BL1-RW regions have been increased 4KB each to accommodate the ECDSA code. REMOVED BUILD OPTIONS: * 'AUTH_MOD' Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
-
Juan Castillo authored
This patch adds a CoT based on the Trusted Board Boot Requirements document*. The CoT consists of an array of authentication image descriptors indexed by the image identifiers. A new header file with TBBR image identifiers has been added. Platforms that use the TBBR (i.e. ARM platforms) may reuse these definitions as part of their platform porting. PLATFORM PORT - IMPORTANT: Default image IDs have been removed from the platform common definitions file (common_def.h). As a consequence, platforms that used those common definitons must now either include the IDs provided by the TBBR header file or define their own IDs. *The NVCounter authentication method has not been implemented yet. Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
-
Juan Castillo authored
This patch extends the platform port by adding an API that returns either the Root of Trust public key (ROTPK) or its hash. This is usually stored in ROM or eFUSE memory. The ROTPK returned must be encoded in DER format according to the following ASN.1 structure: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } In case the platform returns a hash of the key: DigestInfo ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, keyDigest OCTET STRING } An implementation for ARM development platforms is provided in this patch. When TBB is enabled, the ROTPK hash location must be specified using the build option 'ARM_ROTPK_LOCATION'. Available options are: - 'regs' : return the ROTPK hash stored in the Trusted root-key storage registers. - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and BL2 binaries. This hash has been obtained from the development RSA public key located in 'plat/arm/board/common/rotpk'. On FVP, the number of MMU tables has been increased to map and access the ROTPK registers. A new file 'board_common.mk' has been added to improve code sharing in the ARM develelopment platforms. Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
-
Juan Castillo authored
The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
-
- 18 Jun, 2015 1 commit
-
-
Ryan Harkin authored
Add SP804 delay timer support to the FVP BSP. This commit simply provides the 3 constants needed by the SP804 delay timer driver and calls sp804_timer_init() in bl2_platform_setup(). The BSP does not currently use the delay timer functions. Note that the FVP SP804 is a normal world accessible peripheral and should not be used by the secure world after transition to the normal world. Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39 Co-authored-by: Dan Handley <dan.handley@arm.com>
-
- 09 Jun, 2015 2 commits
-
-
Sandrine Bailleux authored
For CSS based platforms, the constants MHU_SECURE_BASE and MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes. As such, they were misnamed because the mailboxes are completely unrelated to the MHU hardware. This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines. The address of the Trusted Mailboxes is now relative to the base of the Trusted SRAM. This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE, which is the address of the first memory region used for communication between AP and SCP. This is used by the BOM and SCPI protocols. Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f
-
Sandrine Bailleux authored
Add a comment explaining what the SCP boot configuration information is on CSS based platforms like Juno. Also express its address relatively to the base of the Trusted SRAM rather than hard-coding it. Change-Id: I82cf708a284c8b8212933074ea8c37bdf48b403b
-
- 27 May, 2015 1 commit
-
-
Soby Mathew authored
This patch fixes the incorrect bit width used to extract the primary cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in platform_is_primary_cpu(). Change-Id: I14abb361685f31164ecce0755fc1a145903b27aa
-
- 28 Apr, 2015 2 commits
-
-
Dan Handley authored
Major update to the FVP platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
-
Dan Handley authored
This major change pulls out the common functionality from the FVP and Juno platform ports into the following categories: * (include/)plat/common. Common platform porting functionality that typically may be used by all platforms. * (include/)plat/arm/common. Common platform porting functionality that may be used by all ARM standard platforms. This includes all ARM development platforms like FVP and Juno but may also include non-ARM-owned platforms. * (include/)plat/arm/board/common. Common platform porting functionality for ARM development platforms at the board (off SoC) level. * (include/)plat/arm/css/common. Common platform porting functionality at the ARM Compute SubSystem (CSS) level. Juno is an example of a CSS-based platform. * (include/)plat/arm/soc/common. Common platform porting functionality at the ARM SoC level, which is not already defined at the ARM CSS level. No guarantees are made about the backward compatibility of functionality provided in (include/)plat/arm. Also remove any unnecessary variation between the ARM development platform ports, including: * Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the Juno implementation, which copies the information from BL2 memory instead of expecting it to persist in shared memory. * Unify the TZC configuration. There is no need to add a region for SCP in Juno; it's enough to simply not allow any access to this reserved region. Also set region 0 to provide no access by default instead of assuming this is the case. * Unify the number of memory map regions required for ARM development platforms, although the actual ranges mapped for each platform may be different. For the FVP port, this reduces the mapped peripheral address space. These latter changes will only be observed when the platform ports are migrated to use the new common platform code in subsequent patches. Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
-
- 12 Feb, 2015 1 commit
-
-
Soby Mathew authored
This patch removes the plat_get_max_afflvl() platform API and instead replaces it with a platform macro PLATFORM_MAX_AFFLVL. This is done because the maximum affinity level for a platform is a static value and it is more efficient for it to be defined as a platform macro. NOTE: PLATFORM PORTS NEED TO BE UPDATED ON MERGE OF THIS COMMIT Fixes ARM-Software/tf-issues#265 Change-Id: I31d89b30c2ccda30d28271154d869060d50df7bf
-
- 28 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch adds the function plat_match_rotpk() to the platform porting layer to provide a Root Of Trust Public key (ROTPK) verification mechanism. This function is called during the Trusted Board Boot process and receives a supposed valid copy of the ROTPK as a parameter, usually obtained from an external source (for instance, a certificate). It returns 0 (success) if that key matches the actual ROTPK stored in the system or any other value otherwise. The mechanism to access the actual ROTPK stored in the system is platform specific and should be implemented as part of this function. The format of the ROTPK is also platform specific (to save memory, some platforms might store a hash of the key instead of the whole key). TRUSTED_BOARD_BOOT build option has been added to allow the user to enable the Trusted Board Boot features. The implementation of the plat_match_rotpk() funtion is mandatory when Trusted Board Boot is enabled. For development purposes, FVP and Juno ports provide a dummy function that returns always success (valid key). A safe trusted boot implementation should provide a proper matching function. Documentation updated accordingly. Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3
-
- 27 Aug, 2014 1 commit
-
-
Sandrine Bailleux authored
This patch gathers miscellaneous minor fixes to the documentation, and comments in the source code. Change-Id: I631e3dda5abafa2d90f464edaee069a1e58b751b Co-Authored-By: Soby Mathew <soby.mathew@arm.com> Co-Authored-By: Dan Handley <dan.handley@arm.com>
-
- 20 Aug, 2014 1 commit
-
-
Soby Mathew authored
This patch adds CPU core and cluster power down sequences to the CPU specific operations framework introduced in a earlier patch. Cortex-A53, Cortex-A57 and generic AEM sequences have been added. The latter is suitable for the Foundation and Base AEM FVPs. A pointer to each CPU's operations structure is saved in the per-cpu data so that it can be easily accessed during power down seqeunces. An optional platform API has been introduced to allow a platform to disable the Accelerator Coherency Port (ACP) during a cluster power down sequence. The weak definition of this function (plat_disable_acp()) does not take any action. It should be overriden with a strong definition if the ACP is present on a platform. Change-Id: I8d09bd40d2f528a28d2d3f19b77101178778685d
-
- 19 Aug, 2014 1 commit
-
-
Dan Handley authored
* Move TSP platform porting functions to new file: include/bl32/tsp/platform_tsp.h. * Create new TSP_IRQ_SEC_PHY_TIMER definition for use by the generic TSP interrupt handling code, instead of depending on the FVP specific definition IRQ_SEC_PHY_TIMER. * Rename TSP platform porting functions from bl32_* to tsp_*, and definitions from BL32_* to TSP_*. * Update generic TSP code to use new platform porting function names and definitions. * Update FVP port accordingly and move all TSP source files to: plat/fvp/tsp/. * Update porting guide with above changes. Note: THIS CHANGE REQUIRES ALL PLATFORM PORTS OF THE TSP TO BE UPDATED Fixes ARM-software/tf-issues#167 Change-Id: Ic0ff8caf72aebb378d378193d2f017599fc6b78f
-
- 28 Jul, 2014 1 commit
-
-
Soby Mathew authored
This patch introduces platform APIs to initialise and print a character on a designated crash console. For the FVP platform, PL011_UART0 is the designated crash console. The platform porting guide is also updated to document the new APIs. Change-Id: I5e97d8762082e0c88c8c9bbb479353eac8f11a66
-
- 19 Jul, 2014 1 commit
-
-
Achin Gupta authored
This patch adds a 'flags' parameter to each exception level specific function responsible for enabling the MMU. At present only a single flag which indicates whether the data cache should also be enabled is implemented. Subsequent patches will use this flag when enabling the MMU in the warm boot paths. Change-Id: I0eafae1e678c9ecc604e680851093f1680e9cefa
-