- 15 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
This reverts commit 2f18aa1f . It is causing some tests to fail. Until the cause is found and fixed, it is needed to remove this commit from master. Change-Id: Ic5ff7a841903a15613e00379e87cbbd8a0e85152 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 11 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
The old API is deprecated and will eventually be removed. Arm platforms now use the multi console driver for boot and runtime consoles. However, the crash console uses the direct console API because it doesn't need any memory access to work. This makes it more robust during crashes. The AArch32 port of the Trusted Firmware doesn't support this new API yet, so it is only enabled in AArch64 builds. Because of this, the common code must maintain compatibility with both systems. SP_MIN doesn't have to be updated because it's only used in AArch32 builds. The TSP is only used in AArch64, so it only needs to support the new API without keeping support for the old one. Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this causes the UARTs to reset (except for the one used by the TSP). This means that they must be unregistered when suspending and re-registered when resuming. This wasn't a problem with the old driver because it just restarted the UART, and there were no problems associated with registering and unregistering consoles. The size of BL31 has been increased in builds with SPM. Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 08 Mar, 2018 1 commit
-
-
Soby Mathew authored
Previously, Juno used to depend on the SSC_GPRETN register to inform about the reset syndrome. This method was removed when SCP migrated to the SDS framework. But even the SDS framework doesn't report the reset syndrome correctly and hence Juno failed to enter Firmware update mode if BL2 authentication failed. In addition to that, the error code populated in V2M_SYS_NVFLAGS register does not seem to be retained any more on Juno across resets. This could be down to the motherboard firmware not doing the necessary to preserve the value. Hence this patch modifies the Juno platform to use the same mechanism to trigger firmware update as FVP which is to corrupt the FIP TOC on authentication failure. The implementation in `fvp_err.c` is made common for ARM platforms and is moved to the new `arm_err.c` file in plat/arm/common folder. The BL1 and BL2 mmap table entries for Juno are modified to allow write to the Flash memory address. Change-Id: Ica7d49a3e8a46a90efd4cf340f19fda3b549e945 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 28 Feb, 2018 1 commit
-
-
Roberto Vargas authored
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined Fixed for: make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all Change-Id: I7c2ad3f5c015411c202605851240d5347e4cc8c7 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 26 Feb, 2018 1 commit
-
-
Soby Mathew authored
This patch modifies the bl1_platform_setup() API to load and authenticate TB_FW_CONFIG in BL1. The load address of the same is passed on to BL2 in `arg0` of entrypoint info. The fvp_io_storage.c and arm_io_storage.c also adds entries corresponding to TB_FW_CONFIG. A helper function `arm_load_tb_fw_config()` is added to load and authenticate TB_FW_CONFIG if present. Change-Id: Ie7bce667b3fad2b1a083bbcbc0a773f9f04254b1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 14 Jul, 2017 1 commit
-
-
Isla Mitchell authored
This fix modifies the order of #includes in ARM standard platforms to meet the ARM TF coding standard. Change-Id: Ide19aad6233babda4eea2d17d49e523645fed1b2 Signed-off-by: Isla Mitchell <isla.mitchell@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>
-
- 20 Apr, 2017 1 commit
-
-
Yatharth Kochar authored
Following steps are required to boot JUNO in AArch32 state: 1> BL1, in AArch64 state, loads BL2. 2> BL2, in AArch64 state, initializes DDR. Loads SP_MIN & BL33 (AArch32 executable)images. Calls RUN_IMAGE SMC to go back to BL1. 3> BL1 writes AArch32 executable opcodes, to load and branch at the entrypoint address of SP_MIN, at HI-VECTOR address and then request for warm reset in AArch32 state using RMR_EL3. This patch makes following changes to facilitate above steps: * Added assembly function to carry out step 3 above. * Added region in TZC that enables Secure access to the HI-VECTOR(0xFFFF0000) address space. * AArch32 image descriptor is used, in BL2, to load SP_MIN and BL33 AArch32 executable images. A new flag `JUNO_AARCH32_EL3_RUNTIME` is introduced that controls above changes. By default this flag is disabled. NOTE: BL1 and BL2 are not supported in AArch32 state for JUNO. Change-Id: I091d56a0e6d36663e6d9d2bb53c92c672195d1ec Signed-off-by: Yatharth Kochar <yatharth.kochar@arm.com> Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 19 Apr, 2017 1 commit
-
-
Antonio Nino Diaz authored
ARM platforms have migrated to the translation tables library v2. However, for testing purposes, it can be useful to temporarily switch back to the old version. This patch introduces the option `ARM_XLAT_TABLES_LIB_V1`, that switches to v1 of the library when is set to 1. By default, it is 0, so that ARM platforms use the new version unless specifically stated. Updated User Guide. Change-Id: I53d3c8dd97706f6af9c6fca0364a88ef341efd31 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 08 Mar, 2017 1 commit
-
-
Antonio Nino Diaz authored
Modify ARM common makefile to use version 2 of the translation tables library and include the new header in C files. Simplify header dependencies related to this library to simplify the change. The following table contains information about the size increase in bytes for BL1 after applying this patch. The code has been compiled for different configurations of FVP in AArch64 mode with compiler GCC 4.9.3 20150413. The sizes have been calculated with the output of `nm` by adding the size of all regions and comparing the total size before and after the change. They are sumarized in the table below: text bss data total Release +660 -20 +88 +728 Debug +740 -20 +242 +962 Debug (LOG_LEVEL=50) +1120 -20 +317 +1417 Change-Id: I539e307f158ab71e3a8b771640001fc1bf431b29 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 18 Jan, 2017 2 commits
-
-
Masahiro Yamada authored
We have lots of duplicated defines (and comment blocks too). Move them to include/plat/common/common_def.h. While we are here, suffix the end address with _END instead of _LIMIT. The _END is a better fit to indicate the linker-derived real end address. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The usage of _LIMIT seems odd here, so rename as follows: BL_CODE_LIMIT --> BL_CODE_END BL_RO_DATA_LIMIT --> BL_RO_DATA_END BL1_CODE_LIMIT --> BL1_CODE_END BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END Basically, we want to use _LIMIT and _END properly as follows: *_SIZE + *_MAX_SIZE = *_LIMIT *_SIZE + *_SIZE = *_END The _LIMIT is generally defined by platform_def.h to indicate the platform-dependent memory constraint. So, its typical usage is ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.") in a linker script. On the other hand, _END is used to indicate the end address of the compiled image, i.e. we do not know it until the image is linked. Here, all of these macros belong to the latter, so should be suffixed with _END. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 21 Sep, 2016 2 commits
-
-
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
-
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
-
- 08 Jul, 2016 3 commits
-
-
Sandrine Bailleux authored
The arm_setup_page_tables() function used to expect a single set of addresses defining the extents of the whole read-only section, code and read-only data mixed up, which was mapped as executable. This patch changes this behaviour. arm_setup_page_tables() now expects 2 separate sets of addresses: - the extents of the code section; - the extents of the read-only data section. The code is mapped as executable, whereas the data is mapped as execute-never. New #defines have been introduced to identify the extents of the code and the read-only data section. Given that all BL images except BL1 share the same memory layout and linker script structure, these #defines are common across these images. The slight memory layout differences in BL1 have been handled by providing values specific to BL1. Note that this patch also affects the Xilinx platform port, which uses the arm_setup_page_tables() function. It has been updated accordingly, such that the memory mappings on this platform are unchanged. This is achieved by passing null values as the extents of the read-only data section so that it is ignored. As a result, the whole read-only section is still mapped as executable. Fixes ARM-software/tf-issues#85 Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
-
Sandrine Bailleux authored
At the moment, on ARM platforms, BL1 maps everything from BL1_RO_BASE to BL1_RO_LIMIT. BL1_RO_LIMIT, as defined in the porting guide, is the maximum address in Trusted ROM that BL1's actual content _can_ occupy. The actual portion of ROM occupied by BL1 can be less than that, which means that BL1 might map more Trusted ROM than it actually needs to. This patch changes BL1's memory mappings on ARM platforms to restrict the region of Trusted ROM it maps. It uses the symbols exported by the linker to figure out the actual extents of BL1's ROM footprint. This change increases the number of page tables used on FVP by 1. On FVP, we used to map the whole Trusted ROM. As it is 64MB large, we used to map it as blocks of 2MB using level-2 translation table entries. We now need a finer-grained mapping, which requires an additional level-3 translation table. On ARM CSS platforms, the number of translation tables is unchanged. The BL1 image resides in flash at address 0x0BEC0000. This address is not aligned on a 2MB-boundary so a level-3 translation table was already required to map this memory. Change-Id: I317a93fd99c40e70d0f13cc3d7a570f05c6c61eb
-
Sandrine Bailleux authored
This patch introduces the arm_setup_page_tables() function to set up page tables on ARM platforms. It replaces the arm_configure_mmu_elx() functions and does the same thing except that it doesn't enable the MMU at the end. The idea is to reduce the amount of per-EL code that is generated by the C preprocessor by splitting the memory regions definitions and page tables creation (which is generic) from the MMU enablement (which is the only per-EL configuration). As a consequence, the call to the enable_mmu_elx() function has been moved up into the plat_arch_setup() hook. Any other ARM standard platforms that use the functions `arm_configure_mmu_elx()` must be updated. Change-Id: I6f12a20ce4e5187b3849a8574aac841a136de83d
-
- 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
-
- 09 Dec, 2015 1 commit
-
-
Yatharth Kochar authored
As of now BL1 loads and execute BL2 based on hard coded information provided in BL1. But due to addition of support for upcoming Firmware Update feature, BL1 now require more flexible approach to load and run different images using information provided by the platform. This patch adds new mechanism to load and execute images based on platform provided image id's. BL1 now queries the platform to fetch the image id of the next image to be loaded and executed. In order to achieve this, a new struct image_desc_t was added which holds the information about images, such as: ep_info and image_info. This patch introduces following platform porting functions: unsigned int bl1_plat_get_next_image_id(void); This is used to identify the next image to be loaded and executed by BL1. struct image_desc *bl1_plat_get_image_desc(unsigned int image_id); This is used to retrieve the image_desc for given image_id. void bl1_plat_set_ep_info(unsigned int image_id, struct entry_point_info *ep_info); This function allows platforms to update ep_info for given image_id. The plat_bl1_common.c file provides default weak implementations of all above functions, the `bl1_plat_get_image_desc()` always return BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns. These functions gets compiled into all BL1 platforms by default. Platform setup in BL1, using `bl1_platform_setup()`, is now done _after_ the initialization of authentication module. This change provides the opportunity to use authentication while doing the platform setup in BL1. In order to store secure/non-secure context, BL31 uses percpu_data[] to store context pointer for each core. In case of BL1 only the primary CPU will be active hence percpu_data[] is not required to store the context pointer. This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to store the context and context pointers respectively. It also also re-defines cm_get_context() and cm_set_context() for BL1 in bl1/bl1_context_mgmt.c. BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime environment, to support resuming execution from a previously saved context. NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()` INSTEAD TO MAINTAIN EXISTING BEHAVIOUR. Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
-
- 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
-
- 26 Nov, 2015 1 commit
-
-
Sandrine Bailleux authored
This patch adds support for booting EL3 payloads on CSS platforms, for example Juno. In this scenario, the Trusted Firmware follows its normal boot flow up to the point where it would normally pass control to the BL31 image. At this point, it jumps to the EL3 payload entry point address instead. Before handing over to the EL3 payload, the data SCP writes for AP at the beginning of the Trusted SRAM is restored, i.e. we zero the first 128 bytes and restore the SCP Boot configuration. The latter is saved before transferring the BL30 image to SCP and is restored just after the transfer (in BL2). The goal is to make it appear that the EL3 payload is the first piece of software to run on the target. The BL31 entrypoint info structure is updated to make the primary CPU jump to the EL3 payload instead of the BL31 image. The mailbox is populated with the EL3 payload entrypoint address, which releases the secondary CPUs out of their holding pen (if the SCP has powered them on). The arm_program_trusted_mailbox() function has been exported for this purpose. The TZC-400 configuration in BL2 is simplified: it grants secure access only to the whole DRAM. Other security initialization is unchanged. This alternative boot flow is disabled by default. A new build option EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3 payload's entry point address. The build system has been modified such that BL31 and BL33 are not compiled and/or not put in the FIP in this case, as those images are not used in this boot flow. Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
-
- 19 Oct, 2015 1 commit
-
-
Sandrine Bailleux authored
This patch fixes the relative path to the 'bl1_private.h' header file included from 'arm_bl1_setup.c'. Note that, although the path was incorrect, it wasn't causing a compilation error because the header file still got included through an alternative include search path. Change-Id: I28e4f3dbe50e3550ca6cad186502c88a9fb5e260
-
- 28 Apr, 2015 1 commit
-
-
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
-
- 22 Jan, 2015 1 commit
-
-
Soby Mathew authored
This patch extends the build option `USE_COHERENT_MEMORY` to conditionally remove coherent memory from the memory maps of all boot loader stages. The patch also adds necessary documentation for coherent memory removal in firmware-design, porting and user guides. Fixes ARM-Software/tf-issues#106 Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
-
- 14 Aug, 2014 1 commit
-
-
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
-
- 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
-
- 28 Jul, 2014 1 commit
-
-
Soby Mathew authored
This patch adds baud rate and UART clock frequency as parameters to the pl011 driver api console_init(). This allows each platform to specify UART clock and baud rate according to their specific hardware implementation. Fixes ARM-software/tf-issues#215 Change-Id: Id13eef70a1c530e709b34dd1e6eb84db0797ced2
-
- 01 Jul, 2014 2 commits
-
-
Sandrine Bailleux authored
There was already a rudimentary mechanism to detect whether BL1 R/W data was loaded at the top or bottom of memory. Basically, - either BL1 was loaded at the very end of the trusted RAM - in all other cases BL1 was considered sitting at the bottom of the memory and the memory usage structure was updated accordingly, potentially resulting in critical memory waste. For instance, if BL1 R/W base address was set to (TZRAM_END - 4096 - bl1_size), it would virtually occupy the whole memory. This patch improves the mechanism to detect the location of BL1 to avoid such scenarios. Change-Id: I224a9edf0fe8d34208545d84b28b63f2bb830d03
-
Sandrine Bailleux authored
This concept is no longer required since we now support loading of images at fixed addresses only. The image loader now automatically detects the position of the image inside the current memory layout and updates the layout such that memory fragmentation is minimised. The 'attr' field of the meminfo data structure, which used to hold the bottom/top loading information, has been removed. Also the 'next' field has been removed as it wasn't used anywhere. The 'init_bl2_mem_layout()' function has been moved out of common code and put in BL1-specific code. It has also been renamed into 'bl1_init_bl2_mem_layout'. Fixes ARM-software/tf-issues#109 Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d
-
- 23 May, 2014 3 commits
-
-
Dan Handley authored
FVP specific files and functions containing the word "plat" have been renamed to use the word "fvp" to distinguish them from the common platform functionality and porting functions. Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
-
Dan Handley authored
Some platform porting functions were in BL specific header files. These have been moved to platform.h so that all porting functions are in the same place. The functions are now grouped by BL. Obsolete BL headers files have been removed. Also, the weak declaration of the init_bl2_mem_layout() function has been moved out the header file and into the source file (bl_common.c) using the more succinct #pragma syntax. This mitigates the risk of 2 weak definitions being created and the wrong one being picked up by the compiler. Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83
-
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
-
- 22 May, 2014 3 commits
-
-
Vikram Kanigiri authored
This change adds optional reset vector support to BL3-1 which means BL3-1 entry point can detect cold/warm boot, initialise primary cpu, set up cci and mail box. When using BL3-1 as a reset vector it is assumed that the BL3-1 platform code can determine the location of the BL3-2 images, or load them as there are no parameters that can be passed to BL3-1 at reset. It also fixes the incorrect initialisation of mailbox registers on the FVP platform This feature can be enabled by building the code with make variable RESET_TO_BL31 set as 1 Fixes ARM-software/TF-issues#133 Fixes ARM-software/TF-issues#20 Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570
-
Vikram Kanigiri authored
The issues addressed in this patch are: 1. Remove meminfo_t from the common interfaces in BL3-x, expecting that platform code will find a suitable mechanism to determine the memory extents in these images and provide it to the BL3-x images. 2. Remove meminfo_t and bl31_plat_params_t from all FVP BL3-x code as the images use link-time information to determine memory extents. meminfo_t is still used by common interface in BL1/BL2 for loading images Change-Id: I4e825ebf6f515b59d84dc2bdddf6edbf15e2d60f
-
Vikram Kanigiri authored
This patch is based on spec published at https://github.com/ARM-software/tf-issues/issues/133 It rearranges the bl31_args struct into bl31_params and bl31_plat_params which provide the information needed for Trusted firmware and platform specific data via x0 and x1 On the FVP platform BL3-1 params and BL3-1 plat params and its constituents are stored at the start of TZDRAM. The information about memory availability and size for BL3-1, BL3-2 and BL3-3 is moved into platform specific data. Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9
-
- 09 May, 2014 1 commit
-
-
Sandrine Bailleux authored
Instead of having a single version of the MMU setup functions for all bootloader images that can execute either in EL3 or in EL1, provide separate functions for EL1 and EL3. Each bootloader image can then call the appropriate version of these functions. The aim is to reduce the amount of code compiled in each BL image by embedding only what's needed (e.g. BL1 to embed only EL3 variants). Change-Id: Ib86831d5450cf778ae78c9c1f7553fe91274c2fa
-
- 08 May, 2014 1 commit
-
-
Vikram Kanigiri authored
This patch moves console_init() to bl32_early_platform_setup(). It also ensures that console_init() is called in each blX_early_platform_setup() function before the console is used e.g. through a printf call in an assert() statement. Fixes ARM-software/TF-issues#127 Change-Id: I5b1f17e0152bab674d807d2a95ff3689c5d4794e
-
- 06 May, 2014 2 commits
-
-
Dan Handley authored
Reduce the number of header files included from other header files as much as possible without splitting the files. Use forward declarations where possible. This allows removal of some unnecessary "#ifndef __ASSEMBLY__" statements. Also, review the .c and .S files for which header files really need including and reorder the #include statements alphabetically. Fixes ARM-software/tf-issues#31 Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
-
Dan Handley authored
Add tag names to all unnamed structs in header files. This allows forward declaration of structs, which is necessary to reduce header file nesting (to be implemented in a subsequent commit). Also change the typedef names across the codebase to use the _t suffix to be more conformant with the Linux coding style. The coding style actually prefers us not to use typedefs at all but this is considered a step too far for Trusted Firmware. Also change the IO framework structs defintions to use typedef'd structs to be consistent with the rest of the codebase. Change-Id: I722b2c86fc0d92e4da3b15e5cab20373dd26786f
-