This patch adds changes in ARM platform code to use new
version of image loading.
Following are the major changes:
-Refactor the signatures for bl31_early_platform_setup()
and arm_bl31_early_platform_setup() function to use
`void *` instead of `bl31_params_t *`.
-Introduce `plat_arm_bl2_handle_scp_bl2()` to handle
loading of SCP_BL2 image from BL2.
-Remove usage of reserve_mem() function from
`arm_bl1_early_platform_setup()`
-Extract BL32 & BL33 entrypoint info, from the link list
passed by BL2, in `arm_bl31_early_platform_setup()`
-Provides weak definitions for following platform functions:
plat_get_bl_image_load_info
plat_get_next_bl_params
plat_flush_next_bl_params
bl2_plat_handle_post_image_load
-Instantiates a descriptor array for ARM platforms
describing image and entrypoint information for
`SCP_BL2`, `BL31`, `BL32` and `BL33` images.
All the above changes are conditionally compiled using the
`LOAD_IMAGE_V2` flag.
Change-Id: I5e88b9785a3df1a2b2bbbb37d85b8e353ca61049
This patch adds changes in BL1 & BL2 to use new version
of image loading to load the BL images.
Following are the changes in BL1:
-Use new version of load_auth_image() to load BL2
-Modified `bl1_init_bl2_mem_layout()` to remove using
`reserve_mem()` and to calculate `bl2_mem_layout`.
`bl2_mem_layout` calculation now assumes that BL1 RW
data is at the top of the bl1_mem_layout, which is more
restrictive than the previous BL1 behaviour.
Following are the changes in BL2:
-The `bl2_main.c` is refactored and all the functions
for loading BLxx images are now moved to `bl2_image_load.c`
`bl2_main.c` now calls a top level `bl2_load_images()` to
load all the images that are applicable in BL2.
-Added new file `bl2_image_load_v2.c` that uses new version
of image loading to load the BL images in BL2.
All the above changes are conditionally compiled using the
`LOAD_IMAGE_V2` flag.
Change-Id: Ic6dcde5a484495bdc05526d9121c59fa50c1bf23
This patch adds capability to load BL images based on image
descriptors instead of hard coded way of loading BL images.
This framework is designed such that it can be readily adapted
by any BL stage that needs to load images.
In order to provide the above capability the following new
platform functions are introduced:
bl_load_info_t *plat_get_bl_image_load_info(void);
This function returns pointer to the list of images that the
platform has populated to load.
bl_params_t *plat_get_next_bl_params(void);
This function returns a pointer to the shared memory that the
platform has kept aside to pass trusted firmware related
information that next BL image needs.
void plat_flush_next_bl_params(void);
This function flushes to main memory all the params that
are passed to next image.
int bl2_plat_handle_post_image_load(unsigned int image_id)
This function can be used by the platforms to update/use
image information for given `image_id`.
`desc_image_load.c` contains utility functions which can be used
by the platforms to generate, load and executable, image list
based on the registered image descriptors.
This patch also adds new version of `load_image/load_auth_image`
functions in-order to achieve the above capability.
Following are the changes for the new version as compared to old:
- Refactor the signature and only keep image_id and image_info_t
arguments. Removed image_base argument as it is already passed
through image_info_t. Given that the BL image base addresses and
limit/size are already provided by the platforms, the meminfo_t
and entry_point_info arguments are not needed to provide/reserve
the extent of free memory for the given BL image.
- Added check for the image size against the defined max size.
This is needed because the image size could come from an
unauthenticated source (e.g. the FIP header).
To make this check, new member is added to the image_info_t
struct for identifying the image maximum size.
New flag `LOAD_IMAGE_V2` is added in the Makefile.
Default value is 0.
NOTE: `TRUSTED_BOARD_BOOT` is currently not supported when
`LOAD_IMAGE_V2` is enabled.
Change-Id: Ia7b643f4817a170d5a2fbf479b9bc12e63112e79
This patch implements CSS platform hook to support NODE_HW_STATE PSCI
API. The platform hook queries SCP to obtain CSS power state. Power
states returned by SCP are then converted to expected PSCI return codes.
Juno's PSCI operation structure is modified to use the CSS
implementation.
Change-Id: I4a5edac0e5895dd77b51398cbd78f934831dafc0
This patch adds a couple of missing forward declarations in plat_arm.h
so that all types it references are known within this header file,
without relying on previous header inclusions. This concerns the
meminfo and bl31_params structures, which are defined in bl_common.h.
Other external types referenced from plat_arm.h (e.g. mmap_region_t)
get declared through header files included by arm_plat.h so they
don't need forward declarations.
Change-Id: I471d5aa487919aff3fa979fc65e053f4f5b0ef32
This patch implements the support for SP_MIN in FVP. The SP_MIN platform
APIs are implemented and the required makefile support is added for FVP.
Change-Id: Id50bd6093eccbd5e38894e3fd2b20d5baeac5452
This patch adds AArch32 support for FVP and implements common platform APIs
like `plat_get_my_stack`, `plat_set_my_stack`, `plat_my_core_cos` for AArch32.
Only Multi Processor(MP) implementations of these functions are considered in
this patch. The ARM Standard platform layer helpers are implemented for
AArch32 and the common makefiles are modified to cater for both AArch64 and
AArch32 builds. Compatibility with the deprecated platform API is not
supported for AArch32.
Change-Id: Iad228400613eec91abf731b49e21a15bcf2833ea
Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to
`ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines
related to the translation tables but to the image size as well.
The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and
`PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h.
This way, ARM platforms no longer have to set their own values if
`ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values
otherwise. The common sizes have been set to the highest values used
for any of the current build configurations.
This is needed because in some build configurations some images are
running out of space. This way there is a common set of values known
to work for all of them and it can be optimized for each particular
platform if needed.
The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been
increased. This is needed because when memory optimisations are
disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and
`MAX_XLAT_TABLES` are higher. If in this situation the code is
compiled in debug mode and with "-O0", the code won't fit.
Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e
This patch reworks type usage in generic code, drivers and ARM platform files
to make it more portable. The major changes done with respect to
type usage are as listed below:
* Use uintptr_t for storing address instead of uint64_t or unsigned long.
* Review usage of unsigned long as it can no longer be assumed to be 64 bit.
* Use u_register_t for register values whose width varies depending on
whether AArch64 or AArch32.
* Use generic C types where-ever possible.
In addition to the above changes, this patch also modifies format specifiers
in print invocations so that they are AArch64/AArch32 agnostic. Only files
related to upcoming feature development have been reworked.
Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8
On ARM CSS platforms, the whole flash used to be mapped as executable.
This is not required, given that the flash is used to store the BL1
and FIP images and:
- The FIP is not executed in place, its images are copied to RAM
and executed from there.
- BL1 is executed in place from flash but only its code needs to be
mapped as executable and platform code takes care of re-mapping
BL1's read-only section as executable.
Therefore, this patch now maps the flash as non-executable by default
on these platforms. This increases security by restricting the
executable region to what is strictly needed.
This patch also adds some comments to clarify the memory mapping
attributes on these platforms.
Change-Id: I4db3c145508bea1f43fbe0f6dcd551e1aec1ecd3
The arm_setup_page_tables() function used to expect a single set of
addresses defining the extents of the whole read-only section, code
and read-only data mixed up, which was mapped as executable.
This patch changes this behaviour. arm_setup_page_tables() now
expects 2 separate sets of addresses:
- the extents of the code section;
- the extents of the read-only data section.
The code is mapped as executable, whereas the data is mapped as
execute-never. New #defines have been introduced to identify the
extents of the code and the read-only data section. Given that
all BL images except BL1 share the same memory layout and linker
script structure, these #defines are common across these images.
The slight memory layout differences in BL1 have been handled by
providing values specific to BL1.
Note that this patch also affects the Xilinx platform port, which
uses the arm_setup_page_tables() function. It has been updated
accordingly, such that the memory mappings on this platform are
unchanged. This is achieved by passing null values as the extents
of the read-only data section so that it is ignored. As a result,
the whole read-only section is still mapped as executable.
FixesARM-software/tf-issues#85
Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
This patch introduces a new header file: include/lib/utils.h.
Its purpose is to provide generic macros and helper functions that
are independent of any BL image, architecture, platform and even
not specific to Trusted Firmware.
For now, it contains only 2 macros: ARRAY_SIZE() and
IS_POWER_OF_TWO(). These were previously defined in bl_common.h and
xlat_tables.c respectively.
bl_common.h includes utils.h to retain compatibility for platforms
that relied on bl_common.h for the ARRAY_SIZE() macro. Upstream
platform ports that use this macro have been updated to include
utils.h.
Change-Id: I960450f54134f25d1710bfbdc4184f12c049a9a9
This patch introduces the arm_setup_page_tables() function to
set up page tables on ARM platforms. It replaces the
arm_configure_mmu_elx() functions and does the same thing except
that it doesn't enable the MMU at the end. The idea is to reduce
the amount of per-EL code that is generated by the C preprocessor
by splitting the memory regions definitions and page tables creation
(which is generic) from the MMU enablement (which is the only per-EL
configuration).
As a consequence, the call to the enable_mmu_elx() function has been
moved up into the plat_arch_setup() hook. Any other ARM standard
platforms that use the functions `arm_configure_mmu_elx()` must be
updated.
Change-Id: I6f12a20ce4e5187b3849a8574aac841a136de83d
A production ROM with TBB enabled must have the ability to boot test software
before a real ROTPK is deployed (e.g. manufacturing mode). Previously the
function plat_get_rotpk_info() must return a valid ROTPK for TBB to succeed.
This patch adds an additional bit `ROTPK_NOT_DEPLOYED` in the output `flags`
parameter from plat_get_rotpk_info(). If this bit is set, then the ROTPK
in certificate is used without verifying against the platform value.
FixesARM-software/tf-issues#381
Change-Id: Icbbffab6bff8ed76b72431ee21337f550d8fdbbb
Added plat_get_syscnt_freq2, which is a 32 bit variant of the 64 bit
plat_get_syscnt_freq. The old one has been flagged as deprecated.
Common code has been updated to use this new version. Porting guide
has been updated.
Change-Id: I9e913544926c418970972bfe7d81ee88b4da837e
This patch moves the definition for `plat_get_syscnt_freq()`
from arm_bl31_setup.c to arm_common.c. This could be useful
in case a delay timer needs to be installed based on the
generic timer in other BLs.
This patch also modifies the return type for this function
from `uint64_t` to `unsigned long long` within ARM and other
platform files.
Change-Id: Iccdfa811948e660d4fdcaae60ad1d700e4eda80d
It is up to the platform to implement the new plat_crash_print_regs macro to
report all relevant platform registers helpful for troubleshooting.
plat_crash_print_regs merges or calls previously defined plat_print_gic_regs
and plat_print_interconnect_regs macros for each existing platforms.
NOTE: THIS COMMIT REQUIRES ALL PLATFORMS THAT ENABLE THE `CRASH_REPORTING`
BUILD FLAG TO MIGRATE TO USE THE NEW `plat_crash_print_regs()` MACRO. BY
DEFAULT, `CRASH_REPORTING` IS ENABLED IN DEBUG BUILDS FOR ALL PLATFORMS.
Fixes: arm-software/tf-issues#373
Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
Previously, when building TF without SPD support, BL2 tried to load a
BL32 image from the FIP and fails to find one, which resulted on
warning messages on the console. Even if there is a BL32 image in the
FIP it shouldn't be loaded because there is no way to transfer
control to the Secure Payload without SPD support.
The Makefile has been modified to pass a define of the form
SPD_${SPD} to the source code the same way it's done for PLAT. The
define SPD_none is then used to undefine BL32_BASE when BL32 is not
used to prevent BL2 from trying to load a BL32 image and failing,
thus removing the warning messages mentioned above.
FixesARM-software/tf-issues#287
Change-Id: Ifeb6f1c26935efb76afd353fea88e87ba09e9658
This patch modifies the return type of the platform API
`plat_get_ns_image_entrypoint()` from `unsigned long` to
`uintptr_t` in accordance with the coding guidelines.
Change-Id: Icb4510ca98b706aa4d535fe27e203394184fb4ca
This patch adds support to program TrustZone protection on ARM platforms that
implement a DMC-500. arm_dmc_500.c has been added which implements the
arm_dmc_tzc_setup() function. This function relies on constants related to TZC
programming that are exported by each platform to program TrustZone protection
using the DMC-500 TrustZone controller driver. This function should be called
from plat_arm_security_setup() which is implemented by each platform.
Change-Id: I5400bdee9e4b29155fd11296a40693d512312f29
This patch adds support for non-volatile counter authentication to
the Authentication Module. This method consists of matching the
counter values provided in the certificates with the ones stored
in the platform. If the value from the certificate is lower than
the platform, the boot process is aborted. This mechanism protects
the system against rollback.
The TBBR CoT has been updated to include this method as part of the
authentication process. Two counters are used: one for the trusted
world images and another for the non trusted world images.
** NEW PLATFORM APIs (mandatory when TBB is enabled) **
int plat_get_nv_ctr(void *cookie, unsigned int *nv_ctr);
This API returns the non-volatile counter value stored
in the platform. The cookie in the first argument may be
used to select the counter in case the platform provides
more than one (i.e. TBSA compliant platforms must provide
trusted and non-trusted counters). This cookie is specified
in the CoT.
int plat_set_nv_ctr(void *cookie, unsigned int nv_ctr);
This API sets a new counter value. The cookie may be
used to select the counter to be updated.
An implementation of these new APIs for ARM platforms is also
provided. The values are obtained from the Trusted Non-Volatile
Counters peripheral. The cookie is used to pass the extension OID.
This OID may be interpreted by the platform to know which counter
must return. On Juno, The trusted and non-trusted counter values
have been tied to 31 and 223, respectively, and cannot be modified.
** IMPORTANT **
THIS PATCH BREAKS THE BUILD WHEN TRUSTED_BOARD_BOOT IS ENABLED. THE
NEW PLATFORM APIs INTRODUCED IN THIS PATCH MUST BE IMPLEMENTED IN
ORDER TO SUCCESSFULLY BUILD TF.
Change-Id: Ic943b76b25f2a37f490eaaab6d87b4a8b3cbc89a
This patch adds an option to the ARM common platforms to load BL31 in the
TZC secured DRAM instead of the default secure SRAM.
To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
If TSP is present, then setting this option also sets the TSP location
to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
To use this feature, BL2 platform code must map in the DRAM used by
BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
Currently, only the FVP BL2 platform code maps in this DRAM.
Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
Added a new platform porting function plat_panic_handler, to allow
platforms to handle unexpected error situations. It must be
implemented in assembly as it may be called before the C environment
is initialized. A default implementation is provided, which simply
spins.
Corrected all dead loops in generic code to call this function
instead. This includes the dead loop that occurs at the end of the
call to panic().
All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
been removed.
Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
This patch fixes inconsistencies in bl1_tbbr_image_descs[]
and miscellaneous fixes in Firmware Update code.
Following are the changes:
* As part of the original FWU changes, a `copied_size`
field was added to `image_info_t`. This was a subtle binary
compatibility break because it changed the size of the
`bl31_params_t` struct, which could cause problems if
somebody used different versions of BL2 or BL31, one with
the old `image_info_t` and one with the new version.
This patch put the `copied_size` within the `image_desc_t`.
* EXECUTABLE flag is now stored in `ep_info.h.attr` in place
of `image_info.h.attr`, associating it to an entrypoint.
* The `image_info.image_base` is only relevant for secure
images that are copied from non-secure memory into secure
memory. This patch removes initializing `image_base` for
non secure images in the bl1_tbbr_image_descs[].
* A new macro `SET_STATIC_PARAM_HEAD` is added for populating
bl1_tbbr_image_descs[].ep_info/image_info.h members statically.
The version, image_type and image attributes are now
populated using this new macro.
* Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct
usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c.
* Refactoring of code/macros related to SECURE and EXECUTABLE flags.
NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t`
OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr`
OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE
BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY.
Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d
`board_arm_def.h` contains multiple definitions of
`PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
memory usage depending upon the chosen build configuration. To ease
maintenance of these constants, this patch replaces their multiple
definitions with a single set of definitions that will work on all ARM
platforms.
Platforms can override the defaults with optimal values by enabling the
`ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
the Juno ADP port.
Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
future ARM platforms.
Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
The common topology description helper funtions and macros for
ARM Standard platforms assumed a dual cluster system. This is not
flexible enough to scale to multi cluster platforms. This patch does
the following changes for more flexibility in defining topology:
1. The `plat_get_power_domain_tree_desc()` definition is moved from
`arm_topology.c` to platform specific files, that is `fvp_topology.c`
and `juno_topology.c`. Similarly the common definition of the porting
macro `PLATFORM_CORE_COUNT` in `arm_def.h` is moved to platform
specific `platform_def.h` header.
2. The ARM common layer porting macros which were dual cluster specific
are now removed and a new macro PLAT_ARM_CLUSTER_COUNT is introduced
which must be defined by each ARM standard platform.
3. A new mandatory ARM common layer porting API
`plat_arm_get_cluster_core_count()` is introduced to enable the common
implementation of `arm_check_mpidr()` to validate MPIDR.
4. For the FVP platforms, a new build option `FVP_NUM_CLUSTERS` has been
introduced which allows the user to specify the cluster count to be
used to build the topology tree within Trusted Firmare. This enables
Trusted Firmware to be built for multi cluster FVP models.
Change-Id: Ie7a2e38e5661fe2fdb2c8fdf5641d2b2614c2b6b
The shared memory region on ARM platforms contains the mailboxes and,
on Juno, the payload area for communication with the SCP. This shared
memory may be configured as normal memory or device memory at build
time by setting the platform flag 'PLAT_ARM_SHARED_RAM_CACHED' (on
Juno, the value of this flag is defined by 'MHU_PAYLOAD_CACHED').
When set as normal memory, the platform port performs the corresponding
cache maintenance operations. From a functional point of view, this is
the equivalent of setting the shared memory as device memory, so there
is no need to maintain both options.
This patch removes the option to specify the shared memory as normal
memory on ARM platforms. Shared memory is always treated as device
memory. Cache maintenance operations are no longer needed and have
been replaced by data memory barriers to guarantee that payload and
MHU are accessed in the right order.
Change-Id: I7f958621d6a536dd4f0fa8768385eedc4295e79f
ARM Trusted Firmware supports 2 different interconnect peripheral
drivers: CCI and CCN. ARM platforms are implemented using either of the
interconnect peripherals.
This patch adds a layer of abstraction to help ARM platform ports to
choose the right interconnect driver and corresponding platform support.
This is as described below:
1. A set of ARM common functions have been implemented to initialise an
interconnect and for entering/exiting a cluster from coherency. These
functions are prefixed as "plat_arm_interconnect_". Weak definitions of
these functions have been provided for each type of driver.
2.`plat_print_interconnect_regs` macro used for printing CCI registers is
moved from a common arm_macros.S to cci_macros.S.
3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure
is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.
Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
Current code mandates loading of SCP_BL2/SCP_BL2U images for all
CSS platforms. On future ARM CSS platforms, the Application
Processor (AP) might not need to load these images. So, these
items can be removed from the FIP on those platforms.
BL2 tries to load SCP_BL2/SCP_BL2U images if their base
addresses are defined causing boot error if the images are not
found in FIP.
This change adds a make flag `CSS_LOAD_SCP_IMAGES` which if set
to `1` does:
1. Adds SCP_BL2, SCP_BL2U images to FIP.
2. Defines the base addresses of these images so that AP loads
them.
And vice-versa if it is set to `0`. The default value is set to
`1`.
Change-Id: I5abfe22d5dc1e9d80d7809acefc87b42a462204a
Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address
for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To
cater for future ARM platforms this is made platform specific.
Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made
platform specific.
Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
Functions to configure the MMU in S-EL1 and EL3 on ARM platforms
expect each platform to export its memory map in the `plat_arm_mmap`
data structure. This approach does not scale well in case the memory
map cannot be determined until runtime. To cater for this possibility,
this patch introduces the plat_arm_get_mmap() API. It returns a
reference to the `plat_arm_mmap` by default but can be overridden
by a platform if required.
Change-Id: Idae6ad8fdf40cdddcd8b992abc188455fa047c74
Each ARM Compute Subsystem based platform implements a System Security
Control (SSC) Registers Unit. The SSC_VERSION register inside it carries
information to identify the platform. This enables ARM Trusted Firmware
to compile in support for multiple ARM platforms and choose one at
runtime. This patch adds macros to enable access to this register.
Each platform is expected to export its PART_NUMBER separately.
Additionally, it also adds juno part number.
Change-Id: I2b1d5f5b65a9c7b76c6f64480cc7cf0aef019422
This patch moves the definition of some macros used only on
ARM platforms from common headers to platform specific headers.
It also forces all ARM standard platforms to have distinct
definitions (even if they are usually the same).
1. `PLAT_ARM_TZC_BASE` and `PLAT_ARM_NSTIMER_FRAME_ID` have been
moved from `css_def.h` to `platform_def.h`.
2. `MHU_BASE` used in CSS platforms is moved from common css_def.h
to platform specific header `platform_def.h` on Juno and
renamed as `PLAT_ARM_MHU_BASE`.
3. To cater for different sizes of BL images, new macros like
`PLAT_ARM_MAX_BL31_SIZE` have been created for each BL image. All
ARM platforms need to define them for each image.
Change-Id: I9255448bddfad734b387922aa9e68d2117338c3f
The debug prints used to debug translation table setup in xlat_tables.c
used the `printf()` standard library function instead of the stack
optimized `tf_printf()` API. DEBUG_XLAT_TABLE option was used to enable
debug logs within xlat_tables.c and it configured a much larger stack
size for the platform in case it was enabled. This patch modifies these
debug prints within xlat_tables.c to use tf_printf() and modifies the format
specifiers to be compatible with tf_printf(). The debug prints are now enabled
if the VERBOSE prints are enabled in Trusted Firmware via LOG_LEVEL build
option.
The much larger stack size definition when DEBUG_XLAT_TABLE is defined
is no longer required and the platform ports are modified to remove this
stack size definition.
Change-Id: I2f7d77ea12a04b827fa15e2adc3125b1175e4c23
Use the new __deprecated macro from the generic cdefs header and remove
the deprecated __warn_deprecated.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
The current FWU_SMC_UPDATE_DONE implementation incorrectly passes
an unused framework cookie through to the 1st argument in the
platform function `bl1_plat_fwu_done`. The intent is to allow
the SMC caller to pass a cookie through to this function.
This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller
through to `bl1_plat_fwu_done`. The argument names are updated
for clarity.
Upstream platforms currently do not use this argument so no
impact is expected.
Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
This patch removes the dash character from the image name, to
follow the image terminology in the Trusted Firmware Wiki page:
https://github.com/ARM-software/arm-trusted-firmware/wiki
Changes apply to output messages, comments and documentation.
non-ARM platform files have been left unmodified.
Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
This patch replaces all references to the SCP Firmware (BL0, BL30,
BL3-0, bl30) with the image terminology detailed in the TF wiki
(https://github.com/ARM-software/arm-trusted-firmware/wiki):
BL0 --> SCP_BL1
BL30, BL3-0 --> SCP_BL2
bl30 --> scp_bl2
This change affects code, documentation, build system, tools and
platform ports that load SCP firmware. ARM plaforms have been
updated to the new porting API.
IMPORTANT: build option to specify the SCP FW image has changed:
BL30 --> SCP_BL2
IMPORTANT: This patch breaks compatibility for platforms that use BL2
to load SCP firmware. Affected platforms must be updated as follows:
BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
BL30_BASE --> SCP_BL2_BASE
bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
This patch adds support for Firmware update in BL2U for ARM
platforms such that TZC initialization is performed on all
ARM platforms and (optionally) transfer of SCP_BL2U image on
ARM CSS platforms.
BL2U specific functions are added to handle early_platform and
plat_arch setup. The MMU is configured to map in the BL2U
code/data area and other required memory.
Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
The Firmware Update (FWU) feature needs support for an optional
secure world image, BL2U, to allow additional secure world
initialization required by FWU, for example DDR initialization.
This patch adds generic framework support to create BL2U.
NOTE: A platform makefile must supply additional `BL2U_SOURCES`
to build the bl2u target. A subsequent patch adds bl2u
support for ARM platforms.
Change-Id: If2ce036199bb40b39b7f91a9332106bcd4e25413
This patch adds Firmware Update support for ARM platforms.
New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
platform specific Firmware update code.
BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
authenticating NS_BL2U image(For both FVP and JUNO platform).
Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
Firmware update(a.k.a FWU) feature is part of the TBB architecture.
BL1 is responsible for carrying out the FWU process if platform
specific code detects that it is needed.
This patch adds support for FWU feature support in BL1 which is
included by enabling `TRUSTED_BOARD_BOOT` compile time flag.
This patch adds bl1_fwu.c which contains all the core operations
of FWU, which are; SMC handler, image copy, authentication, execution
and resumption. It also adds bl1.h introducing #defines for all
BL1 SMCs.
Following platform porting functions are introduced:
int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size,
unsigned int flags);
This function can be used to add platform specific memory checks
for the provided base/size for the given security state.
The weak definition will invoke `assert()` and return -ENOMEM.
__dead2 void bl1_plat_fwu_done(void *cookie, void *reserved);
This function can be used to initiate platform specific procedure
to mark completion of the FWU process.
The weak definition waits forever calling `wfi()`.
plat_bl1_common.c contains weak definitions for above functions.
FWU process starts when platform detects it and return the image_id
other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in
`bl1_main()`.
NOTE: User MUST provide platform specific real definition for
bl1_plat_mem_check() in order to use it for Firmware update.
Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed
As of now BL1 loads and execute BL2 based on hard coded information
provided in BL1. But due to addition of support for upcoming Firmware
Update feature, BL1 now require more flexible approach to load and
run different images using information provided by the platform.
This patch adds new mechanism to load and execute images based on
platform provided image id's. BL1 now queries the platform to fetch
the image id of the next image to be loaded and executed. In order
to achieve this, a new struct image_desc_t was added which holds the
information about images, such as: ep_info and image_info.
This patch introduces following platform porting functions:
unsigned int bl1_plat_get_next_image_id(void);
This is used to identify the next image to be loaded
and executed by BL1.
struct image_desc *bl1_plat_get_image_desc(unsigned int image_id);
This is used to retrieve the image_desc for given image_id.
void bl1_plat_set_ep_info(unsigned int image_id,
struct entry_point_info *ep_info);
This function allows platforms to update ep_info for given
image_id.
The plat_bl1_common.c file provides default weak implementations of
all above functions, the `bl1_plat_get_image_desc()` always return
BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return
BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns.
These functions gets compiled into all BL1 platforms by default.
Platform setup in BL1, using `bl1_platform_setup()`, is now done
_after_ the initialization of authentication module. This change
provides the opportunity to use authentication while doing the
platform setup in BL1.
In order to store secure/non-secure context, BL31 uses percpu_data[]
to store context pointer for each core. In case of BL1 only the
primary CPU will be active hence percpu_data[] is not required to
store the context pointer.
This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to
store the context and context pointers respectively. It also also
re-defines cm_get_context() and cm_set_context() for BL1 in
bl1/bl1_context_mgmt.c.
BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime
environment, to support resuming execution from a previously saved
context.
NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS
NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE
THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()`
INSTEAD TO MAINTAIN EXISTING BEHAVIOUR.
Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
This patch overrides the default weak definition of
`bl31_plat_runtime_setup()` for ARM Standard platforms to
specify a BL31 runtime console. ARM Standard platforms are
now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
`PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
by `arm_bl31_plat_runtime_setup()` to initialize the runtime
console.
The system suspend resume helper `arm_system_pwr_domain_resume()`
is fixed to initialize the runtime console rather than the boot
console on resumption from system suspend.
FixesARM-software/tf-issues#220
Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
It is not ideal for BL31 to continue to use boot console at
runtime which could be potentially uninitialized. This patch
introduces a new optional platform porting API
`bl31_plat_runtime_setup()` which allows the platform to perform
any BL31 runtime setup just prior to BL31 exit during cold boot.
The default weak implementation of this function will invoke
`console_uninit()` which will suppress any BL31 runtime logs.
On the ARM Standard platforms, there is an anomaly that
the boot console will be reinitialized on resumption from
system suspend in `arm_system_pwr_domain_resume()`. This
will be resolved in the following patch.
NOTE: The default weak definition of `bl31_plat_runtime_setup()`
disables the BL31 console. To print the BL31 runtime
messages, platforms must override this API and initialize a
runtime console.
FixesARM-software/tf-issues#328
Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
separate drivers instead of providing a single driver that can work on both
versions of the GIC architecture. These drivers correspond to the following
software use cases:
1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
e.g. GIC-400
2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
3. A deprecated GICv3 driver that operates in legacy mode. This driver can
operate only in the GICv2 mode in the secure world. On a GICv3 system, this
driver allows normal world to run in either GICv3 mode (asymmetric mode)
or in the GICv2 mode. Both modes of operation are deprecated on GICv3
systems.
ARM platforms implement both versions of the GIC architecture. This patch adds a
layer of abstraction to help ARM platform ports chose the right GIC driver and
corresponding platform support. This is as described below:
1. A set of ARM common functions have been introduced to initialise the GIC and
the driver during cold and warm boot. These functions are prefixed as
"plat_arm_gic_". Weak definitions of these functions have been provided for
each type of driver.
2. Each platform includes the sources that implement the right functions
directly into the its makefile. The FVP can be instantiated with different
versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
to specify which of the three drivers should be included in the build.
3. A list of secure interrupts has to be provided to initialise each of the
three GIC drivers. For GIC v3.0 the interrupt ids have to be further
categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
types are merged and treated as Group 0 interrupts.
The two lists of interrupts are exported from the platform_def.h. The lists
are constructed by adding a list of board specific interrupt ids to a list of
ids common to all ARM platforms and Compute sub-systems.
This patch also makes some fields of `arm_config` data structure in FVP redundant
and these unused fields are removed.
Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
This patch adds platform helpers for the new GICv2 and GICv3 drivers in
plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
file in their build according to the GIC driver to be used. The existing
plat_gic.c is only meant for the legacy GIC driver.
In the case of ARM platforms, the major changes are as follows:
1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU
interface register values has been modified to detect the type of CPU
interface being used (System register or memory mappped interface) before
using the right interface to print the registers.
2. The power management helper function that is called after a core is powered
up has been further refactored. This is to highlight that the per-cpu
distributor interface should be initialised only when the core was originally
powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API
was used.
3. In the case of CSS platforms, the system power domain restore helper
`arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish`
handler as the system power domain is always expected to be initialized when
the `on_finish` handler is invoked.
Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
This patch fixes several issues with the SP804 delay timer on FVP:
* By default, the SP804 dual timer on FVP runs at 32 KHz. In order
to run the timer at 35 MHz (as specified in the FVP user manual)
the Overwrite bit in the SP810 control register must be set.
* The CLKMULT and CLKDIV definitions are mixed up:
delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz)
From the delay function:
delta_us = (delta * ops->clk_mult) / ops->clk_div;
Matching both expressions:
1 / f(MHz) = ops->clk_mult / ops->clk_div
And consequently:
f(MHz) = ops->clk_div / ops->clk_mult
Which, for a 35 MHz timer, translates to:
ops->clk_div = 35
ops->clk_mult = 1
* The comment in the delay timer header file has been corrected:
The ratio of the multiplier and the divider is the clock period
in microseconds, not the frequency.
Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
This patch adds watchdog support on ARM platforms (FVP and Juno).
A secure instance of SP805 is used as Trusted Watchdog. It is
entirely managed in BL1, being enabled in the early platform setup
hook and disabled in the exit hook. By default, the watchdog is
enabled in every build (even when TBB is disabled).
A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
has been introduced to allow the user to disable the watchdog at
build time. This feature may be used for testing or debugging
purposes.
Specific error handlers for Juno and FVP are also provided in this
patch. These handlers will be called after an image load or
authentication error. On FVP, the Table of Contents (ToC) in the FIP
is erased. On Juno, the corresponding error code is stored in the
V2M Non-Volatile flags register. In both cases, the CPU spins until
a watchdog reset is generated after 256 seconds (as specified in
the TBBR document).
Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
This patch adds ARM specific OIDs which will be used to extract
the extension data from the certificates. These OIDs are arranged
as a subtree whose root node has been specifically allocated for
ARM Ltd.
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) 4128 }
Change-Id: Ice20b3c8a31ddefe9102f3bd42f7429986f3ac34
FVP and Juno platforms include a NOR flash memory to store and
load the FIP, the kernel or a ramdisk. This NOR flash is arranged
as 2 x 16 bit flash devices and can be programmed using CFI
standard commands.
This patch provides a basic API to write single 32 bit words of
data into the NOR flash. Functions to lock/unlock blocks against
erase or write operations are also provided.
Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.
Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.
The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.
The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.
The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.
This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.
Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
This patch changes the build time behaviour when using deprecated API within
Trusted Firmware. Previously the use of deprecated APIs would only trigger a
build warning (which was always treated as a build error), when
WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always
trigger a build time warning. Whether this warning is treated as error or not
is determined by the build flag ERROR_DEPRECATED which is disabled by default.
When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or
inclusion of deprecated headers will result in a build error.
Also the deprecated context management helpers in context_mgmt.c are now
conditionally compiled depending on the value of ERROR_DEPRECATED flag
so that the APIs themselves do not result in a build error when the
ERROR_DEPRECATED flag is set.
NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to
using ERROR_DEPRECATED, otherwise deprecated API usage will no longer
trigger a build error.
Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a
This patch fixes a compilation issue for platforms that are aligned to ARM
Standard platforms and include the `plat_arm.h` header in their platform port.
The compilation would fail for such a platform because `xlat_tables.h` which
has the definition for `mmap_region_t` is not included in `plat_arm.h`. This
patch fixes this by including `xlat_tables.h` in `plat_arm.h` header.
FixesARM-Software/tf-issues#318
Change-Id: I75f990cfb4078b3996fc353c8cd37c9de61d555e
This patch adds the capability to power down at system power domain level
on Juno via the PSCI SYSTEM SUSPEND API. The CSS power management helpers
are modified to add support for power management operations at system
power domain level. A new helper for populating `get_sys_suspend_power_state`
handler in plat_psci_ops is defined. On entering the system suspend state,
the SCP powers down the SYSTOP power domain on the SoC and puts the memory
into retention mode. On wakeup from the power down, the system components
on the CSS will be reinitialized by the platform layer and the PSCI client
is responsible for restoring the context of these system components.
According to PSCI Specification, interrupts targeted to cores in PSCI CPU
SUSPEND should be able to resume it. On Juno, when the system power domain
is suspended, the GIC is also powered down. The SCP resumes the final core
to be suspend when an external wake-up event is received. But the other
cores cannot be woken up by a targeted interrupt, because GIC doesn't
forward these interrupts to the SCP. Due to this hardware limitation,
we down-grade PSCI CPU SUSPEND requests targeted to the system power domain
level to cluster power domain level in `juno_validate_power_state()`
and the CSS default `plat_arm_psci_ops` is overridden in juno_pm.c.
A system power domain resume helper `arm_system_pwr_domain_resume()` is
defined for ARM standard platforms which resumes/re-initializes the
system components on wakeup from system suspend. The security setup also
needs to be done on resume from system suspend, which means
`plat_arm_security_setup()` must now be included in the BL3-1 image in
addition to previous BL images if system suspend need to be supported.
Change-Id: Ie293f75f09bad24223af47ab6c6e1268f77bcc47
This patch implements the necessary topology changes for supporting
system power domain on CSS platforms. The definition of PLAT_MAX_PWR_LVL and
PLAT_NUM_PWR_DOMAINS macros are removed from arm_def.h and are made platform
specific. In addition, the `arm_power_domain_tree_desc[]` and
`arm_pm_idle_states[]` are modified to support the system power domain
at level 2. With this patch, even though the power management operations
involving the system power domain will not return any error, the platform
layer will silently ignore any operations to the power domain. The actual
power management support for the system power domain will be added later.
Change-Id: I791867eded5156754fe898f9cdc6bba361e5a379
This patch adds an optional API to the platform port:
void plat_error_handler(int err) __dead2;
The platform error handler is called when there is a specific error
condition after which Trusted Firmware cannot continue. While panic()
simply prints the crash report (if enabled) and spins, the platform
error handler can be used to hand control over to the platform port
so it can perform specific bookeeping or post-error actions (for
example, reset the system). This function must not return.
The parameter indicates the type of error using standard codes from
errno.h. Possible errors reported by the generic code are:
-EAUTH : a certificate or image could not be authenticated
(when Trusted Board Boot is enabled)
-ENOENT : the requested image or certificate could not be found
or an IO error was detected
-ENOMEM : resources exhausted. Trusted Firmware does not use
dynamic memory, so this error is usually an indication
of an incorrect array size
A default weak implementation of this function has been provided.
It simply implements an infinite loop.
Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3
This patch does the following reorganization to psci power management (PM)
handler setup for ARM standard platform ports :
1. The mailbox programming required during `plat_setup_psci_ops()` is identical
for all ARM platforms. Hence the implementation of this API is now moved
to the common `arm_pm.c` file. Each ARM platform now must define the
PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
as ARM_SHARED_RAM_BASE.
2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
exported via `plat_arm_psci_pm_ops`. This allows the common implementation
of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
In the case of CSS platforms, a default weak implementation of the same is
provided in `css_pm.c` which can be overridden by each CSS platform.
3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
made library functions and a new header file `css_pm.h` is added to export
these generic PM handlers. This allows the platform to reuse the
adequate CSS PM handlers and redefine others which need to be customized
when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.
Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
This patch updates ARM platform ports to use the new unified bakery locks
API. The caller does not have to use a different bakery lock API depending upon
the value of the USE_COHERENT_MEM build option.
NOTE: THIS PATCH CAN BE USED AS A REFERENCE TO UPDATE OTHER PLATFORM PORTS.
Change-Id: I1b26afc7c9a9808a6040eb22f603d30192251da7
On Juno and FVP platforms, the Non-Secure System timer corresponds
to frame 1. However, this is a platform-specific decision and it
shouldn't be hard-coded. Hence, this patch introduces
PLAT_ARM_NSTIMER_FRAME_ID which should be used by all ARM platforms
to specify the correct non-secure timer frame.
Change-Id: I6c3a905d7d89200a2f58c20ce5d1e1d166832bba
This patch replaces the `ARM_TZC_BASE` constant with `PLAT_ARM_TZC_BASE` to
support different TrustZone Controller base addresses across ARM platforms.
Change-Id: Ie4e1c7600fd7a5875323c7cc35e067de0c6ef6dd
ARM TF configures all interrupts as non-secure except those which
are present in irq_sec_array. This patch updates the irq_sec_array
with the missing secure interrupts for ARM platforms.
It also updates the documentation to be inline with the latest
implementation.
FixesARM-software/tf-issues#312
Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
This patch implements the platform power managment handler to verify
non secure entrypoint for ARM platforms. The handler ensures that the
entry point specified by the normal world during CPU_SUSPEND, CPU_ON
or SYSTEM_SUSPEND PSCI API is a valid address within the non secure
DRAM.
Change-Id: I4795452df99f67a24682b22f0e0967175c1de429
Since there is a unique warm reset entry point, the FVP and Juno
port can use a single mailbox instead of maintaining one per core.
The mailbox gets programmed only once when plat_setup_psci_ops()
is invoked during PSCI initialization. This means mailbox is not
zeroed out during wakeup.
Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
This patch adds support to the Juno and FVP ports for composite power states
with both the original and extended state-id power-state formats. Both the
platform ports use the recommended state-id encoding as specified in
Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
ARM_RECOM_STATE_ID_ENC is used to include this support.
By default, to maintain backwards compatibility, the original power state
parameter format is used and the state-id field is expected to be zero.
Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
This patch migrates ARM reference platforms, Juno and FVP, to the new platform
API mandated by the new PSCI power domain topology and composite power state
frameworks. The platform specific makefiles now exports the build flag
ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.
Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
This patch defines deprecated platform APIs to enable Trusted
Firmware components like Secure Payload and their dispatchers(SPD)
to continue to build and run when platform compatibility is disabled.
This decouples the migration of platform ports to the new platform API
from SPD and enables them to be migrated independently. The deprecated
platform APIs defined in this patch are : platform_get_core_pos(),
platform_get_stack() and platform_set_stack().
The patch also deprecates MPIDR based context management helpers like
cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context().
A mechanism to deprecate APIs and identify callers of these APIs during
build is introduced, which is controlled by the build flag WARN_DEPRECATED.
If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be
flagged either as a link error for assembly files or compile time warning
for C files during build.
Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613
This commit does the switch to the new PSCI framework implementation replacing
the existing files in PSCI folder with the ones in PSCI1.0 folder. The
corresponding makefiles are modified as required for the new implementation.
The platform.h header file is also is switched to the new one
as required by the new frameworks. The build flag ENABLE_PLAT_COMPAT defaults
to 1 to enable compatibility layer which let the existing platform ports to
continue to build and run with minimal changes.
The default weak implementation of platform_get_core_pos() is now removed from
platform_helpers.S and is provided by the compatibility layer.
Note: The Secure Payloads and their dispatchers still use the old platform
and framework APIs and hence it is expected that the ENABLE_PLAT_COMPAT build
flag will remain enabled in subsequent patch. The compatibility for SPDs using
the older APIs on platforms migrated to the new APIs will be added in the
following patch.
Change-Id: I18c51b3a085b564aa05fdd98d11c9f3335712719
The new PSCI topology framework and PSCI extended State framework introduces
a breaking change in the platform port APIs. To ease the migration of the
platform ports to the new porting interface, a compatibility layer is
introduced which essentially defines the new platform API in terms of the
old API. The old PSCI helpers to retrieve the power-state, its associated
fields and the highest coordinated physical OFF affinity level of a core
are also implemented for compatibility. This allows the existing
platform ports to work with the new PSCI framework without significant
rework. This layer will be enabled by default once the switch to the new
PSCI framework is done and is controlled by the build flag ENABLE_PLAT_COMPAT.
Change-Id: I4b17cac3a4f3375910a36dba6b03d8f1700d07e3
There used to be 2 warm reset entry points:
- the "on finisher", for when the core has been turned on using a
PSCI CPU_ON call;
- the "suspend finisher", entered upon resumption from a previous
PSCI CPU_SUSPEND call.
The appropriate warm reset entry point used to be programmed into the
mailboxes by the power management hooks.
However, it is not required to provide this information to the PSCI
entry point code, as it can figure it out by itself. By querying affinity
info state, a core is able to determine on which execution path it is.
If the state is ON_PENDING then it means it's been turned on else
it is resuming from suspend.
This patch unifies the 2 warm reset entry points into a single one:
psci_entrypoint(). The patch also implements the necessary logic
to distinguish between the 2 types of warm resets in the power up
finisher.
The plat_setup_psci_ops() API now takes the
secure entry point as an additional parameter to enable the platforms
to configure their mailbox. The platform hooks `pwr_domain_on`
and `pwr_domain_suspend` no longer take secure entry point as
a parameter.
Change-Id: I7d1c93787b54213aefdbc046b8cd66a555dfbfd9
The state-id field in the power-state parameter of a CPU_SUSPEND call can be
used to describe composite power states specific to a platform. The current PSCI
implementation does not interpret the state-id field. It relies on the target
power level and the state type fields in the power-state parameter to perform
state coordination and power management operations. The framework introduced
in this patch allows the PSCI implementation to intepret generic global states
like RUN, RETENTION or OFF from the State-ID to make global state coordination
decisions and reduce the complexity of platform ports. It adds support to
involve the platform in state coordination which facilitates the use of
composite power states and improves the support for entering standby states
at multiple power domains.
The patch also includes support for extended state-id format for the power
state parameter as specified by PSCIv1.0.
The PSCI implementation now defines a generic representation of the power-state
parameter. It depends on the platform port to convert the power-state parameter
(possibly encoding a composite power state) passed in a CPU_SUSPEND call to this
representation via the `validate_power_state()` plat_psci_ops handler. It is an
array where each index corresponds to a power level. Each entry contains the
local power state the power domain at that power level could enter.
The meaning of the local power state values is platform defined, and may vary
between levels in a single platform. The PSCI implementation constrains the
values only so that it can classify the state as RUN, RETENTION or OFF as
required by the specification:
* zero means RUN
* all OFF state values at all levels must be higher than all RETENTION
state values at all levels
* the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values
to the framework
The platform also must define the macros PLAT_MAX_RET_STATE and
PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power
domains have been requested to enter a retention or power down state. The PSCI
implementation does not interpret the local power states defined by the
platform. The only constraint is that the PLAT_MAX_RET_STATE <
PLAT_MAX_OFF_STATE.
For a power domain tree, the generic implementation maintains an array of local
power states. These are the states requested for each power domain by all the
cores contained within the domain. During a request to place multiple power
domains in a low power state, the platform is passed an array of requested
power-states for each power domain through the plat_get_target_pwr_state()
API. It coordinates amongst these states to determine a target local power
state for the power domain. A default weak implementation of this API is
provided in the platform layer which returns the minimum of the requested
power-states back to the PSCI state coordination.
Finally, the plat_psci_ops power management handlers are passed the target
local power states for each affected power domain using the generic
representation described above. The platform executes operations specific to
these target states.
The platform power management handler for placing a power domain in a standby
state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for
placing a core power domain into a standby or retention state should now be
used to only place the core power domain in a standby or retention state.
The extended state-id power state format can be enabled by setting the
build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default.
Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c
This patch removes the assumption in the current PSCI implementation that MPIDR
based affinity levels map directly to levels in a power domain tree. This
enables PSCI generic code to support complex power domain topologies as
envisaged by PSCIv1.0 specification. The platform interface for querying
the power domain topology has been changed such that:
1. The generic PSCI code does not generate MPIDRs and use them to query the
platform about the number of power domains at a particular power level. The
platform now provides a description of the power domain tree on the SoC
through a data structure. The existing platform APIs to provide the same
information have been removed.
2. The linear indices returned by plat_core_pos_by_mpidr() and
plat_my_core_pos() are used to retrieve core power domain nodes from the
power domain tree. Power domains above the core level are accessed using a
'parent' field in the tree node descriptors.
The platform describes the power domain tree in an array of 'unsigned
char's. The first entry in the array specifies the number of power domains at
the highest power level implemented in the system. Each susbsequent entry
corresponds to a power domain and contains the number of power domains that are
its direct children. This array is exported to the generic PSCI implementation
via the new `plat_get_power_domain_tree_desc()` platform API.
The PSCI generic code uses this array to populate its internal power domain tree
using the Breadth First Search like algorithm. The tree is split into two
arrays:
1. An array that contains all the core power domain nodes
2. An array that contains all the other power domain nodes
A separate array for core nodes allows certain core specific optimisations to
be implemented e.g. remove the bakery lock, re-use per-cpu data framework for
storing some information.
Entries in the core power domain array are allocated such that the
array index of the domain is equal to the linear index returned by
plat_core_pos_by_mpidr() and plat_my_core_pos() for the MPIDR
corresponding to that domain. This relationship is key to be able to use
an MPIDR to find the corresponding core power domain node, traverse to higher
power domain nodes and index into arrays that contain core specific
information.
An introductory document has been added to briefly describe the new interface.
Change-Id: I4b444719e8e927ba391cae48a23558308447da13
This patch introduces new platform APIs and context management helper APIs
to support the new topology framework based on linear core position. This
framework will be introduced in the follwoing patch and it removes the
assumption that the MPIDR based affinity levels map directly to levels
in a power domain tree. The new platforms APIs and context management
helpers based on core position are as described below:
* plat_my_core_pos() and plat_core_pos_by_mpidr()
These 2 new mandatory platform APIs are meant to replace the existing
'platform_get_core_pos()' API. The 'plat_my_core_pos()' API returns the
linear index of the calling core and 'plat_core_pos_by_mpidr()' returns
the linear index of a core specified by its MPIDR. The latter API will also
validate the MPIDR passed as an argument and will return an error code (-1)
if an invalid MPIDR is passed as the argument. This enables the caller to
safely convert an MPIDR of another core to its linear index without querying
the PSCI topology tree e.g. during a call to PSCI CPU_ON.
Since the 'plat_core_pos_by_mpidr()' API verifies an MPIDR, which is always
platform specific, it is no longer possible to maintain a default implementation
of this API. Also it might not be possible for a platform port to verify an
MPIDR before the C runtime has been setup or the topology has been initialized.
This would prevent 'plat_core_pos_by_mpidr()' from being callable prior to
topology setup. As a result, the generic Trusted Firmware code does not call
this API before the topology setup has been done.
The 'plat_my_core_pos' API should be able to run without a C runtime.
Since this API needs to return a core position which is equal to the one
returned by 'plat_core_pos_by_mpidr()' API for the corresponding MPIDR,
this too cannot have default implementation and is a mandatory API for
platform ports. These APIs will be implemented by the ARM reference platform
ports later in the patch stack.
* plat_get_my_stack() and plat_set_my_stack()
These APIs are the stack management APIs which set/return stack addresses
appropriate for the calling core. These replace the 'platform_get_stack()' and
'platform_set_stack()' APIs. A default weak MP version and a global UP version
of these APIs are provided for the platforms.
* Context management helpers based on linear core position
A set of new context management(CM) helpers viz cm_get_context_by_index(),
cm_set_context_by_index(), cm_init_my_context() and cm_init_context_by_index()
are defined which are meant to replace the old helpers which took MPIDR
as argument. The old CM helpers are implemented based on the new helpers to
allow for code consolidation and will be deprecated once the switch to the new
framework is done.
Change-Id: I89758632b370c2812973a4b2efdd9b81a41f9b69
As per Section 4.2.2. in the PSCI specification, the term "affinity"
is used in the context of describing the hierarchical arrangement
of cores. This often, but not always, maps directly to the processor
power domain topology of the system. The current PSCI implementation
assumes that this is always the case i.e. MPIDR based levels of
affinity always map to levels in a power domain topology tree.
This patch is the first in a series of patches which remove this
assumption. It removes all occurences of the terms "affinity
instances and levels" when used to describe the power domain
topology. Only the terminology is changed in this patch. Subsequent
patches will implement functional changes to remove the above
mentioned assumption.
Change-Id: Iee162f051b228828310610c5a320ff9d31009b4e
This patch creates a copy of the existing PSCI files and related psci.h and
platform.h header files in a new `PSCI1.0` directory. The changes for the
new PSCI power domain topology and extended state-ID frameworks will be
added incrementally to these files. This incremental approach will
aid in review and in understanding the changes better. Once all the
changes have been introduced, these files will replace the existing PSCI
files.
Change-Id: Ibb8a52e265daa4204e34829ed050bddd7e3316ff
If Trusted Firmware is built with optimizations disabled (-O0), the
linker throws the following error:
undefined reference to 'xxx'
Where 'xxx' is a raw inline function defined in a header file. The
reason is that, with optimizations disabled, GCC may decide to skip
the inlining. If that is the case, an external definition to the
compilation unit must be provided. Because no external definition
is present, the linker throws the error.
This patch fixes the problem by declaring the following inline
functions static, so the internal definition is used:
inline void soc_css_security_setup(void)
inline const arm_config_t *get_arm_config(void)
Change-Id: Id650d6be1b1396bdb48af1ac8a4c7900d212e95f
This patch changes the type of the base address parameter in the
ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The
uintptr_t type allows coverage of the whole memory space and to
perform arithmetic operations on the addresses. ARM platform code
has also been updated to use uintptr_t as GIC base address in the
configuration.
FixesARM-software/tf-issues#214
Change-Id: I1b87daedadcc8b63e8f113477979675e07d788f1
The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.
Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto module and the image parser module to
authenticate the images in the Chain of Trust.
A new function 'load_auth_image()' has been implemented. When TBB
is enabled, this function will call the authentication module to
authenticate parent images following the CoT up to the root of
trust to finally load and authenticate the requested image.
The platform is responsible for picking up the right makefiles to
build the corresponding cryptographic and image parser libraries.
ARM platforms use the mbedTLS based libraries.
The platform may also specify what key algorithm should be used
to sign the certificates. This is done by declaring the 'KEY_ALG'
variable in the platform makefile. FVP and Juno use ECDSA keys.
On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
each to accommodate the ECDSA code.
REMOVED BUILD OPTIONS:
* 'AUTH_MOD'
Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
This patch adds a CoT based on the Trusted Board Boot Requirements
document*. The CoT consists of an array of authentication image
descriptors indexed by the image identifiers.
A new header file with TBBR image identifiers has been added.
Platforms that use the TBBR (i.e. ARM platforms) may reuse these
definitions as part of their platform porting.
PLATFORM PORT - IMPORTANT:
Default image IDs have been removed from the platform common
definitions file (common_def.h). As a consequence, platforms that
used those common definitons must now either include the IDs
provided by the TBBR header file or define their own IDs.
*The NVCounter authentication method has not been implemented yet.
Change-Id: I7c4d591863ef53bb0cd4ce6c52a60b06fa0102d5
This patch extends the platform port by adding an API that returns
either the Root of Trust public key (ROTPK) or its hash. This is
usually stored in ROM or eFUSE memory. The ROTPK returned must be
encoded in DER format according to the following ASN.1 structure:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
In case the platform returns a hash of the key:
DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
keyDigest OCTET STRING
}
An implementation for ARM development platforms is provided in this
patch. When TBB is enabled, the ROTPK hash location must be specified
using the build option 'ARM_ROTPK_LOCATION'. Available options are:
- 'regs' : return the ROTPK hash stored in the Trusted
root-key storage registers.
- 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
BL2 binaries. This hash has been obtained from the development
RSA public key located in 'plat/arm/board/common/rotpk'.
On FVP, the number of MMU tables has been increased to map and
access the ROTPK registers.
A new file 'board_common.mk' has been added to improve code sharing
in the ARM develelopment platforms.
Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
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
Yatharth Kochar
danh-arm
Jeenu Viswambharan
Sandrine Bailleux
Soby Mathew
Antonio Nino Diaz
Gerald Lejeune
Vikram Kanigiri
Juan Castillo
David Wang
Soren Brinkmann
Achin Gupta