- 28 Feb, 2018 1 commit
-
-
Michalis Pappas authored
Update qemu_configure_mmu_##_el to add an additional region for code, marked as MT_CODE | MT_SECURE. Update ro region attributes to NON_EXEC. Update calls to QEMU_CONFIGURE_BLx_MMU() to pass an additional region for code. Update calls to pass regions defined in common_def.h. Increase MAX_MMAP_REGIONS to 10. Enable SEPARATE_CODE_AND_RODATA by default on QEMU builds. Fixes ARM-software/tf-issues#558 Signed-off-by: Michalis Pappas <mpappas@fastmail.fm>
-
- 05 Feb, 2018 1 commit
-
-
Etienne Carriere authored
Define Qemu AArch32 implementation for some platform functions (core position, secondary boot cores, crash console). These are derived from the AArch64 implementation. BL31 on Qemu is needed only for ARMv8 and later. On ARMv7, BL32 is the first executable image after BL2. Support SP_MIN and OP-TEE as BL32: create a sp_min make script target in Qemu, define mapping for IMAGE_BL32 Minor fix Qemu return value type for plat_get_ns_image_entrypoint(). Qemu model for the Cortex-A15 does not support the virtualization extension although the core expects it. To overcome the issue, Qemu ARMv7 configuration set ARCH_SUPPORTS_VIRTUALIZATION to 0. Add missing AArch32 assembly macro arm_print_gic_regs from ARM platform used by the Qemu platform. Qemu Cortex-A15 model integrates a single cluster with up to 4 cores. Change-Id: I65b44399071d6f5aa40d5183be11422b9ee9ca15 Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
- 24 Aug, 2017 1 commit
-
-
Jens Wiklander authored
OP-TEE 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 OP-TEE: header, pager and pages 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. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
-
- 16 Aug, 2017 1 commit
-
-
Fu Wei authored
The generic LOAD_IMAGE_V2 framework has been merged and enable for almost all the arm platform. Because qemu platform doesn't share those common files with arm, QEMU haven't got this support yet. This patch add all the necessary code the files for adding LOAD_IMAGE_V2 support on QEMU and enable it as default. Fixes ARM-software/tf-issues#507 Signed-off-by: Fu Wei <fu.wei@linaro.org>
-
- 14 Jul, 2017 1 commit
-
-
Isla Mitchell authored
This fix modifies the order of system includes to meet the ARM TF coding standard. There are some exceptions to this change in order to retain header groupings and where there are headers within #if statements. Change-Id: Ib5b668c992d817cc860e97b29e16ef106d17e404 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>
-
- 02 May, 2017 1 commit
-
-
Jeenu Viswambharan authored
Replace all instances of checks with the new macro. Change-Id: I0eec39b9376475a1a9707a3115de9d36f88f8a2a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@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 1 commit
-
-
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>
-
- 09 Jun, 2016 1 commit
-
-
Jens Wiklander authored
This patch adds support for the QEMU virt ARMv8-A target. Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
-
- 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
-
- 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
-