- 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>
-
- 01 May, 2018 1 commit
-
-
Roberto Vargas authored
Previously mem_protect used to be only supported from BL2. This is not helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates mem_protect from el3_runtime firmware on ARM Platforms specifically when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap tables temporarily and then the protected regions are then cleared. This avoids the need to map the non secure DRAM permanently to BL31/sp_min. The stack size is also increased, because DYNAMIC_XLAT_TABLES require a bigger stack. Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 26 Mar, 2018 1 commit
-
-
Jonathan Wright authored
Ensure (where possible) that switch statements in plat comply with MISRA rules 16.1 - 16.7. Change-Id: Ie4a7d2fd10f6141c0cfb89317ea28a755391622f Signed-off-by: Jonathan Wright <jonathan.wright@arm.com>
-
- 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>
-
- 22 Feb, 2018 1 commit
-
-
Soby Mathew authored
Change-Id: I93e491fde2a991fc39584c2762f33cbea40541e3 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 25 Sep, 2017 1 commit
-
-
Roberto Vargas authored
mem_protect needs some kind of non-volatile memory because it has to remember its state across reset and power down events. The most suitable electronic part for this feature is a NVRAM which should be only accesible from the secure world. Juno and FVP lack such hardware and for this reason the MEM_PROTECT functionality is implemented with Flash EEPROM memory on both boards, even though this memory is accesible from the non-secure world. This is done only to show a full implementation of these PSCI features, but an actual system shouldn't use a non-secure NVRAM to implement it. The EL3 runtime software will write the mem_protect flag and BL2 will read and clear the memory ranges if enabled. It is done in BL2 because it reduces the time that TF needs access to the full non-secure memory. The memory layout of both boards is defined using macros which take different values in Juno and FVP platforms. Generic platform helpers are added that use the platform specific macros to generate a mem_region_t that is valid for the platform. Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 06 Sep, 2017 1 commit
-
-
Soby Mathew authored
This patch does the required changes to enable CSS platforms to build and use the SDS framework. Since SDS is always coupled with SCMI protocol, the preexisting SCMI build flag is now renamed to `CSS_USE_SCMI_SDS_DRIVER` which will enable both SCMI and SDS on CSS platforms. Also some of the workarounds applied for SCMI are now removed with SDS in place. Change-Id: I94e8b93f05e3fe95e475c5501c25bec052588a9c Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 09 Aug, 2017 1 commit
-
-
Summer Qin authored
Trusted OS may have extra images to be loaded. Load them one by one and do the parsing. In this patch, ARM TF need to load up to 3 images for optee os: header, pager and paged images. Header image is the info about optee os and images. Pager image include pager code and data. Paged image include the paging parts using virtual memory. Change-Id: Ia3bcfa6d8a3ed7850deb5729654daca7b00be394 Signed-off-by: Summer Qin <summer.qin@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>
-
- 24 May, 2017 1 commit
-
-
dp-arm authored
Change-Id: I4108ce8d1fe7d3fd51a5a96d43b9134c23b8399b Signed-off-by: dp-arm <dimitris.papastamos@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>
-
- 06 Feb, 2017 1 commit
-
-
Douglas Raillard authored
Replace all use of memset by zeromem when zeroing moderately-sized structure by applying the following transformation: memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x)) As the Trusted Firmware is compiled with -ffreestanding, it forbids the compiler from using __builtin_memset and forces it to generate calls to the slow memset implementation. Zeromem is a near drop in replacement for this use case, with a more efficient implementation on both AArch32 and AArch64. Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e Signed-off-by: Douglas Raillard <douglas.raillard@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 BL2 for AArch32 state. It instantiates a descriptor array for ARM platforms describing image and entrypoint information for `SCP_BL2`, `BL32` and `BL33`. It also enables building of BL2 for ARCH=aarch32. Change-Id: I60dc7a284311eceba401fc789311c50ac746c51e
-
Yatharth Kochar authored
This patch adds 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 2 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
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
-
- 08 Apr, 2016 1 commit
-
-
Antonio Nino Diaz authored
Previously, when building TF without SPD support, BL2 tried to load a BL32 image from the FIP and fails to find one, which resulted on warning messages on the console. Even if there is a BL32 image in the FIP it shouldn't be loaded because there is no way to transfer control to the Secure Payload without SPD support. The Makefile has been modified to pass a define of the form SPD_${SPD} to the source code the same way it's done for PLAT. The define SPD_none is then used to undefine BL32_BASE when BL32 is not used to prevent BL2 from trying to load a BL32 image and failing, thus removing the warning messages mentioned above. Fixes ARM-software/tf-issues#287 Change-Id: Ifeb6f1c26935efb76afd353fea88e87ba09e9658
-
- 31 Mar, 2016 1 commit
-
-
David Wang authored
This patch adds an option to the ARM common platforms to load BL31 in the TZC secured DRAM instead of the default secure SRAM. To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options. If TSP is present, then setting this option also sets the TSP location to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag. To use this feature, BL2 platform code must map in the DRAM used by BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose. Currently, only the FVP BL2 platform code maps in this DRAM. Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
-
- 14 Dec, 2015 2 commits
-
-
Juan Castillo authored
This patch removes the dash character from the image name, to follow the image terminology in the Trusted Firmware Wiki page: https://github.com/ARM-software/arm-trusted-firmware/wiki Changes apply to output messages, comments and documentation. non-ARM platform files have been left unmodified. Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
-
Juan Castillo authored
This patch replaces all references to the SCP Firmware (BL0, BL30, BL3-0, bl30) with the image terminology detailed in the TF wiki (https://github.com/ARM-software/arm-trusted-firmware/wiki): BL0 --> SCP_BL1 BL30, BL3-0 --> SCP_BL2 bl30 --> scp_bl2 This change affects code, documentation, build system, tools and platform ports that load SCP firmware. ARM plaforms have been updated to the new porting API. IMPORTANT: build option to specify the SCP FW image has changed: BL30 --> SCP_BL2 IMPORTANT: This patch breaks compatibility for platforms that use BL2 to load SCP firmware. Affected platforms must be updated as follows: BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID BL30_BASE --> SCP_BL2_BASE bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo() bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2() Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
-
- 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
-
- 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
-
- 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 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
-
- 09 Oct, 2014 1 commit
-
-
Juan Castillo authored
This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
-
- 21 Aug, 2014 3 commits
-
-
Soby Mathew authored
This patch changes the UART port assignment for various BL stages so as to make it consistent on the platform ports. The BL1, BL2 and BL3-1 now uses UART0 on the FVP port and SoC UART0 on the Juno port. The BL3-2 uses UART2 on the FVP port and FPGA UART0 on the Juno port. This provides an interim fix to ARM-software/tf-issues#220 until support is added for changing the UART port for a BL image between cold boot and runtime. Change-Id: Iae5faea90be3d59e41e597b34a902f93e737505a
-
Juan Castillo authored
This patch removes the PRIMARY_CPU definition hardcoded in the Juno port. Instead, the primary CPU is obtained at runtime by reading the SCC General Purpose Register 1 (GPR_1), whose value is copied by the SCP into shared memory during the boot process. Change-Id: I3981daa92eb7142250712274cf7f655b219837f5
-
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
-
- 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
-