GitLab

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

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

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

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.

Fixes ARM-software/tf-issues#328

Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a

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 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 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 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

This patch removes the plat_get_max_afflvl() platform API
and instead replaces it with a platform macro PLATFORM_MAX_AFFLVL.
This is done because the maximum affinity level for a platform
is a static value and it is more efficient for it to be defined
as a platform macro.

NOTE: PLATFORM PORTS NEED TO BE UPDATED ON MERGE OF THIS COMMIT

Fixes ARM-Software/tf-issues#265

Change-Id: I31d89b30c2ccda30d28271154d869060d50df7bf

This patch adds the function plat_match_rotpk() to the platform
porting layer to provide a Root Of Trust Public key (ROTPK)
verification mechanism. This function is called during the
Trusted Board Boot process and receives a supposed valid copy
of the ROTPK as a parameter, usually obtained from an external
source (for instance, a certificate). It returns 0 (success) if
that key matches the actual ROTPK stored in the system or any
other value otherwise.

The mechanism to access the actual ROTPK stored in the system
is platform specific and should be implemented as part of this
function. The format of the ROTPK is also platform specific
(to save memory, some platforms might store a hash of the key
instead of the whole key).

TRUSTED_BOARD_BOOT build option has been added to allow the user
to enable the Trusted Board Boot features. The implementation of
the plat_match_rotpk() funtion is mandatory when Trusted Board
Boot is enabled.

For development purposes, FVP and Juno ports provide a dummy
function that returns always success (valid key). A safe trusted
boot implementation should provide a proper matching function.

Documentation updated accordingly.

Change-Id: I74ff12bc2b041556c48533375527d9e8c035b8c3

This patch gathers miscellaneous minor fixes to the documentation, and comments
in the source code.

Change-Id: I631e3dda5abafa2d90f464edaee069a1e58b751b
Co-Authored-By: Soby Mathew <soby.mathew@arm.com>
Co-Authored-By: Dan Handley <dan.handley@arm.com>

* Move TSP platform porting functions to new file:
  include/bl32/tsp/platform_tsp.h.

* Create new TSP_IRQ_SEC_PHY_TIMER definition for use by the generic
  TSP interrupt handling code, instead of depending on the FVP
  specific definition IRQ_SEC_PHY_TIMER.

* Rename TSP platform porting functions from bl32_* to tsp_*, and
  definitions from BL32_* to TSP_*.

* Update generic TSP code to use new platform porting function names
  and definitions.

* Update FVP port accordingly and move all TSP source files to:
  plat/fvp/tsp/.

* Update porting guide with above changes.

Note: THIS CHANGE REQUIRES ALL PLATFORM PORTS OF THE TSP TO
      BE UPDATED

Fixes ARM-software/tf-issues#167

Change-Id: Ic0ff8caf72aebb378d378193d2f017599fc6b78f

This patch introduces platform APIs to initialise and
print a character on a designated crash console.
For the FVP platform, PL011_UART0 is the designated
crash console. The platform porting guide is also updated
to document the new APIs.

Change-Id: I5e97d8762082e0c88c8c9bbb479353eac8f11a66

This patch adds a 'flags' parameter to each exception level specific function
responsible for enabling the MMU. At present only a single flag which indicates
whether the data cache should also be enabled is implemented. Subsequent patches
will use this flag when enabling the MMU in the warm boot paths.

Change-Id: I0eafae1e678c9ecc604e680851093f1680e9cefa

 - Add support for loading a BL3-0 image in BL2. Information about
   memory extents is populated by platform-specific code. Subsequent
   handling of BL3-0 is also platform specific.
   The BL2 main function has been broken down to improve readability.
   The BL3-2 image is now loaded before the BL3-3 image to align with
   the boot flow.

 - Build system: Add support for specifying a BL3-0 image that will be
   included into the FIP image.

 - IO FIP driver: Add support for identifying a BL3-0 image inside a
   FIP image.

 - Update the documentation to reflect the above changes.

Change-Id: I067c184afd52ccaa86569f13664757570c86fc48

This concept is no longer required since we now support loading of
images at fixed addresses only.

The image loader now automatically detects the position of the image
inside the current memory layout and updates the layout such that
memory fragmentation is minimised.

The 'attr' field of the meminfo data structure, which used to hold
the bottom/top loading information, has been removed. Also the 'next'
field has been removed as it wasn't used anywhere.

The 'init_bl2_mem_layout()' function has been moved out of common
code and put in BL1-specific code. It has also been renamed into
'bl1_init_bl2_mem_layout'.

Fixes ARM-software/tf-issues#109

Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d

Exclude stdlib files because they do not follow kernel code style.

Fixes ARM-software/tf-issues#73

Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab

Rename the ic_* platform porting functions to plat_ic_* to be
consistent with the other functions in platform.h. Also rename
bl31_get_next_image_info() to bl31_plat_get_next_image_ep_info()
and remove the duplicate declaration in bl31.h.

Change-Id: I4851842069d3cff14c0a468daacc0a891a7ede84

Remove the FVP specific comments in platform.h since this file
is re-usable across all platforms.

Change-Id: Ifd4a4f72562adb3ecf8b9078b0150f170ef22dba

Previously, the enable_mmu_elX() functions were implicitly part of
the platform porting layer since they were included by generic
code. These functions have been placed behind 2 new platform
functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu().
These are weakly defined so that they can be optionally overridden
by platform ports.

Also, the enable_mmu_elX() functions have been moved to
lib/aarch64/xlat_tables.c for optional re-use by platform ports.
These functions are tightly coupled with the translation table
initialization code.

Fixes ARM-software/tf-issues#152

Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c

Some platform porting functions were in BL specific header files.
These have been moved to platform.h so that all porting functions
are in the same place. The functions are now grouped by BL.
Obsolete BL headers files have been removed.

Also, the weak declaration of the init_bl2_mem_layout() function
has been moved out the header file and into the source file
(bl_common.c) using the more succinct #pragma syntax. This
mitigates the risk of 2 weak definitions being created and the
wrong one being picked up by the compiler.

Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83

Previously, platform.h contained many declarations and definitions
used for different purposes. This file has been split so that:

* Platform definitions used by common code that must be defined
  by the platform are now in platform_def.h. The exact include
  path is exported through $PLAT_INCLUDES in the platform makefile.

* Platform definitions specific to the FVP platform are now in
  /plat/fvp/fvp_def.h.

* Platform API declarations specific to the FVP platform are now
  in /plat/fvp/fvp_private.h.

* The remaining platform API declarations that must be ported by
  each platform are still in platform.h but this file has been
  moved to /include/plat/common since this can be shared by all
  platforms.

Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a