- 09 Jul, 2014 2 commits
-
-
Dan Handley authored
Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform specific inputs in the arm_gic_setup() function so that the driver has no explicit dependency on platform code. Provide weak implementations of the platform interrupt controller API in a new file, plat/common/plat_gic.c. These simply call through to the ARM GIC driver. Move the only remaining FVP GIC function, fvp_gic_init() to plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c Fixes ARM-software/tf-issues#182 Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21
-
Dan Handley authored
Changed the fvp_config array in fvp_common.c into a struct and moved into a new optional common platform header, include/plat/common/plat_config.h. Removed the config definitions in fvp_def.h and updated all references to the platform config. This makes the interface to the platform config cleaner and uses a little less RAM. Fixes ARM-software/tf-issues#180 Change-Id: I58dd7b3c150f24f7ee230a26fd57c827853ba803
-
- 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
-
- 27 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
The code in the FVP port which checks the platform type and revision information in the SYS_ID register strictly supported only the first revision of the Base and Foundation FVPs. The current check also does not reflect the fact that the board revision field is 'local' to the board type (HBI field). Support for a new Foundation model is required now, and the checking code is relaxed to allow execution (with a diagnostic) on unrecognised revisions of the Base and Foundation FVP. Change-Id: I7cd3519dfb56954aafe5f52ce1fcea0ee257ba9f
-
- 24 Jun, 2014 4 commits
-
-
Andrew Thoelke authored
Making the simple mmio_read_*() and mmio_write_*() functions inline saves 360 bytes of code in FVP release build. Fixes ARM-software/tf-issues#210 Change-Id: I65134f9069f3b2d8821d882daaa5fdfe16355e2f
-
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
-
Sandrine Bailleux authored
The 'plat_print_gic_regs' macro was accessing the GICC_CTLR register using the GICD_CTLR offset. This still generates the right code in the end because GICD_CTLR == GICC_CTLR but this patch fixes it for the logic of the code. Change-Id: I7b17af50e587f07bec0e4c933e346088470c96f3
-
- 23 Jun, 2014 2 commits
-
-
Andrew Thoelke authored
The bakery lock code currently expects the calling code to pass the MPIDR_EL1 of the current CPU. This is not always done correctly. Also the change to provide inline access to system registers makes it more efficient for the bakery lock code to obtain the MPIDR_EL1 directly. This change removes the mpidr parameter from the bakery lock interface, and results in a code reduction of 160 bytes for the ARM FVP port. Fixes ARM-software/tf-issues#213 Change-Id: I7ec7bd117bcc9794a0d948990fcf3336a367d543
-
Andrew Thoelke authored
The array of affinity nodes is currently allocated for 32 entries with the PSCI_NUM_AFFS value defined in psci.h. This is not enough for large systems, and will substantially over allocate the array for small systems. This patch introduces an optional platform definition PLATFORM_NUM_AFFS to platform_def.h. If defined this value is used for PSCI_NUM_AFFS, otherwise a value of two times the number of CPU cores is used. The FVP port defines PLATFORM_NUM_AFFS to be 10 which saves nearly 1.5KB of memory. Fixes ARM-software/tf-issues#192 Change-Id: I68e30ac950de88cfbd02982ba882a18fb69c1445
-
- 20 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
This memory is not used by the FVP port and requires an additional 4KB translation table. This patch removes the entry from the memory map and reduces the number of allocated translation tables. Fixes ARM-software/tf-issues#196 Change-Id: I5b959e4fe92f5f892ed127c40dbe6c85eed3ed72
-
- 18 Jun, 2014 1 commit
-
-
Soby Mathew authored
This patch removes the reinitialisation of memory mapped system timer registers after a warm boot for the FVP. The system timers in FVP are in the 'Always ON' power domain which meant the reinitialisation was redundant and it could have conflicted with the setup the normal world has done. The programming of CNTACR(x) and CNTNSAR, the system timer registers, are removed from the warm boot path with this patch. Fixes ARM-software/tf-issues#169 Change-Id: Ie982eb03d1836b15ef3cf1568de2ea68a08b443e
-
- 16 Jun, 2014 1 commit
-
-
Juan Castillo authored
According to documentation, the Rev field is located at bit 28 in the V2M sysid register. Fixes ARM-software/tf-issues#179 Change-Id: I2abb7bdc092ccd3f41f8962dc8d8d8e44e8dfdc3
-
- 10 Jun, 2014 1 commit
-
-
Andrew Thoelke authored
Replace the current out-of-line assembler implementations of the system register and system instruction operations with inline assembler. This enables better compiler optimisation and code generation when accessing system registers. Fixes ARM-software/tf-issues#91 Change-Id: I149af3a94e1e5e5140a3e44b9abfc37ba2324476
-
- 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
-
- 02 Jun, 2014 1 commit
-
-
Lin Ma authored
Current ATF uses a direct physical-to-virtual mapping, that is, a physical address is mapped to the same address in the virtual space. For example, physical address 0x8000_0000 is mapped to 0x8000_0000 virtual. This approach works fine for FVP as all its physical addresses fall into 0 to 4GB range. But for other platform where all I/O addresses are 48-bit long, If we follow the same direct mapping, we would need virtual address range from 0 to 0x8fff_ffff_ffff, which is about 144TB. This requires a significant amount of memory for MMU tables and it is not necessary to use that much virtual space in ATF. The patch is to enable mapping a physical address range to an arbitrary virtual address range (instead of flat mapping) Changed "base" to "base_va" and added "base_pa" in mmap_region_t and modified functions such as mmap_add_region and init_xlation_table etc. Fixes ARM-software/tf-issues#158
-
- 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
-
- 27 May, 2014 1 commit
-
-
Dan Handley authored
Rename the ic_* platform porting functions to plat_ic_* to be consistent with the other functions in platform.h. Also rename bl31_get_next_image_info() to bl31_plat_get_next_image_ep_info() and remove the duplicate declaration in bl31.h. Change-Id: I4851842069d3cff14c0a468daacc0a891a7ede84
-
- 23 May, 2014 9 commits
-
-
Dan Handley authored
Previously, the enable_mmu_elX() functions were implicitly part of the platform porting layer since they were included by generic code. These functions have been placed behind 2 new platform functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu(). These are weakly defined so that they can be optionally overridden by platform ports. Also, the enable_mmu_elX() functions have been moved to lib/aarch64/xlat_tables.c for optional re-use by platform ports. These functions are tightly coupled with the translation table initialization code. Fixes ARM-software/tf-issues#152 Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c
-
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
-
Dan Handley authored
Some data variables were declared but not used. These have been removed. Change-Id: I038632af3c32d88984cd25b886c43ff763269bf9
-
Dan Handley authored
Function declarations implicitly have external linkage so do not need the extern keyword. Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32
-
Sandrine Bailleux authored
Currently the platform code gets to define the base address of each boot loader image. However, the linker scripts couteract this flexibility by enforcing a fixed overall layout of the different images. For example, they require that the BL3-1 image sits below the BL2 image. Choosing BL3-1 and BL2 base addresses in such a way that it violates this constraint makes the build fail at link-time. This patch requires the platform code to now define a limit address for each image. The linker scripts check that the image fits within these bounds so they don't rely anymore on the position of a given image in regard to the others. Fixes ARM-software/tf-issues#163 Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c
-
Sandrine Bailleux authored
BL1 RO and RW base address used to be fixed, respectively to the first address of the Trusted ROM and the first address of the Trusted RAM. Introduce new platform defines to configure the BL1 RO and RW base addresses. Change-Id: If26616513a47798593a4bb845a4b0fb37c867cd6
-
Andrew Thoelke authored
At present BL3-1 has access to all of the SRAM, including regions that are mapped as read-only and non-cacheable by other firmware images. This patch restricts BL3-1 to only be able to read/write from memory used for its own data sections Change-Id: I26cda1b9ba803d91a9eacda768f3ce7032c6db94 Conflicts: plat/fvp/bl31_plat_setup.c
-
- 22 May, 2014 10 commits
-
-
Achin Gupta authored
This patch adds support in the TSP for handling S-EL1 interrupts handed over by the TSPD. It includes GIC support in its platform port, updates various statistics related to FIQ handling, exports an entry point that the TSPD can use to hand over interrupts and defines the handover protocol w.r.t what context is the TSP expected to preserve and the state in which the entry point is invoked by the TSPD. Change-Id: I93b22e5a8133400e4da366f5fc862f871038df39
-
Achin Gupta authored
This patch introduces a set of functions which allow generic firmware code e.g. the interrupt management framework to access the platform interrupt controller. APIs for finding the type and id of the highest pending interrupt, acknowledging and EOIing an interrupt and finding the security state of an interrupt have been added. It is assumed that the platform interrupt controller implements the v2.0 of the ARM GIC architecture specification. Support for v3.0 of the specification for managing interrupts in EL3 and the platform port will be added in the future. Change-Id: Ib3a01c2cf3e3ab27806930f1be79db2b29f91bcf
-
Achin Gupta authored
This patch introduces a framework for registering interrupts routed to EL3. The interrupt routing model is governed by the SCR_EL3.IRQ and FIQ bits and the security state an interrupt is generated in. The framework recognizes three type of interrupts depending upon which exception level and security state they should be handled in i.e. Secure EL1 interrupts, Non-secure interrupts and EL3 interrupts. It provides an API and macros that allow a runtime service to register an handler for a type of interrupt and specify the routing model. The framework validates the routing model and uses the context management framework to ensure that it is applied to the SCR_EL3 prior to entry into the target security state. It saves the handler in internal data structures. An API is provided to retrieve the handler when an interrupt of a particular type is asserted. Registration is expected to be done once by the primary CPU. The same handler and routing model is used for all CPUs. Support for EL3 interrupts will be added to the framework in the future. A makefile flag has been added to allow the FVP port choose between ARM GIC v2 and v3 support in EL3. The latter version is currently unsupported. A framework for handling interrupts in BL3-1 will be introduced in subsequent patches. The default routing model in the absence of any handlers expects no interrupts to be routed to EL3. Change-Id: Idf7c023b34fcd4800a5980f2bef85e4b5c29e649
-
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
-
- 16 May, 2014 1 commit
-
-
Soby Mathew authored
This patch implements the register reporting when unhandled exceptions are taken in BL3-1. Unhandled exceptions will result in a dump of registers to the console, before halting execution by that CPU. The Crash Stack, previously called the Exception Stack, is used for this activity. This stack is used to preserve the CPU context and runtime stack contents for debugging and analysis. This also introduces the per_cpu_ptr_cache, referenced by tpidr_el3, to provide easy access to some of BL3-1 per-cpu data structures. Initially, this is used to provide a pointer to the Crash stack. panic() now prints the the error file and line number in Debug mode and prints the PC value in release mode. The Exception Stack is renamed to Crash Stack with this patch. The original intention of exception stack is no longer valid since we intend to support several valid exceptions like IRQ and FIQ in the trusted firmware context. This stack is now utilized for dumping and reporting the system state when a crash happens and hence the rename. Fixes ARM-software/tf-issues#79 Improve reporting of unhandled exception Change-Id: I260791dc05536b78547412d147193cdccae7811a
-
- 12 May, 2014 1 commit
-
-
Andrew Thoelke authored
The TZC configuration on FVP was incorrectly allowing both secure and non-secure accesses to the DRAM, which can cause aliasing problems for software. It was also not enabling virtio access on some models. This patch fixes both of those issues. The patch also enabless non-secure access to the DDR RAM for all devices with defined IDs. The third region of DDR RAM has been removed from the configuration as this is not used in any of the FVP models. Fixes ARM-software/tf-issues#150 Fixes ARM-software/tf-issues#151 Change-Id: I60ad5daaf55e14f178affb8afd95d17e7537abd7
-