- 11 Oct, 2017 1 commit
-
-
Soby Mathew authored
Some recent enhancements to EL3 runtime firmware like support for save and restoring GICv3 register context during system_suspend necessitates additional data memory for the firmware. This patch introduces support for creating a TZC secured DDR carveout for use by ARM reference platforms. A new linker section `el3_tzc_dram` is created using platform supplied linker script and data marked with the attribute `arm_el3_tzc_dram` will be placed in this section. The FVP makefile now defines the `PLAT_EXTRA_LD_SCRIPT` variable to allow inclusion of the platform linker script by the top level BL31 linker script. Change-Id: I0e7f4a75a6ac51419c667875ff2677043df1585d Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 05 Oct, 2017 1 commit
-
-
Soby Mathew authored
During system suspend, the GICv3 Distributor and Redistributor context can be lost due to power gating of the system power domain. This means that the GICv3 context needs to be saved prior to system suspend and restored on wakeup. Currently the consensus is that the Firmware should be in charge of this. See tf-issues#464 for more details. This patch introduces helper APIs in the GICv3 driver to save and restore the Distributor and Redistributor contexts. The GICv3 ITS context is not considered in this patch because the specification says that the details of ITS power management is implementation-defined. These APIs are expected to be appropriately invoked by the platform layer during system suspend. Fixes ARM-software/tf-issues#464 Change-Id: Iebb9c6770ab8c4d522546f161fa402d2fe02ec00 Signed-off-by: Soby Mathew <soby.mathew@arm.com> Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 06 Sep, 2017 1 commit
-
-
Soby Mathew authored
This patch does the required changes to enable CSS platforms to build and use the SDS framework. Since SDS is always coupled with SCMI protocol, the preexisting SCMI build flag is now renamed to `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on CSS platforms. Also some of the workarounds applied for SCMI are now removed with SDS in place. Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 02 Aug, 2017 1 commit
-
-
Jeenu Viswambharan authored
Revision C of the Base FVP has the same memory map as earlier revisions, but has the following differences: - Implements CCI550 instead of CCI400, - Has a single instantiation of SMMUv3, - CPU MPIDs are shifted left by one level, and has MT bit set in them. The correct interconnect to program is chosen at run time based on the FVP revision. Therefore, this patch implements FVP functions for interconnect programming, rather than depending on ARM generic ones. The macros used have been renamed to reflect this change. Additionally, this patch initializes SMMUv3 as part of FVP early platform setup. New ARM config flags are introduced for feature queries at run time. Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 01 Aug, 2017 1 commit
-
-
Jeenu Viswambharan authored
ARM CPUs with multi-threading implementation has more than one Processing Element in a single physical CPU. Such an implementation will reflect the following changes in the MPIDR register: - The MT bit set; - Affinity levels pertaining to cluster and CPUs occupy one level higher than in a single-threaded implementation, and the lowest affinity level pertains to hardware threads. MPIDR affinity level fields essentially appear shifted to left than otherwise. The FVP port henceforth assumes that both properties above to be concomitant on a given FVP platform. To accommodate for varied MPIDR formats at run time, this patch re-implements the FVP platform-specific functions that translates MPIDR values to a linear indices, along with required validation. The same treatment is applied for GICv3 MPIDR hashing function as well. An FVP-specific build option FVP_MAX_PE_PER_CPU is introduced which specifies the maximum number of threads implemented per CPU. For backwards compatibility, its value defaults to 1. Change-Id: I729b00d3e121d16ce9a03de4f9db36dfac580e3f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 01 Jun, 2017 2 commits
-
-
Jeenu Viswambharan authored
ARM GIC-600 IP complies with ARM GICv3 architecture, but among others, implements a power control register in the Redistributor frame. This register must be programmed to mark the frame as powered on, before accessing other registers in the frame. Rest of initialization sequence remains the same. The driver provides APIs for Redistributor power management, and overrides those in the generic GICv3 driver. The driver data is shared between generic GICv3 driver and that of GIC-600. For FVP platform, the GIC-600 driver is chosen when FVP_USE_GIC_DRIVER is set to FVP_GIC600. Also update user guide. Change-Id: I321b2360728d69f6d4b0a747b2cfcc3fe5a20d67 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
David Wang authored
Both Cortex-A75 and Cortex-A55 CPUs use the ARM DynamIQ Shared Unit (DSU). The power-down and power-up sequences are therefore mostly managed in hardware, and required software operations are considerably simpler. Change-Id: I68b30e6e1ebe7c041d5e67f39c59f08575fc7ecc Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 15 May, 2017 1 commit
-
-
dp-arm authored
This patch adds `TRUSTED_BOARD_BOOT` support for AArch32 mode. To build this patch the "mbedtls/include/mbedtls/bignum.h" needs to be modified to remove `#define MBEDTLS_HAVE_UDBL` when `MBEDTLS_HAVE_INT32` is defined. This is a workaround for "https://github.com/ARMmbed/mbedtls/issues/708 " NOTE: TBBR support on Juno AArch32 is not currently supported. Change-Id: I86d80e30b9139adc4d9663f112801ece42deafcf Signed-off-by: dp-arm <dimitris.papastamos@arm.com> Co-Authored-By: Yatharth Kochar <yatharth.kochar@arm.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 31 Mar, 2017 1 commit
-
-
Douglas Raillard authored
Introduce new build option ENABLE_STACK_PROTECTOR. It enables compilation of all BL images with one of the GCC -fstack-protector-* options. A new platform function plat_get_stack_protector_canary() is introduced. It returns a value that is used to initialize the canary for stack corruption detection. Returning a random value will prevent an attacker from predicting the value and greatly increase the effectiveness of the protection. A message is printed at the ERROR level when a stack corruption is detected. To be effective, the global data must be stored at an address lower than the base of the stacks. Failure to do so would allow an attacker to overwrite the canary as part of an attack which would void the protection. FVP implementation of plat_get_stack_protector_canary is weak as there is no real source of entropy on the FVP. It therefore relies on a timer's value, which could be predictable. Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 21 Sep, 2016 3 commits
-
-
Yatharth Kochar authored
This patch adds ARM Cortex-A32 MPCore Processor support in the CPU specific operations framework. It also includes this support for the Base FVP port. Change-Id: If3697b88678df737c29f79cf3fa1ea2cb6fa565d
-
Yatharth Kochar authored
This patch adds ARM platform changes in BL2 for AArch32 state. It instantiates a descriptor array for ARM platforms describing image and entrypoint information for `SCP_BL2`, `BL32` and `BL33`. It also enables building of BL2 for ARCH=aarch32. Change-Id: I60dc7a284311eceba401fc789311c50ac746c51e
-
Yatharth Kochar authored
This patch adds ARM platform changes in BL1 for AArch32 state. It also enables building of BL1 for ARCH=aarch32. Change-Id: I079be81a93d027f37b0f7d8bb474b1252bb4cf48
-
- 10 Aug, 2016 1 commit
-
-
Soby Mathew authored
This patch adds AArch32 support for FVP and implements common platform APIs like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32. Only Multi Processor(MP) implementations of these functions are considered in this patch. The ARM Standard platform layer helpers are implemented for AArch32 and the common makefiles are modified to cater for both AArch64 and AArch32 builds. Compatibility with the deprecated platform API is not supported for AArch32. Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
-
- 03 Jun, 2016 1 commit
-
-
Antonio Nino Diaz authored
Replaced placeholder implementation of plat_set_nv_ctr for FVP platforms by a working one. On FVP, the mapping of region DEVICE2 has been changed from RO to RW to prevent exceptions when writing to the NV counter, which is contained in this region. Change-Id: I56a49631432ce13905572378cbdf106f69c82f57
-
- 01 Jun, 2016 1 commit
-
-
Yatharth Kochar authored
This patch adds ARM Cortex-A73 MPCore Processor support in the CPU specific operations framework. It also includes this support for the Base FVP port. Change-Id: I0e26b594f2ec1d28eb815db9810c682e3885716d
-
- 25 May, 2016 1 commit
-
-
Soby Mathew authored
This patch adds support to select CCN driver for FVP during build. A new build option `FVP_INTERCONNECT_DRIVER` is added to allow selection between the CCI and CCN driver. Currently only the CCN-502 variant is supported on FVP. The common ARM CCN platform helper file now verifies the cluster count declared by platform is equal to the number of root node masters exported by the ARM Standard platform. Change-Id: I71d7b4785f8925ed499c153b2e9b9925fcefd57a
-
- 20 May, 2016 1 commit
-
-
Antonio Nino Diaz authored
Added a build flag to select the generic delay timer on FVP instead of the SP804 timer. By default, the generic one will be selected. The user guide has been updated. Change-Id: Ica34425c6d4ed95a187b529c612f6d3b26b78bc6
-
- 28 Apr, 2016 1 commit
-
-
Soby Mathew authored
This patch changes the default driver for FVP platform from the deprecated GICv3 legacy to the GICv3 only driver. This means that the default build of Trusted Firmware will not be able boot Linux kernel with GICv2 FDT blob. The user guide is also updated to reflect this change of default GIC driver for FVP. Change-Id: Id6fc8c1ac16ad633dabb3cd189b690415a047764
-
- 13 Apr, 2016 1 commit
-
-
Soby Mathew authored
This patch modifies the upstream platform port makefiles to use the new xlat_tables library files. This patch also makes mmap region setup common between AArch64 and AArch32 for FVP platform port. The file `fvp_common.c` is moved from the `plat/arm/board/fvp/aarch64` folder to the parent folder as it is not specific to AArch64. Change-Id: Id2e9aac45e46227b6f83cccfd1e915404018ea0b
-
- 31 Mar, 2016 1 commit
-
-
Soby Mathew authored
This patch migrates ARM Standard platforms to the refactored TZC driver. Change-Id: I2a2f60b645f73e14d8f416740c4551cec87cb1fb
-
- 19 Feb, 2016 1 commit
-
-
Soby Mathew authored
The common topology description helper funtions and macros for ARM Standard platforms assumed a dual cluster system. This is not flexible enough to scale to multi cluster platforms. This patch does the following changes for more flexibility in defining topology: 1. The `plat_get_power_domain_tree_desc()` definition is moved from `arm_topology.c` to platform specific files, that is `fvp_topology.c` and `juno_topology.c`. Similarly the common definition of the porting macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform specific `platform_def.h` header. 2. The ARM common layer porting macros which were dual cluster specific are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced which must be defined by each ARM standard platform. 3. A new mandatory ARM common layer porting API `plat_arm_get_cluster_core_count()` is introduced to enable the common implementation of `arm_check_mpidr()` to validate MPIDR. 4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been introduced which allows the user to specify the cluster count to be used to build the topology tree within Trusted Firmare. This enables Trusted Firmware to be built for multi cluster FVP models. Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
-
- 16 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
ARM Trusted Firmware supports 2 different interconnect peripheral drivers: CCI and CCN. ARM platforms are implemented using either of the interconnect peripherals. This patch adds a layer of abstraction to help ARM platform ports to choose the right interconnect driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been implemented to initialise an interconnect and for entering/exiting a cluster from coherency. These functions are prefixed as "plat_arm_interconnect_". Weak definitions of these functions have been provided for each type of driver. 2.`plat_print_interconnect_regs` macro used for printing CCI registers is moved from a common arm_macros.S to cci_macros.S. 3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure is renamed to `ARM_CONFIG_HAS_INTERCONNECT`. Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
-
- 15 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
Prior to this patch, it was assumed that on all ARM platforms the bare minimal security setup required is to program TrustZone protection. This would always be done by programming the TZC-400 which was assumed to be present in all ARM platforms. The weak definition of platform_arm_security_setup() in plat/arm/common/arm_security.c reflected these assumptions. In reality, each ARM platform either decides at runtime whether TrustZone protection needs to be programmed (e.g. FVPs) or performs some security setup in addition to programming TrustZone protection (e.g. NIC setup on Juno). As a result, the weak definition of plat_arm_security_setup() is always overridden. When a platform needs to program TrustZone protection and implements the TZC-400 peripheral, it uses the arm_tzc_setup() function to do so. It is also possible to program TrustZone protection through other peripherals that include a TrustZone controller e.g. DMC-500. The programmer's interface is slightly different across these various peripherals. In order to satisfy the above requirements, this patch makes the following changes to the way security setup is done on ARM platforms. 1. arm_security.c retains the definition of arm_tzc_setup() and has been renamed to arm_tzc400.c. This is to reflect the reliance on the TZC-400 peripheral to perform TrustZone programming. The new file is not automatically included in all platform ports through arm_common.mk. Each platform must include it explicitly in a platform specific makefile if needed. This approach enables introduction of similar library code to program TrustZone protection using a different peripheral. This code would be used by the subset of ARM platforms that implement this peripheral. 2. Due to #1 above, existing platforms which implements the TZC-400 have been updated to include the necessary files for both BL2, BL2U and BL31 images. Change-Id: I513c58f7a19fff2e9e9c3b95721592095bcb2735
-
- 13 Jan, 2016 1 commit
-
-
Sandrine Bailleux authored
This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP. This allows the same TF binaries to run on a Cortex-A72 based FVP without recompiling them. Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47
-
- 12 Jan, 2016 1 commit
-
-
Sandrine Bailleux authored
This patch adds support for ARM Cortex-A35 processor in the CPU specific framework, as described in the Cortex-A35 TRM (r0p0). Change-Id: Ief930a0bdf6cd82f6cb1c3b106f591a71c883464
-
- 09 Dec, 2015 2 commits
-
-
Yatharth Kochar authored
This patch adds support for Firmware update in BL2U for ARM platforms such that TZC initialization is performed on all ARM platforms and (optionally) transfer of SCP_BL2U image on ARM CSS platforms. BL2U specific functions are added to handle early_platform and plat_arch setup. The MMU is configured to map in the BL2U code/data area and other required memory. Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
-
Achin Gupta authored
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
-
- 02 Dec, 2015 1 commit
-
-
Juan Castillo authored
This patch adds watchdog support on ARM platforms (FVP and Juno). A secure instance of SP805 is used as Trusted Watchdog. It is entirely managed in BL1, being enabled in the early platform setup hook and disabled in the exit hook. By default, the watchdog is enabled in every build (even when TBB is disabled). A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG` has been introduced to allow the user to disable the watchdog at build time. This feature may be used for testing or debugging purposes. Specific error handlers for Juno and FVP are also provided in this patch. These handlers will be called after an image load or authentication error. On FVP, the Table of Contents (ToC) in the FIP is erased. On Juno, the corresponding error code is stored in the V2M Non-Volatile flags register. In both cases, the CPU spins until a watchdog reset is generated after 256 seconds (as specified in the TBBR document). Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
-
- 13 Aug, 2015 1 commit
-
-
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
-
- 25 Jun, 2015 1 commit
-
-
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
-
- 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>
-
- 28 Apr, 2015 2 commits
-
-
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
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
-
- 16 Mar, 2015 1 commit
-
-
Vikram Kanigiri authored
This patch updates the FVP and Juno platform ports to use the common driver for ARM Cache Coherent Interconnects. Change-Id: Ib142f456b9b673600592616a2ec99e9b230d6542
-
- 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
-
- 26 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch allows the secure payload (BL3-2) to be loaded in the DRAM region secured by the TrustZone controller (top 16 MB of DRAM1). The location of BL3-2 can be selected at build time by setting the build flag FVP_TSP_RAM_LOCATION to one of the following options: - 'tsram' : Trusted SRAM (this is the default option) - 'tdram' : Trusted DRAM - 'dram' : Secure region in DRAM1 (top 16MB configured by the TrustZone controller) The number of MMU tables in BL3-2 depends on its location in memory: 3 in case it is loaded in DRAM, 2 otherwise. Documentation updated accordingly. Fixes ARM-software/tf-issues#212 Change-Id: I371eef3a4159f06a0c9e3c6c1f4c905b2f93803a
-
- 22 Oct, 2014 1 commit
-
-
Juan Castillo authored
This patch deprecates the build option to relocate the shared data into Trusted DRAM in FVP. After this change, shared data is always located at the base of Trusted SRAM. This reduces the complexity of the memory map and the number of combinations in the build options. Fixes ARM-software/tf-issues#257 Change-Id: I68426472567b9d8c6d22d8884cb816f6b61bcbd3
-
- 20 Aug, 2014 1 commit
-
-
Soby Mathew authored
This patch introduces a framework which will allow CPUs to perform implementation defined actions after a CPU reset, during a CPU or cluster power down, and when a crash occurs. CPU specific reset handlers have been implemented in this patch. Other handlers will be implemented in subsequent patches. Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/. Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
-
- 14 Aug, 2014 1 commit
-
-
Dan Handley authored
Move the remaining IO storage source file (io_storage.c) from the lib to the drivers directory. This requires that platform ports explicitly add this file to the list of source files. Also move the IO header files to a new sub-directory, include/io. Change-Id: I862b1252a796b3bcac0d93e50b11e7fb2ded93d6
-