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>
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
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
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
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
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
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
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
- Add instructions for contributing to ARM Trusted Firmware.
- Update copyright text in all files to acknowledge contributors.
Change-Id: I9311aac81b00c6c167d2f8c889aea403b84450e5
Achin Gupta
Jeenu Viswambharan
Harry Liebel
James Morrissey
Dan Handley
Ian Spray