- 21 Sep, 2016 1 commit
-
-
Yatharth Kochar authored
This patch adds changes in ARM platform code to use new version of image loading. Following are the major changes: -Refactor the signatures for bl31_early_platform_setup() and arm_bl31_early_platform_setup() function to use `void *` instead of `bl31_params_t *`. -Introduce `plat_arm_bl2_handle_scp_bl2()` to handle loading of SCP_BL2 image from BL2. -Remove usage of reserve_mem() function from `arm_bl1_early_platform_setup()` -Extract BL32 & BL33 entrypoint info, from the link list passed by BL2, in `arm_bl31_early_platform_setup()` -Provides weak definitions for following platform functions: plat_get_bl_image_load_info plat_get_next_bl_params plat_flush_next_bl_params bl2_plat_handle_post_image_load -Instantiates a descriptor array for ARM platforms describing image and entrypoint information for `SCP_BL2`, `BL31`, `BL32` and `BL33` images. All the above changes are conditionally compiled using the `LOAD_IMAGE_V2` flag. Change-Id: I5e88b9785a3df1a2b2bbbb37d85b8e353ca61049
-
- 25 Jul, 2016 1 commit
-
-
Antonio Nino Diaz authored
Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to `ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines related to the translation tables but to the image size as well. The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and `PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h. This way, ARM platforms no longer have to set their own values if `ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values otherwise. The common sizes have been set to the highest values used for any of the current build configurations. This is needed because in some build configurations some images are running out of space. This way there is a common set of values known to work for all of them and it can be optimized for each particular platform if needed. The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been increased. This is needed because when memory optimisations are disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` are higher. If in this situation the code is compiled in debug mode and with "-O0", the code won't fit. Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e
-
- 22 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
`board_arm_def.h` contains multiple definitions of `PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for memory usage depending upon the chosen build configuration. To ease maintenance of these constants, this patch replaces their multiple definitions with a single set of definitions that will work on all ARM platforms. Platforms can override the defaults with optimal values by enabling the `ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in the Juno ADP port. Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate future ARM platforms. Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
-
- 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
-
- 15 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
-
- 11 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
This patch moves the definition of some macros used only on ARM platforms from common headers to platform specific headers. It also forces all ARM standard platforms to have distinct definitions (even if they are usually the same). 1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been moved from `css_def.h` to `platform_def.h`. 2. `MHU_BASE` used in CSS platforms is moved from common css_def.h to platform specific header `platform_def.h` on Juno and renamed as `PLAT_ARM_MHU_BASE`. 3. To cater for different sizes of BL images, new macros like `PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All ARM platforms need to define them for each image. Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
-
- 09 Dec, 2015 1 commit
-
-
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
-
- 30 Oct, 2015 1 commit
-
-
Soby Mathew authored
This patch implements the necessary topology changes for supporting system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform specific. In addition, the `arm_power_domain_tree_desc[]` and `arm_pm_idle_states[]` are modified to support the system power domain at level 2. With this patch, even though the power management operations involving the system power domain will not return any error, the platform layer will silently ignore any operations to the power domain. The actual power management support for the system power domain will be added later. Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
-
- 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
-
- 28 Apr, 2015 2 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
Major update to the Juno 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 move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
-
- 27 Apr, 2015 1 commit
-
-
Dan Handley authored
The required platform constant PLATFORM_CACHE_LINE_SIZE is unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the same information. CACHE_WRITEBACK_GRANULE is preferred since this is an architecturally defined term and allows comparison with the corresponding hardware register value. Replace all usage of PLATFORM_CACHE_LINE_SIZE with CACHE_WRITEBACK_GRANULE. Also, add a runtime assert in BL1 to check that the provided CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0. Change-Id: If87286be78068424217b9f3689be358356500dcd
-
- 12 Feb, 2015 2 commits
-
-
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
-
Soby Mathew authored
This patch defines MAX_MMAP_REGIONS separately for each BL stage as per its requirements. This minimizes the size of the mmap[] array. Fixes ARM-Software/tf-issues#201 Change-Id: I19b15e1a91a8365b2ecf24e2cd71937cb73916b2
-
- 28 Jan, 2015 3 commits
-
-
Juan Castillo authored
This patch adds support to authenticate the Trusted Key certificate and the BL3-x certificates and images at BL2. Change-Id: I69a8c13a14c8da8b75f93097d3a4576aed71c5dd
-
Juan Castillo authored
This patch adds support to authenticate the BL2 content certificate and image using the authentication module in BL1. The FIP driver has been extended to include the BL2 certificate UUID. FVP and Juno ports include the BL2 certificate FIP file definition. Change-Id: I32680e9bd123c8db4a4193c14448c9b32b0e9325
-
Juan Castillo authored
This patch implements an authentication module based on the PolarSSL library (v1.3.9) to verify the Chain of Trust when Trusted Boot is enabled. PolarSSL sources must be fetched separately. The POLARSSL_DIR build option may be used to indicate the path to the PolarSSL main directory (this directory must contain the 'include' and 'library' subdirectories). To be able to build PolarSSL sources as a part of the Trusted Firmware build process, the DISABLE_PEDANTIC flag in polarssl.mk will tell the build system to remove the -pedantic option from the CFLAGS. Inclusion of PolarSSL increases the memory requirements of the BL1 and BL2 images. The following are the changes made to the FVP and Juno platforms to cater for this when TRUSTED_BOARD_BOOT is defined: Changes on FVP: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - BL2 memory region has been increased to 112 KB Changes on Juno: - BL1 and BL2 stacks have been increased to 4 KB - BL1(rw) section has been increased to 32 KB. - Trusted ROM region in Flash has been increased to 128 KB. - BL2 memory region has been increased to 116 KB Change-Id: Ie87d80d43408eb6239c4acd0ec5ab2120e4e9e80
-
- 22 Jan, 2015 1 commit
-
-
Soby Mathew authored
This patch moves the bakery locks out of coherent memory to normal memory. This implies that the lock information needs to be placed on a separate cache line for each cpu. Hence the bakery_lock_info_t structure is allocated in the per-cpu data so as to minimize memory wastage. A similar platform per-cpu data is introduced for the platform locks. As a result of the above changes, the bakery lock api is completely changed. Earlier, a reference to the lock structure was passed to the lock implementation. Now a unique-id (essentially an index into the per-cpu data array) and an offset into the per-cpu data for bakery_info_t needs to be passed to the lock implementation. Change-Id: I1e76216277448713c6c98b4c2de4fb54198b39e0
-
- 12 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch allows the BL3-1 NOBITS section to overlap the BL1 R/W section since the former will always be used after the latter. Similarly, the BL3-2 NOBITS section can overlay the BL2 image when BL3-2 is loaded in Trusted SRAM. Due to the current size of the images, there is no actual overlap. Nevertheless, this reorganization may help to optimise the Trusted SRAM usage when the images size grows. Note that because BL3-1 NOBITS section is allowed to overlap the BL1 R/W section, BL1 global variables will remain valid only until execution reaches the BL3-1 entry point during a cold boot. Documentation updated accordingly. Fixes ARM-software/tf-issues#254 Change-Id: Id538f4d1c7f1f7858108280fd7b97e138572b879
-
- 14 Oct, 2014 1 commit
-
-
Juan Castillo authored
This patch configures the TrustZone Controller in Juno to split the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure regions: - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are used by the SCP for DDR retraining - Non-Secure DDR-DRAM: remaining DRAM starting at base address Build option PLAT_TSP_LOCATION selects the location of the secure payload (BL3-2): - 'tsram' : Trusted SRAM (default option) - 'dram' : Secure region in the DDR-DRAM (set by the TrustZone controller) The MMU memory map has been updated to give BL2 permission to load BL3-2 into the DDR-DRAM secure region. Fixes ARM-software/tf-issues#233 Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
-
- 21 Aug, 2014 2 commits
-
-
Sandrine Bailleux authored
This patch implements the TSP on Juno. It executes from on-chip Trusted SRAM. Also, the other bootloader images (i.e. BL1 R/W, BL2 and BL3-1) have been moved around. The reason is, although there was enough space overall to store the TSP in SRAM, there was no contiguous free chunk of SRAM big enough to hold it. This patch keeps the overall memory layout (i.e. keeping BL1 R/W at the bottom, BL2 at the top and BL3-1 in between) but moves the base addresses of all the bootloader images in such a way that: - memory fragmentation is reduced enough to fit BL3-2 in; - new base addresses are suitable for release builds as well as debug ones; - each image has a few extra kilobytes for future growth. BL3-1 and BL3-2 are the images which received the biggest allocations since they will most probably grow the most. This patch also adds instruction synchronization barriers around the code which handles the timer interrupt in the TSP. This ensures that the interrupt is not acknowledged after or EOIed before it is deactivated at the peripheral. Change-Id: I1c5b51858700027ee283ac85d18e06863a27c72e
-
Sandrine Bailleux authored
This patch adds the initial port of the ARM Trusted Firmware on the Juno development platform. This port does not support a BL3-2 image or any PSCI APIs apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno platform errata (Defect id 831273). Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
-
- 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
-
- 14 Aug, 2014 2 commits
-
-
Dan Handley authored
* Create cci_init() function in CCI-400 driver to allow platform to provide arguments needed by the driver (i.e. base address and cluster indices for the ACE slave interfaces). * Rename cci_(en|dis)able_coherency to cci_(en|dis)able_cluster_coherency to make it clear that the driver only enables/disables the coherency of CPU clusters and not other devices connected to the CCI-400. * Update FVP port to use new cci_init() function and remove unnecessary CCI defintions from platform_def.h. Also rename fvp_cci_setup() to fvp_cci_enable() to more clearly differentiate between CCI initialization and enabling. THIS CHANGE REQUIRES PLATFORM PORTS THAT USE THE CCI-400 DRIVER TO BE UPDATED Fixes ARM-software/tf-issues#168 Change-Id: I1946a51409b91217b92285b6375082619f607fec
-
Juan Castillo authored
This patch groups the current contents of the Trusted DRAM region at address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in a single shared memory area that may be allocated to Trusted SRAM (default) or Trusted DRAM at build time by setting the FVP_SHARED_DATA_LOCATION make variable. The size of this shared memory is 4096 bytes. The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM' is not currently supported due to restrictions in the maximum number of mmu tables that can be created. Documentation has been updated to reflect these changes. Fixes ARM-software/tf-issues#100 Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
-
- 12 Aug, 2014 2 commits
-
-
Dan Handley authored
Fix the following issues with the console log output: * Make sure the welcome string is the first thing in the log output (during normal boot). * Prefix each message with the BL image name so it's clear which BL the output is coming from. * Ensure all output is wrapped in one of the log output macros so it can be easily compiled out if necessary. Change some of the INFO() messages to VERBOSE(), especially in the TSP. * Create some extra NOTICE() and INFO() messages during cold boot. * Remove all usage of \r in log output. Fixes ARM-software/tf-issues#231 Change-Id: Ib24f7acb36ce64bbba549f204b9cde2dbb46c8a3
-
Juan Castillo authored
Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM BLn_BASE and BLn_LIMIT definitions have been updated and are based on these new memory regions. The available memory for each bootloader in the linker script is defined by BLn_BASE and BLn_LIMIT, instead of the complete memory region. TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of the platform porting. FVP common definitions are defined in fvp_def.h while platform_def.h contains exclusively (with a few exceptions) the definitions that are mandatory in the porting guide. Therefore, platform_def.h now includes fvp_def.h instead of the other way around. Porting guide has been updated to reflect these changes. Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
-
- 11 Aug, 2014 1 commit
-
-
Soby Mathew authored
This patch separates the stack size for each BL stage and reduces it after stack usage analysis was done. Fixes ARM-software/tf-issues#200 Change-Id: I8edc6de2551b0a6788761d121937692b2149bb29
-
- 01 Aug, 2014 1 commit
-
-
Juan Castillo authored
The purpose of platform_is_primary_cpu() is to determine after reset (BL1 or BL3-1 with reset handler) if the current CPU must follow the cold boot path (primary CPU), or wait in a safe state (secondary CPU) until the primary CPU has finished the system initialization. This patch removes redundant calls to platform_is_primary_cpu() in subsequent bootloader entrypoints since the reset handler already guarantees that code is executed exclusively on the primary CPU. Additionally, this patch removes the weak definition of platform_is_primary_cpu(), so the implementation of this function becomes mandatory. Removing the weak symbol avoids other bootloaders accidentally picking up an invalid definition in case the porting layer makes the real function available only to BL1. The define PRIMARY_CPU is no longer mandatory in the platform porting because platform_is_primary_cpu() hides the implementation details (for instance, there may be platforms that report the primary CPU in a system register). The primary CPU definition in FVP has been moved to fvp_def.h. The porting guide has been updated accordingly. Fixes ARM-software/tf-issues#219 Change-Id: If675a1de8e8d25122b7fef147cb238d939f90b5e
-
- 28 Jul, 2014 1 commit
-
-
Achin Gupta authored
This patch removes the allocation of memory for coherent stacks, associated accessor function and some dead code which called the accessor function. It also updates the porting guide to remove the concept and the motivation behind using stacks allocated in coherent memory. Fixes ARM-software/tf-issues#198 Change-Id: I00ff9a04f693a03df3627ba39727e3497263fc38
-
- 10 Jul, 2014 1 commit
-
-
Sandrine Bailleux authored
This patch re-organizes the memory layout on FVP as to give the BL3-2 image as much memory as possible. Considering these two facts: - not all images need to live in memory at the same time. Once in BL3-1, the memory used by BL1 and BL2 can be reclaimed. - when BL2 loads the BL3-1 and BL3-2 images, it only considers the PROGBITS sections of those 2 images. The memory occupied by the NOBITS sections will be touched only at execution of the BL3-x images; Then it is possible to choose the different base addresses such that the NOBITS sections of BL3-1 and BL3-2 overlay BL1 and BL2. On FVP we choose to put: - BL1 and BL3-1 at the top of the Trusted RAM, with BL3-1 NOBITS sections overlaying BL1; - BL3-2 at the bottom of the Trusted RAM, with its NOBITS sections overlaying BL2; This is illustrated by the following diagram: 0x0404_0000 ------------ ------------------ | BL1 | <= | BL3-1 NOBITS | ------------ <= ------------------ | | <= | BL3-1 PROGBITS | ------------ ------------------ | BL2 | <= | BL3-2 NOBITS | ------------ <= ------------------ | | <= | BL3-2 PROGBITS | 0x0400_0000 ------------ ------------------ New platform-specific constants have been introduced to easily check at link time that BL3-1 and BL3-2 PROGBITS sections don't overwrite BL1 and BL2. These are optional and the platform code is free to define them or not. If not defined, the linker won't attempt to check image overlaying. Fixes ARM-software/tf-issues#117 Change-Id: I5981d1c3d66ee70eaac8bd052630c9ac6dd8b042
-
- 23 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
The array of affinity nodes is currently allocated for 32 entries with the PSCI_NUM_AFFS value defined in psci.h. This is not enough for large systems, and will substantially over allocate the array for small systems. This patch introduces an optional platform definition PLATFORM_NUM_AFFS to platform_def.h. If defined this value is used for PSCI_NUM_AFFS, otherwise a value of two times the number of CPU cores is used. The FVP port defines PLATFORM_NUM_AFFS to be 10 which saves nearly 1.5KB of memory. Fixes ARM-software/tf-issues#192 Change-Id: I68e30ac950de88cfbd02982ba882a18fb69c1445
-
- 20 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
This memory is not used by the FVP port and requires an additional 4KB translation table. This patch removes the entry from the memory map and reduces the number of allocated translation tables. Fixes ARM-software/tf-issues#196 Change-Id: I5b959e4fe92f5f892ed127c40dbe6c85eed3ed72
-
- 23 May, 2014 1 commit
-
-
Dan Handley authored
Previously, platform.h contained many declarations and definitions used for different purposes. This file has been split so that: * Platform definitions used by common code that must be defined by the platform are now in platform_def.h. The exact include path is exported through $PLAT_INCLUDES in the platform makefile. * Platform definitions specific to the FVP platform are now in /plat/fvp/fvp_def.h. * Platform API declarations specific to the FVP platform are now in /plat/fvp/fvp_private.h. * The remaining platform API declarations that must be ported by each platform are still in platform.h but this file has been moved to /include/plat/common since this can be shared by all platforms. Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a
-