| 16948ae1 | 13-Apr-2015 |
Juan Castillo <juan.castillo@arm.com> |
Use numbers to identify images instead of names
The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in t
Use numbers to identify images instead of names
The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in the platform function plat_get_image_source(). For
a given image name, it returns the handle to the image file which
involves comparing images names. In addition, if the image is
packaged in a FIP, a name comparison is required to find the UUID
for the image. This method is not optimal.
This patch changes the interface between the generic and platform
code with regard to identifying images. The platform port must now
allocate a unique number (ID) for every image. The generic code will
use the image ID instead of the name to access its attributes.
As a result, the plat_get_image_source() function now takes an image
ID as an input parameter. The organisation of data structures within
the IO framework has been rationalised to use an image ID as an index
into an array which contains attributes of the image such as UUID and
name. This prevents the name comparisons.
A new type 'io_uuid_spec_t' has been introduced in the IO framework
to specify images identified by UUID (i.e. when the image is contained
in a FIP file). There is no longer need to maintain a look-up table
[iname_name --> uuid] in the io_fip driver code.
Because image names are no longer mandatory in the platform port, the
debug messages in the generic code will show the image identifier
instead of the file name. The platforms that support semihosting to
load images (i.e. FVP) must provide the file names as definitions
private to the platform.
The ARM platform ports and documentation have been updated accordingly.
All ARM platforms reuse the image IDs defined in the platform common
code. These IDs will be used to access other attributes of an image in
subsequent patches.
IMPORTANT: applying this patch breaks compatibility for platforms that
use TF BL1 or BL2 images or the image loading code. The platform port
must be updated to match the new interface.
Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
show more ...
|
| 452b7fa2 | 27-May-2015 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Remove FIRST_RESET_HANDLER_CALL build option
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required b
Remove FIRST_RESET_HANDLER_CALL build option
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required between the first and subsequent invocations
of the reset handling code, this should be detected at runtime.
On Juno, the platform reset handler is now always compiled in.
This means it is now executed twice on the cold boot path, first in
BL1 then in BL3-1, and it has the same behavior in both cases. It is
also executed twice on the warm boot path, first in BL1 then in the
PSCI entrypoint code.
Also update the documentation to reflect this change.
NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.
Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
show more ...
|
| c8f0c3f7 | 30-Apr-2015 |
Soby Mathew <soby.mathew@arm.com> |
FVP: Correct the PSYSR_WK bit width in platform_get_entrypoint
This patch fixes the incorrect bit width used to extract the wakeup
reason from PSYSR in platform_get_entrypoint() function. This defec
FVP: Correct the PSYSR_WK bit width in platform_get_entrypoint
This patch fixes the incorrect bit width used to extract the wakeup
reason from PSYSR in platform_get_entrypoint() function. This defect
did not have any observed regression.
Change-Id: I42652dbffc99f5bf50cc86a5878f28d730720d9a
show more ...
|
| a6695275 | 14-May-2015 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Always enable CCI coherency in BL3-1
On ARM standard platforms, snoop and DVM requests used to be enabled
for the primary CPU's cluster only in the first EL3 bootloader.
In other words, if the platf
Always enable CCI coherency in BL3-1
On ARM standard platforms, snoop and DVM requests used to be enabled
for the primary CPU's cluster only in the first EL3 bootloader.
In other words, if the platform reset into BL1 then CCI coherency
would be enabled by BL1 only, and not by BL3-1 again.
However, this doesn't cater for platforms that use BL3-1 along with
a non-TF ROM bootloader that doesn't enable snoop and DVM requests.
In this case, CCI coherency is never enabled.
This patch modifies the function bl31_early_platform_setup() on
ARM standard platforms so that it always enables snoop and DVM
requests regardless of whether earlier bootloader stages have
already done it. There is no harm in executing this code twice.
ARM Trusted Firmware Design document updated accordingly.
Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c
show more ...
|