- 26 Feb, 2018 3 commits
-
-
Soby Mathew authored
Change-Id: I1d85b76af002b8b672fcaeca94939b7420bc8243 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
The patch adds the necessary changes to load HW_CONFIG in BL2 for ARM Platforms : 1. The load address of HW_CONFIG is specified via the `hw_config_addr` property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size` property defines the maximum size to be expected for the HW_CONFIG. The `arm_dyn_cfg_helpers.c` and corresponding header implements utility functions to parse these DT properties defined. The `arm_dyn_cfg.c` implements wrappers to these helpers to enable them to be invoked from ARM platform layer. 2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is the list of images to be loaded by BL2. 3. The `libfdt` sources are now included when BL2 is built 4. A new helper `populate_next_bl_params_config()` is introduced in desc_image_load.c to populate the subsequent executable BL images with the `hw_config` and the corresponding `fw_config` if available. The `plat_get_next_bl_params()` API for ARM platforms is modified to invoke this new helper. 5. The implementation of `bl2_early_platform_setup2()` is modified to consider `arg0` as well in addition to `arg1` passed from BL1. 6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt. Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Soby Mathew authored
This patch migrates the ARM Standard platforms to the new BL handover interface. The arm_blx_early_platform_setup() functions are also modified to take in 4 arguments. The `ARM_BL31_PLAT_PARAM_VAL` value passed to BL31 from BL2 is now in arg3 in preparation of dynamic configuration arguments. Change-Id: I33e8e61325a19e7a7127b1ff203c3b86921bf153 Signed-off-by: Soby Mathew <soby.mathew@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 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
-
- 04 Dec, 2015 1 commit
-
-
Juan Castillo authored
This patch fixes several issues with the SP804 delay timer on FVP: * By default, the SP804 dual timer on FVP runs at 32 KHz. In order to run the timer at 35 MHz (as specified in the FVP user manual) the Overwrite bit in the SP810 control register must be set. * The CLKMULT and CLKDIV definitions are mixed up: delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz) From the delay function: delta_us = (delta * ops->clk_mult) / ops->clk_div; Matching both expressions: 1 / f(MHz) = ops->clk_mult / ops->clk_div And consequently: f(MHz) = ops->clk_div / ops->clk_mult Which, for a 35 MHz timer, translates to: ops->clk_div = 35 ops->clk_mult = 1 * The comment in the delay timer header file has been corrected: The ratio of the multiplier and the divider is the clock period in microseconds, not the frequency. Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
-
- 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
-
- 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
-
- 28 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch moves fvp_io_setup() to bl2_early_platform_setup() in order to allow BL2 to use the IO framework before bl2_platform_setup(). Change-Id: I75e1a772ab5f9b4727f6727822a2527c30f3c63d
-
- 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
-
- 21 Jan, 2015 1 commit
-
-
Juan Castillo authored
This patch maps the non-secure region of DRAM1 in the MMU. The non-secure region comprises the whole DRAM1 (0x80000000 - 0xffffffff) excluding the top 16 MB (0xff000000 - 0xffffffff). The TrustZone controller configures this 16 MB region as secure memory, so it can not be accessed in non-secure mode. The number of MMU tables in BL2 has been increased to 3 because the new size of the non-secure region in DRAM requires an extra L2 table. Change-Id: I5ad080c6e181f6b6060e15cebb1d18b7fa128cf5
-
- 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
-
- 14 Aug, 2014 1 commit
-
-
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 1 commit
-
-
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 1 commit
-
-
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
-
- 24 Jun, 2014 2 commits
-
-
Juan Castillo authored
Exclude stdlib files because they do not follow kernel code style. Fixes ARM-software/tf-issues#73 Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab
-
Vikram Kanigiri authored
This patch reworks FVP specific code responsible for determining the entry point information for BL3-2 and BL3-3 stages when BL3-1 is configured as the reset handler. Change-Id: Ia661ff0a6a44c7aabb0b6c1684b2e8d3642d11ec
-
- 05 Jun, 2014 1 commit
-
-
Sandrine Bailleux authored
'bl2_el_change_mem_ptr' variable is a left over from the former BL2/BL3-1 interface. Change-Id: Ib0979c8e2809e103a41f9c5cc4afec7dd21ac9ab
-
- 29 May, 2014 1 commit
-
-
Andrew Thoelke authored
bl2_main() was overwriting any platform set X1 parameter for BL3-1 with the value zero. This patch ensure that any platform set value is correctly passed to BL3-1. The FVP port adds a check to verify this parameter is being passed correctly. Fixes ARM-software/tf-issues#173 Change-Id: Ifbcda73d3d41d2b04a4baf5614e9d2d21f1717c8
-
- 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
-