- 25 Jun, 2015 2 commits
-
-
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>
-
- 04 Jun, 2015 1 commit
-
-
Sandrine Bailleux authored
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its use in ARM development platforms. If a different reset handling behavior is required between the first and subsequent invocations of the reset handling code, this should be detected at runtime. On Juno, the platform reset handler is now always compiled in. This means it is now executed twice on the cold boot path, first in BL1 then in BL3-1, and it has the same behavior in both cases. It is also executed twice on the warm boot path, first in BL1 then in the PSCI entrypoint code. Also update the documentation to reflect this change. NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER. Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
-
- 03 Jun, 2015 1 commit
-
-
Soby Mathew authored
This patch fixes the incorrect bit width used to extract the wakeup reason from PSYSR in platform_get_entrypoint() function. This defect did not have any observed regression. Change-Id: I42652dbffc99f5bf50cc86a5878f28d730720d9a
-
- 01 Jun, 2015 1 commit
-
-
Sandrine Bailleux authored
On ARM standard platforms, snoop and DVM requests used to be enabled for the primary CPU's cluster only in the first EL3 bootloader. In other words, if the platform reset into BL1 then CCI coherency would be enabled by BL1 only, and not by BL3-1 again. However, this doesn't cater for platforms that use BL3-1 along with a non-TF ROM bootloader that doesn't enable snoop and DVM requests. In this case, CCI coherency is never enabled. This patch modifies the function bl31_early_platform_setup() on ARM standard platforms so that it always enables snoop and DVM requests regardless of whether earlier bootloader stages have already done it. There is no harm in executing this code twice. ARM Trusted Firmware Design document updated accordingly. Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c
-
- 19 May, 2015 1 commit
-
-
Dan Handley authored
Fix the return type of the FVP `plat_arm_topology_setup` function to be `void` instead of `int` to match the declaration in `plat_arm.h`. This does not result in any change in behavior. Change-Id: I62edfa7652b83bd26cffb7d167153959b38e37e7
-
- 28 Apr, 2015 3 commits
-
-
Dan Handley authored
Move the Juno port from plat/juno to plat/arm/board/juno. Also rename some of the files so they are consistently prefixed with juno_. Update the platform makefiles accordingly. Change-Id: I0af6cb52a5fee7ef209107a1188b76a3c33a2a9f
-
Dan Handley authored
Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename some of the files so they are consistently prefixed with fvp_. Update the platform makefiles accordingly. Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
-
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
-