- 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 7 commits
-
-
Sandrine Bailleux authored
The TSP used to execute from secure DRAM on the FVPs because there was not enough space in Trusted SRAM to fit it in. Thanks to recent RAM usage enhancements being implemented, we have made enough savings for the TSP to execute in SRAM. However, there is no contiguous free chunk of SRAM big enough to hold the TSP. Therefore, the different bootloader images need to be moved around to reduce memory fragmentation. 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 slice of the cake since they will most probably grow the most. A few useful numbers for reference (valid at the time of this patch): |-----------------------|------------------------------- | image size (debug) | extra space for the future --------|-----------------------|------------------------------- BL1 R/W | 20 KB | 4 KB BL2 | 44 KB | 4 KB BL3-1 | 108 KB | 12 KB BL3-2 | 56 KB | 8 KB --------|-----------------------|------------------------------- Total | 228 KB | 28 KB = 256 KB --------|-----------------------|------------------------------- Although on FVPs the TSP now executes from Trusted SRAM by default, this patch keeps the option to execute it from Trusted DRAM. This is controlled by the build configuration 'TSP_RAM_LOCATION'. Fixes ARM-Software/tf-issues#81 Change-Id: Ifb9ef2befa9a2d5ac0813f7f79834df7af992b94
-
Sandrine Bailleux authored
The TSP's linker script used to assume that the TSP would execute from secure DRAM. Although it is currently the case on FVPs, platforms are free to use any secure memory they wish. This patch introduces the flexibility to load the TSP into any secure memory. The platform code gets to specify the extents of this memory in the platform header file, as well as the BL3-2 image limit address. The latter definition allows to check in a generic way that the BL3-2 image fits in its bounds. Change-Id: I9450f2d8b32d74bd00b6ce57a0a1542716ab449c
-
Juan Castillo authored
TZC-400 is configured to set the last 16MB of DRAM1 as secure memory and the rest of DRAM as non-secure. Non-secure software must not attempt to access the 16MB secure area. Device tree files (sources and binaries) have been updated to match this configuration, removing that memory from the Linux physical memory map. To use UEFI and Linux with this patch, the latest version of UEFI and the updated device tree files are required. Check the user guide in the documentation for more details. Replaced magic numbers with #define for memory region definition in the platform security initialization function. Fixes ARM-software/tf-issues#149 Change-Id: Ia5d070244aae6c5288ea0e6c8e89d92859522bfe
-
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
-
Vikram Kanigiri authored
This patch reworks the handover interface from: BL1 to BL2 and BL2 to BL3-1. It removes the raise_el(), change_el(), drop_el() and run_image() functions as they catered for code paths that were never exercised. BL1 calls bl1_run_bl2() to jump into BL2 instead of doing the same by calling run_image(). Similarly, BL2 issues the SMC to transfer execution to BL3-1 through BL1 directly. Only x0 and x1 are used to pass arguments to BL31. These arguments and parameters for running BL3-1 are passed through a reference to a 'el_change_info_t' structure. They were being passed value in general purpose registers earlier. Change-Id: Id4fd019a19a9595de063766d4a66295a2c9307e1
-
- 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
-
- 24 Apr, 2014 1 commit
-
-
Harry Liebel authored
- Use the TrustZone controller on Base FVP to program DRAM access permissions. By default no access to DRAM is allowed if 'secure memory' is enabled on the Base FVP. - The Foundation FVP does not have a TrustZone controller but instead has fixed access permissions. - Update FDTs for Linux to use timers at the correct security level. - Starting the FVPs with 'secure memory' disabled is also supported. Limitations: Virtio currently uses a reserved NSAID. This will be corrected in future FVP releases. Change-Id: I0b6c003a7b5982267815f62bcf6eb82aa4c50a31
-
- 26 Mar, 2014 1 commit
-
-
Vikram Kanigiri authored
This patch reworks the console driver to ensure that each bootloader stage initializes it independently. As a result, both BL3-1 and BL2 platform code now calls console_init() instead of relying on BL1 to perform console setup Fixes ARM-software/tf-issues#120 Change-Id: Ic4d66e0375e40a2fc7434afcabc8bbb4715c14ab
-
- 20 Feb, 2014 2 commits
-
-
Achin Gupta authored
This patch adds support for loading a BL3-2 image in BL2. In case a BL3-2 image is found, it also passes information to BL3-1 about where it is located and the extents of memory available to it. Information about memory extents is populated by platform specific code. The documentation has also been updated to reflect the above changes. Change-Id: I526b2efb80babebab1318f2b02e319a86d6758b0 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Achin Gupta authored
This patch reworks BL2 to BL3-1 hand over interface by introducing a composite structure (bl31_args) that holds the superset of information that needs to be passed from BL2 to BL3-1. - The extents of secure memory available to BL3-1 - The extents of memory available to BL3-2 (not yet implemented) and BL3-3 - Information to execute BL3-2 (not yet implemented) and BL3-3 images This patch also introduces a new platform API (bl2_get_bl31_args_ptr) that needs to be implemented by the platform code to export reference to bl31_args structure which has been allocated in platform-defined memory. The platform will initialize the extents of memory available to BL3-3 during early platform setup in bl31_args structure. This obviates the need for bl2_get_ns_mem_layout platform API. BL2 calls the bl2_get_bl31_args_ptr function to get a reference to bl31_args structure. It uses the 'bl33_meminfo' field of this structure to load the BL3-3 image. It sets the entry point information for the BL3-3 image in the 'bl33_image_info' field of this structure. The reference to this structure is passed to the BL3-1 image. Also fixes issue ARM-software/tf-issues#25 Change-Id: Ic36426196dd5ebf89e60ff42643bed01b3500517
-
- 17 Feb, 2014 2 commits
-
-
Harry Liebel authored
The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
-
James Morrissey authored
The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
-
- 17 Jan, 2014 1 commit
-
-
Dan Handley authored
Change-Id: Ic7fb61aabae1d515b9e6baf3dd003807ff42da60
-
- 12 Dec, 2013 1 commit
-
-
Sandrine Bailleux authored
Platform setup code has to reserve some memory for storing the memory layout information. It is populated in early platform setup code. blx_get_sec_mem_layout() functions used to return a copy of this structure. This patch modifies blx_get_sec_mem_layout() functions so that they now directly return a pointer to their memory layout structure. It ensures that the memory layout returned by blx_get_sec_mem_layout() is always up-to-date and also avoids a useless copy of the meminfo structure. Also rename blx_get_sec_mem_layout() to blx_plat_sec_mem_layout() to make it clear those functions are platform specific. Change-Id: Ic7a6f9d6b6236b14865ab48a9f5eff545ce56551
-
- 05 Dec, 2013 2 commits
-
-
Dan Handley authored
- Add instructions for contributing to ARM Trusted Firmware. - Update copyright text in all files to acknowledge contributors. Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
-
Sandrine Bailleux authored
- Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
-
- 27 Nov, 2013 3 commits
-
-
Sandrine Bailleux authored
On FVP platforms, for now it is assumed that the normal-world bootloader is already sitting in its final memory location. Therefore, BL2 doesn't need to load it and so it doesn't need to know the extents of the non-trusted DRAM. Change-Id: I33177ab43ca242edc8958f2fa8d994e7cf3e0843
-
Sandrine Bailleux authored
Global and static variables are expected to be initialised to zero by default. This is specified by the C99 standard. This patch removes some unnecessary initialisations of such variables. It fixes a compilation warning at the same time: plat/fvp/bl31_plat_setup.c:82:3: warning: missing braces around initializer [-Wmissing-braces] section("tzfw_coherent_mem"))) = {0}; ^ plat/fvp/bl31_plat_setup.c:82:3: warning: (near initialization for ‘ns_entry_info[0]’) [-Wmissing-braces] Note that GCC should not have emitted this warning message in the first place. The C Standard permits braces to be elided around subaggregate initializers. See this GCC bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 Change-Id: I13cb0c344feb9803bca8819f976377741fa6bc35
-
Sandrine Bailleux authored
blx_plat_arch_setup() should only perform platform-specific architectural setup, e.g. enabling the MMU. This patch moves generic architectural setup code out of blx_plat_arch_setup(). Change-Id: I4ccf56b8c4a2fa84909817779a2d97a14aaafab6
-
- 25 Oct, 2013 1 commit
-
-
Achin Gupta authored
-