- 17 Feb, 2014 3 commits
-
-
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
-
- 17 Jan, 2014 2 commits
-
-
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
-
- 05 Dec, 2013 2 commits
-
-
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
-
Dan Handley authored
- Add instructions for contributing to ARM Trusted Firmware. - Update copyright text in all files to acknowledge contributors. Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
-
- 14 Nov, 2013 1 commit
-
-
Harry Liebel authored
- The Foundation FVP only has one cluster and does not have CCI. Change-Id: If91e81ff72c52e448150089c4cfea3e4d6ae1232
-
- 25 Oct, 2013 1 commit
-
-
Achin Gupta authored
-