- 21 Mar, 2014 2 commits
-
-
Vikram Kanigiri authored
Each ARM Trusted Firmware image should know in which EL it is running and it should use the corresponding register directly instead of reading currentEL and knowing which asm register to read/write Change-Id: Ief35630190b6f07c8fbb7ba6cb20db308f002945
-
Vikram Kanigiri authored
Remove the hard coding of all the MMU related registers with 0 and disable MMU by clearing the M and C bit in SCTLR_ELx Change-Id: I4a0b1bb14a604734b74c32eb31315d8504a7b8d8
-
- 10 Mar, 2014 2 commits
-
-
Jeenu Viswambharan authored
At present, bl1_arch_setup() and bl31_arch_setup() program the counter frequency using a value from the memory mapped generic timer. The generic timer however is not necessarily present on all ARM systems (although it is architected to be present on all server systems). This patch moves the timer setup to platform-specific code and updates the relevant documentation. Also, CNTR.FCREQ is set as the specification requires the bit corresponding to the counter's frequency to be set when enabling. Since we intend to use the base frequency, set bit 8. Fixes ARM-software/tf-issues#24 Change-Id: I32c52cf882253e01f49056f47c58c23e6f422652
-
Jeenu Viswambharan authored
This patch removes the 'CPU present' flag that's being set but not referred or used anywhere else. Change-Id: Iaf82bdb354134e0b33af16c7ba88eb2259b2682a
-
- 05 Mar, 2014 4 commits
-
-
Ryan Harkin authored
Fixes ARM-software/tf-issues#41 The policy functions for each file to be loaded were implemented by copy/pasting one method and then varying the data checked. This patch creates a generic function to check the policy based on the data stored in a table. This removes the amount of duplicated code but also makes the code simpler and more efficient. Change-Id: I1c52eacf6f18a1442dabbb33edd03d4bb8bbeae0 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
-
Jon Medhurst authored
Change-Id: I559c5a4d86cad55ce3f6ad71285b538d3cfd76dc Signed-off-by: Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
This change requires all platforms to now specify a list of source files rather than object files. New source files should preferably be specified by using the path as well and we should add this in the future for all files so we can remove use of vpath. This is desirable because vpath hides issues like the fact that BL2 currently pulls in a BL1 file bl1/aarch64/early_exceptions.S and if in the future we added bl2/aarch64/early_exceptions.S then it's likely only one of the two version would be used for both bootloaders. This change also removes the 'dump' build target and simply gets bootloaders to always generate a dump file. At the same time the -x option is added so the section headers and symbols table are listed. Fixes ARM-software/tf-issues#11 Change-Id: Ie38f7be76fed95756c8576cf3f3ea3b7015a18dc Signed-off-by: Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Make gicd_set_ipriorityr() actually write to the priority register. Also correct callers of this function which want the highest priority to use the value zero as this is the highest priority value according to the ARM Generic Interrupt Controller Architecture Specification. To make this easier to get right, we introduce defines for the lowest and highest priorities for secure and non-secure interrupts. Fixes ARM-software/tf-issues#21 Signed-off-by: Jon Medhurst <tixy@linaro.org>
-
- 26 Feb, 2014 1 commit
-
-
Sandrine Bailleux authored
The UART used to be initialised in bl1_platform_setup(). This is too late because there are some calls to the assert() macro, which needs to print some messages on the console, before that. This patch moves the UART initialisation code to bl1_early_platform_setup(). Fixes ARM-software/tf-issues#49 Change-Id: I98c83a803866372806d2a9c2e1ed80f2ef5b3bcc
-
- 20 Feb, 2014 8 commits
-
-
Jeenu Viswambharan authored
At present many recoverable failures are reported as errors. This patch modifies all such failures to be reported as warnings instead. Change-Id: I5141653c82498defcada9b90fdf7498ba496b2f2
-
Achin Gupta authored
This patch adds the TSPD service which is responsible for managing communication between the non-secure state and the Test Secure Payload (TSP) executing in S-EL1. The TSPD does the following: 1. Determines the location of the TSP (BL3-2) image and passes control to it for initialization. This is done by exporting the 'bl32_init()' function. 2. Receives a structure containing the various entry points into the TSP image as a response to being initialized. The TSPD uses this information to determine how the TSP should be entered depending on the type of operation. 3. Implements a synchronous mechanism for entering into and returning from the TSP image. This mechanism saves the current C runtime context on top of the current stack and jumps to the TSP through an ERET instruction. The TSP issues an SMC to indicate completion of the previous request. The TSPD restores the saved C runtime context and resumes TSP execution. This patch also introduces a Make variable 'SPD' to choose the specific SPD to include in the build. By default, no SPDs are included in the build. Change-Id: I124da5695cdc510999b859a1bf007f4d049e04f3 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Achin Gupta authored
This patch adds a simple TSP as the BL3-2 image. The secure payload executes in S-EL1. It paves the way for the addition of the TSP dispatcher runtime service to BL3-1. The TSP and the dispatcher service will serve as an example of the runtime firmware's ability to toggle execution between the non-secure and secure states in response to SMC request from the non-secure state. The TSP will be replaced by a Trusted OS in a real system. The TSP also exports a set of handlers which should be called in response to a PSCI power management event e.g a cpu being suspended or turned off. For now it runs out of Secure DRAM on the ARM FVP port and will be moved to Secure SRAM later. The default translation table setup code assumes that the caller is executing out of secure SRAM. Hence the TSP exports its own translation table setup function. The TSP only services Fast SMCs, is non-reentrant and non-interruptible. It does arithmetic operations on two sets of four operands, one set supplied by the non-secure client, and the other supplied by the TSP dispatcher in EL3. It returns the result according to the Secure Monitor Calling convention standard. This TSP has two functional entry points: - An initial, one-time entry point through which the TSP is initialized and prepares for receiving further requests from secure monitor/dispatcher - A fast SMC service entry point through which the TSP dispatcher requests secure services on behalf of the non-secure client Change-Id: I24377df53399307e2560a025eb2c82ce98ab3931 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Achin Gupta authored
This patch adds the ability to specify the base address of a UART device for initialising the console. This allows a boot loader stage to use a different UART device from UART0 (default) for the console. Change-Id: Ie60b927389ae26085cfc90d22a564ff83ba62955
-
Achin Gupta authored
This patch factors out the ARM FVP specific code to create MMU translation tables so that it is possible for a boot loader stage to create a different set of tables instead of using the default ones. The default translation tables are created with the assumption that the calling boot loader stage executes out of secure SRAM. This might not be true for the BL3_2 stage in the future. A boot loader stage can define the `fill_xlation_tables()` function as per its requirements. It returns a reference to the level 1 translation table which is used by the common platform code to setup the TTBR_EL3. This patch is a temporary solution before a larger rework of translation table creation logic is introduced. Change-Id: I09a075d5da16822ee32a411a9dbe284718fb4ff6
-
Achin Gupta authored
This patch adds the following support to the BL3-1 stage: 1. BL3-1 allows runtime services to specify and determine the security state of the next image after BL3-1. This has been done by adding the `bl31_set_next_image_type()` & `bl31_get_next_image_type()` apis. The default security state is non-secure. The platform api `bl31_get_next_image_info()` has been modified to let the platform decide which is the next image in the desired security state. 2. BL3-1 exports the `bl31_prepare_next_image_entry()` function to program entry into the target security state. It uses the apis introduced in 1. to do so. 3. BL3-1 reads the information populated by BL2 about the BL3-2 image into its internal data structures. 4. BL3-1 introduces a weakly defined reference `bl32_init()` to allow initialisation of a BL3-2 image. A runtime service like the Secure payload dispatcher will define this function if present. Change-Id: Icc46dcdb9e475ce6575dd3f9a5dc7a48a83d21d1
-
Achin Gupta authored
This patch adds support for loading a BL3-2 image in BL2. In case a BL3-2 image is found, it also passes information to BL3-1 about where it is located and the extents of memory available to it. Information about memory extents is populated by platform specific code. The documentation has also been updated to reflect the above changes. Change-Id: I526b2efb80babebab1318f2b02e319a86d6758b0 Co-authored-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Achin Gupta authored
This patch reworks BL2 to BL3-1 hand over interface by introducing a composite structure (bl31_args) that holds the superset of information that needs to be passed from BL2 to BL3-1. - The extents of secure memory available to BL3-1 - The extents of memory available to BL3-2 (not yet implemented) and BL3-3 - Information to execute BL3-2 (not yet implemented) and BL3-3 images This patch also introduces a new platform API (bl2_get_bl31_args_ptr) that needs to be implemented by the platform code to export reference to bl31_args structure which has been allocated in platform-defined memory. The platform will initialize the extents of memory available to BL3-3 during early platform setup in bl31_args structure. This obviates the need for bl2_get_ns_mem_layout platform API. BL2 calls the bl2_get_bl31_args_ptr function to get a reference to bl31_args structure. It uses the 'bl33_meminfo' field of this structure to load the BL3-3 image. It sets the entry point information for the BL3-3 image in the 'bl33_image_info' field of this structure. The reference to this structure is passed to the BL3-1 image. Also fixes issue ARM-software/tf-issues#25 Change-Id: Ic36426196dd5ebf89e60ff42643bed01b3500517
-
- 17 Feb, 2014 6 commits
-
-
Achin Gupta authored
This patch increases coherent stack size for both debug and release builds in order to accommodate stack-heavy printf() and extended EL3 functionality Change-Id: I30ef30530a01517a97e63d703873374828c09f20
-
Jeenu Viswambharan authored
This patch moves the translation tables into their own section. This saves space that would otherwise have been lost in padding due to page table alignment constraints. The BL31 and BL32 bases have been consequently adjusted. Change-Id: Ibd65ae8a5ce4c4ea9a71a794c95bbff40dc63e65
-
Harry Liebel authored
The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
-
James Morrissey authored
The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
-
James Morrissey authored
This is intended primarily for use as a storage abstraction. It allows operations such as image-loading to be implemented in a platform-independent fashion. Each platform registers a set of IO drivers during initialisation. The platform must also provide a function that will return a device and a specifier that can be used to access specified content. Clients of the API will primarily use device and entity handles. The term "entity" is deliberately vague, to allow for different representations of content accessed using different types of specifier, but will often be interpreted as a "file" where the specifier will normally be its path. This commit builds, but is intended to be paired with a sample implementation of "load_image" using a semi-hosting driver on FVP. Change-Id: Id3b52f1c0eb9ce76b44b99fc6b6460803668cc86
-
James Morrissey authored
Also fix warnings generated in release builds when assert code is absent. Change-Id: I45b9173d3888f9e93e98eb5b4fdc06727ba5cbf4
-
- 23 Jan, 2014 1 commit
-
-
Achin Gupta authored
The last CPU in a cluster is responsible for issuing the cluster power down request to the FVP power controller. If another CPU in this cluster wakes up before the last CPU enters WFI then the cluster power down request remains pending. If this request is not cancelled and the newly woken up CPU enters a simple WFI later, the power controller powers the cluster down. This leads to unpredictable behaviour. This patch fixes this issue by ensuring that the first CPU to wake up in a cluster writes its MPIDR to the power controller's PPONR. This cancels any pending cluster power down request. Change-Id: I7e787adfd6c9a0bd7308390e3309d46f35c01086
-
- 20 Jan, 2014 3 commits
-
-
Ryan Harkin authored
The FVP platform has a few filenames that begin with fvp_. These are renamed to plat_ to make it easier to use the FVP port as a template. Change-Id: I601e6256d5ef3bae81a2e1f5df6de56db5b27069 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
-
Ryan Harkin authored
Tidy up the spacing of variable definitions within the makefiles to make them more consistent, easier to read and amend. Change-Id: Ic6d7c8489ca4330824abb5cd1ead8f1d449d1a85 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
-
Ryan Harkin authored
Move all explicit platform or architecture specific references into a new platform.mk file that is defined for each platform. Change-Id: I9d6320d1ba957e0cc8d9b316b3578132331fa428 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
-
- 17 Jan, 2014 4 commits
-
-
Jeenu Viswambharan authored
Ctags seem to have a problem with generating tags for assembler symbols when a comment immediately follows an assembly label. This patch inserts a single space character between the label definition and the following comments to help ctags. The patch is generated by the command: git ls-files -- \*.S | xargs sed -i 's/^\([^:]\+\):;/\1: ;/1' Change-Id: If7a3c9d0f51207ea033cc8b8e1b34acaa0926475
-
Harry Liebel authored
The GICv3 distributor can have more ports than CPUs are available in the system. Probe all re-distributors and use the matching affinity levels as specified by each core and re-distributor to decide which re-distributor to use with which CPU core. If a core cannot be matched with a re-distributor, the core panics and is placed in an endless loop. Change-Id: Ie393cfe07c7449a2383959e3c968664882e18afc
-
Dan Handley authored
Change-Id: Ic7fb61aabae1d515b9e6baf3dd003807ff42da60
-
Ian Spray authored
GIC setup code which used to be in bl31_plat_setup.c is now in fvp_gic.c to simplify future changes to other bootloader stages. This patch moves code from bl31_plat_setup.c to fvp_gic.c, simplifies the include file list for bl31_plat_setup.c, moves GIC declarations from the bl31.h header file into the platform.h, and reworks files according to coding style guide. Change-Id: I48d82a4ba33e7114dcc88f9ca98767a06cf8f417
-
- 12 Dec, 2013 2 commits
-
-
Sandrine Bailleux authored
ns_entry_info used to be a per-cpu array. This is a waste of space because it is only accessed by the primary CPU on the cold boot path. This patch reduces ns_entry_info to a single-cpu area. Change-Id: I647c70c4e76069560f1aaad37a1d5910f56fba4c
-
Sandrine Bailleux authored
Platform setup code has to reserve some memory for storing the memory layout information. It is populated in early platform setup code. blx_get_sec_mem_layout() functions used to return a copy of this structure. This patch modifies blx_get_sec_mem_layout() functions so that they now directly return a pointer to their memory layout structure. It ensures that the memory layout returned by blx_get_sec_mem_layout() is always up-to-date and also avoids a useless copy of the meminfo structure. Also rename blx_get_sec_mem_layout() to blx_plat_sec_mem_layout() to make it clear those functions are platform specific. Change-Id: Ic7a6f9d6b6236b14865ab48a9f5eff545ce56551
-
- 05 Dec, 2013 6 commits
-
-
Achin Gupta authored
In fvp_affinst_on/suspend, the non-secure entrypoint is always expected to lie in the DRAM. This check will not be valid if non-secure code executes directly out of flash e.g. a baremetal test. This patch removes this check. Change-Id: I0436e1138fc394aae8ff1ea59ebe38b46a440b61
-
Achin Gupta authored
In the previous psci implementation, the psci_afflvl_power_on_finish() function would run into an error condition if the value of the context id parameter in the cpu_on and cpu_suspend psci calls was != 0. The parameter was being restored as the return value of the affinity level 0 finisher function. A non zero context id would be treated as an error condition. This would prevent successful wake up of the cpu from a power down state. Also, the contents of the general purpose registers were not being cleared upon return to the non-secure world after a cpu power up. This could potentially allow the non-secure world to view secure data. This patch ensures that all general purpose registers are set to ~0 prior to the final eret that drops the execution to the non-secure world. The context id is used to initialize the general purpose register x0 prior to re-entry into the non-secure world and is no longer restored as a function return value. A platform helper (platform_get_stack()) has been introduced to facilitate this change. Change-Id: I2454911ffd75705d6aa8609a5d250d9b26fa097c
-
Achin Gupta authored
The FVP specific code that gets called after a cpu has been physically powered on after having been turned off or suspended earlier does not clear the PWRC.PWKUPR.WEN bit. Not doing so causes problems if: a cpu is suspended, woken from suspend, powered down through a cpu_off call & receives a spurious interrupt. Since the WEN bit is not cleared after the cpu woke up from suspend, the spurious wakeup will power the cpu on. Since the cpu_off call clears the jump address in the mailbox this spurious wakeup will cause the cpu to crash. This patch fixes this issue by clearing the WEN bit whenever a cpu is powered up. Change-Id: Ic91f5dffe1ed01d76bc7fc807acf0ecd3e38ce5b
-
Dan Handley authored
- Add instructions for contributing to ARM Trusted Firmware. - Update copyright text in all files to acknowledge contributors. Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
-
Sandrine Bailleux authored
This patch makes sure the C runtime environment is properly initialised before executing any C code. - Zero-initialise NOBITS sections (e.g. the bss section). - Relocate BL1 data from ROM to RAM. Change-Id: I0da81b417b2f0d1f7ef667cc5131b1e47e22571f
-
Sandrine Bailleux authored
- Check at link-time that bootloader images will fit in memory at run time and that they won't overlap each other. - Remove text and rodata orphan sections. - Define new linker symbols to remove the need for platform setup code to know the order of sections. - Reduce the size of the raw binary images by cutting some sections out of the disk image and allocating them at load time, whenever possible. - Rework alignment constraints on sections. - Remove unused linker symbols. - Homogenize linker symbols names across all BLs. - Add some comments in the linker scripts. Change-Id: I47a328af0ccc7c8ab47fcc0dc6e7dd26160610b9
-
- 27 Nov, 2013 1 commit
-
-
Sandrine Bailleux authored
On FVP platforms, for now it is assumed that the normal-world bootloader is already sitting in its final memory location. Therefore, BL2 doesn't need to load it and so it doesn't need to know the extents of the non-trusted DRAM. Change-Id: I33177ab43ca242edc8958f2fa8d994e7cf3e0843
-