GitLab

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 fixes the build time condition deciding whether the
read-write data should be relocated from ROM to RAM. It was incorrectly
using __DATA_ROM_START__, which is a linker symbol and not a compiler
build flag. As a result, the relocation code was always compiled out.

This bug has been introduced by the following patch:
"Rationalize reset handling code"

Change-Id: I1c8d49de32f791551ab4ac832bd45101d6934045

Add SP804 delay timer support to the FVP BSP.

This commit simply provides the 3 constants needed by the SP804
delay timer driver and calls sp804_timer_init() in
bl2_platform_setup(). The BSP does not currently use the delay
timer functions.

Note that the FVP SP804 is a normal world accessible peripheral
and should not be used by the secure world after transition
to the normal world.

Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39
Co-authored-by: Dan Handley <dan.handley@arm.com>

Add a delay timer driver for the ARM SP804 dual timer.

This driver only uses the first timer, called timer 1 in the
SP804 Technical Reference Manual (ARM DDI 0271D).

To use this driver, the BSP must provide three constants:

*   The base address of the SP804 dual timer
*   The clock multiplier
*   The clock divider

The BSP is responsible for calling sp804_timer_init(). The SP804
driver instantiates a constant timer_ops_t and calls the generic
timer_init().

Change-Id: I49ba0a52bdf6072f403d1d0a20e305151d4bc086
Co-authored-by: Dan Handley <dan.handley@arm.com>

The API is simple. The BSP or specific timer driver creates an
instance of timer_ops_t, fills in the timer specific data, then calls
timer_init(). The timer specific data includes a function pointer
to return the timer value and a clock multiplier/divider. The ratio
of the multiplier and the divider is the clock frequency in MHz.

After that, mdelay() or udelay() can be called to delay execution for
the specified time (milliseconds or microseconds, respectively).

Change-Id: Icf8a295e1d25874f789bf28b7412156329dc975c
Co-authored-by: Dan Handley <dan.handley@arm.com>

For CSS based platforms, the constants MHU_SECURE_BASE and
MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes.
As such, they were misnamed because the mailboxes are completely
unrelated to the MHU hardware.

This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines.
The address of the Trusted Mailboxes is now relative to the base of
the Trusted SRAM.

This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE,
which is the address of the first memory region used for communication
between AP and SCP. This is used by the BOM and SCPI protocols.

Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f

Add a comment explaining what the SCP boot configuration information
is on CSS based platforms like Juno. Also express its address
relatively to the base of the Trusted SRAM rather than hard-coding it.

Change-Id: I82cf708a284c8b8212933074ea8c37bdf48b403b

The attempt to run the CPU reset code as soon as possible after reset
results in highly complex conditional code relating to the
RESET_TO_BL31 option.

This patch relaxes this requirement a little. In the BL1, BL3-1 and
PSCI entrypoints code, the sequence of operations is now as follows:
 1) Detect whether it is a cold or warm boot;
 2) For cold boot, detect whether it is the primary or a secondary
    CPU. This is needed to handle multiple CPUs entering cold reset
    simultaneously;
 3) Run the CPU init code.

This patch also abstracts the EL3 registers initialisation done by
the BL1, BL3-1 and PSCI entrypoints into common code.

This improves code re-use and consolidates the code flows for
different types of systems.

NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
OTHERWISE, SECONDARY CPUS WILL PANIC.

Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546

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

This patch adds driver for the 16550 UART interface. The driver is exposed
as a console, which platforms can use to dump their boot/crash logs.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch fixes the incorrect bit width used to extract the primary
cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in
platform_is_primary_cpu().

Change-Id: I14abb361685f31164ecce0755fc1a145903b27aa

The ARM GIC driver treats the entire contents of the GICC_HPPIR as the interrupt
ID instead of just bits[9:0]. This could result in an SGI being treated as a
Group 1 interrupt on a GICv2 system.

This patch introduces a mask to retrieve only the ID from a read of GICC_HPPIR,
GICC_IAR and similar registers. The value read from these registers is masked
with this constant prior to use as an interrupt ID.

Fixes ARM-software/tf-issues#306

Change-Id: Ie3885157de33b71df9781a41f6ef015a30c4608d

Major update to the FVP platform port to use the common platform code
in (include/)plat/arm/* and (include/)plat/common/*. This mainly
consists of removing duplicated code but also introduces some small
behavioural changes where there was unnecessary variation between the
FVP and Juno ports. See earlier commit titled `Add common ARM and CSS
platform code` for details.

Also add support for Foundation FVP version 9.1 during FVP config
setup to prevent a warning being emitted in the console.

Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc

This major change pulls out the common functionality from the
FVP and Juno platform ports into the following categories:

*   (include/)plat/common. Common platform porting functionality that
typically may be used by all platforms.

*   (include/)plat/arm/common. Common platform porting functionality
that may be used by all ARM standard platforms. This includes all
ARM development platforms like FVP and Juno but may also include
non-ARM-owned platforms.

*   (include/)plat/arm/board/common. Common platform porting
functionality for ARM development platforms at the board
(off SoC) level.

*   (include/)plat/arm/css/common. Common platform porting
functionality at the ARM Compute SubSystem (CSS) level. Juno
is an example of a CSS-based platform.

*   (include/)plat/arm/soc/common. Common platform porting
functionality at the ARM SoC level, which is not already defined
at the ARM CSS level.

No guarantees are made about the backward compatibility of
functionality provided in (include/)plat/arm.

Also remove any unnecessary variation between the ARM development
platform ports, including:

*   Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
Juno implementation, which copies the information from BL2 memory
instead of expecting it to persist in shared memory.

*   Unify the TZC configuration. There is no need to add a region
for SCP in Juno; it's enough to simply not allow any access to
this reserved region. Also set region 0 to provide no access by
default instead of assuming this is the case.

*   Unify the number of memory map regions required for ARM
development platforms, although the actual ranges mapped for each
platform may be different. For the FVP port, this reduces the
mapped peripheral address space.

These latter changes will only be observed when the platform ports
are migrated to use the new common platform code in subsequent
patches.

Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8

Add extern declarations of linker symbols to bl_common.h. These are
used by platform ports to determine the memory layout of BL images.
Adding the declarations to this file facilitates removal of these
declarations from the platform porting source files in subsequent
patches.

Also remove the linker symbol declarations from common TSP source
code.

Change-Id: I8ed0426bc815317c4536b588e4e78bc15b4fe91c

Some assembly files containing macros are included like header files
into other assembly files. This will cause assembler errors if they
are included multiple times.

Add header guards to assembly macro files to avoid assembler errors.

Change-Id: Ia632e767ed7df7bf507b294982b8d730a6f8fe69

The required platform constant PLATFORM_CACHE_LINE_SIZE is
unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
same information. CACHE_WRITEBACK_GRANULE is preferred since this
is an architecturally defined term and allows comparison with the
corresponding hardware register value.

Replace all usage of PLATFORM_CACHE_LINE_SIZE with
CACHE_WRITEBACK_GRANULE.

Also, add a runtime assert in BL1 to check that the provided
CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.

Change-Id: If87286be78068424217b9f3689be358356500dcd

Region 0 is special in TZC-400. It is possible to set the access
permissions for this but not the address range or filters to which
the permissions apply. Add a function for setting the region 0
access permissions.

Also add some VERBOSE logging and allow assembly files to include
the TZC header.

Change-Id: I4389261ba10a6e5e2e43ee93d55318dc507b6648

This patch removes the need for a shared buffer between the EL3 and S-EL1
levels. We now use the CPU registers, x0-x7, while passing data between
the two levels. Since TLK is a 32-bit Trusted OS, tlkd has to unpack the
arguments in the x0-x7 registers. TLK in turn gets these values via r0-r7.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

In order for the symbol table in the ELF file to contain the size of
functions written in assembly, it is necessary to report it to the
assembler using the .size directive.

To fulfil the above requirements, this patch introduces an 'endfunc'
macro which contains the .endfunc and .size directives. It also adds
a .func directive to the 'func' assembler macro.

The .func/.endfunc have been used so the assembler can fail if
endfunc is omitted.

Fixes ARM-Software/tf-issues#295

Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
Signed-off-by: Kévin Petit <kevin.petit@arm.com>

This patch adds support to open/close secure sessions with Trusted
Apps and later send commands/events. Modify TLK_NUM_FID to indicate
the total number of FIDs available to the NS world.

Change-Id: I3f1153dfa5510bd44fc25f1fee85cae475b1abf1
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch allows servicing of the non-secure world IRQs when the
CPU is in the secure world. Once the interrupt is handled, the
non-secure world issues the Resume FID to allow the secure payload
complete the preempted standard FID.

Change-Id: Ia52c41adf45014ab51d8447bed6605ca2f935587
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch adds functionality to translate virtual addresses from
secure or non-secure worlds. This functionality helps Trusted Apps
to share virtual addresses directly and allows the NS world to
pass virtual addresses to TLK directly.

Change-Id: I77b0892963e0e839c448b5d0532920fb7e54dc8e
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch registers NS memory buffer with the secure payload using
two different functions IDs - REGISTER_LOGBUF, REGISTER_REQBUF.

a. The SP uses the log-buffer to store its activity logs, in a
pre-decided format. This helps in debugging secure payload's issues.
b. The SP uses the req-buffer to get the parameters required by
sessions with Trusted Applications.

Change-Id: I6b0247cf7790524132ee0da24f1f35b1fccec5d5
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

TLK Dispatcher (tlkd) is based on the tspd and is the glue required
to run TLK as a Secure Payload with the Trusted Firmware.

Change-Id: I69e573d26d52342eb049feef773dd7d2a506f4ab
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

This patch removes the `owner` field in bakery_lock_t structure which
is the data structure used in the bakery lock implementation that uses
coherent memory. The assertions to protect against recursive lock
acquisition were based on the 'owner' field. They are now done based
on the bakery lock ticket number. These assertions are also added
to the bakery lock implementation that uses normal memory as well.

Change-Id: If4850a00dffd3977e218c0f0a8d145808f36b470

This patch optimizes the data structure used with the bakery lock
implementation for coherent memory to save memory and minimize memory
accesses. These optimizations were already part of the bakery lock
implementation for normal memory and this patch now implements
it for the coherent memory implementation as well. Also
included in the patch is a cleanup to use the do-while loop while
waiting for other contenders to finish choosing their tickets.

Change-Id: Iedb305473133dc8f12126726d8329b67888b70f1

This patch adds support for ARM Cortex-A72 processor in the CPU
specific framework.

Change-Id: I5986855fc1b875aadf3eba8c36e989d8a05e5175

This patch updates the FVP and Juno platform ports to use the common
driver for ARM Cache Coherent Interconnects.

Change-Id: Ib142f456b9b673600592616a2ec99e9b230d6542

Even though both CCI-400 and CCI-500 IPs have different configurations
with respect to the number and types of supported interfaces, their
register offsets and programming sequences are similar. This patch
creates a common driver for enabling and disabling snoop transactions
and DVMs with both the IPs.

New platform ports which implement one of these IPs should use this
common driver. Existing platform ports which implement CCI-400 should
migrate to the common driver as the standalone CCI-400 will be
deprecated in the future.

Change-Id: I3ccd0eb7b062922d2e4a374ff8c21e79fa357556

This patch defines the ARRAY_SIZE macro for calculating number of elements
in an array and uses it where appropriate.

Change-Id: I72746a9229f0b259323972b498b9a3999731bc9b

The cpu-ops pointer was initialized before enabling the data cache in the cold
and warm boot paths. This required a DCIVAC cache maintenance operation to
invalidate any stale cache lines resident in other cpus.

This patch moves this initialization to the bl31_arch_setup() function
which is always called after the data cache and MMU has been enabled.

This change removes the need:
 1. for the DCIVAC cache maintenance operation.
 2. to initialise the CPU ops upon resumption from a PSCI CPU_SUSPEND
    call since memory contents are always preserved in this case.

Change-Id: Ibb2fa2f7460d1a1f1e721242025e382734c204c6

This patch modifies the declarations of the functions printf() et al.
and adds the right GCC attribute to request the compiler to check
the type of the arguments passed to these functions against the given
format string. This will ensure that the compiler outputs warning
messages like the following whenever it detects an inconsistency:

 file.c:42: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’

It also fixes the type mismatch inconsistencies that it revealed
across the code base.

NOTE: THIS PATCH MAY FORCE PLATFORM PORTS OR SP/SPDS THAT USE THE
PRINTF FAMILY OF FUNCTIONS TO FIX ANY TYPE MISMATCH INCONSISTENCIES.

Change-Id: If36bb54ec7d6dd2cb4791d89b02a24ac13fd2df6

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 provides an API to access the authentication module that
will be used to verify the authenticity of the images loaded into
memory as part of the Trusted Board Boot process.

To include the authentication module as part of the build, set the
boolean build option TRUSTED_BOARD_BOOT. One single authentication
module must be registered at build time by setting the build option
AUTH_MOD=<mod_name>. All authentication modules will be located in
'common/auth/<mod_name>' and must present the <mod_name>.mk file that
will be included by the build system to compile the module sources.

To create an authentication module, an instance of auth_mod_t called
'auth_mod' must be declared in the module sources. The initialization
and verification functions provided by the module will be exported
through the function pointers specified when declaring this instance.

If an authentication module includes third party sources that do not
adhere to the C99 standard, the -pedantic option may be removed from
the build options by setting the flag DISABLE_PEDANTIC in the module
file <mod_name>.mk.

Change-Id: I080bb04bd421029bcdf22ec2c63807afbf061dcd

This patch adds the missing features to the C library included
in the Trusted Firmware to build PolarSSL:

  - strcasecmp() function
  - exit() function
  - sscanf()* function
  - time.h header file (and its dependencies)

* NOTE: the sscanf() function is not a real implementation. It just
returns the number of expected arguments by counting the number of
'%' characters present in the formar string. This return value is
good enough for PolarSSL because during the certificate parsing
only the return value is checked. The certificate validity period
is ignored.

Change-Id: I43bb3742f26f0bd458272fccc3d72a7f2176ab3d

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 extends the FIP tool to include the certificates
generated by the 'cert_create' tool.

If GENERATE_COT build option is enabled, the Makefile adds the
certificates as dependencies to create the FIP file. Thus, make
target 'fip' will also build the certificates as part of the
Trusted Firmware build process.

Change-Id: I5eee500da7f7be6cfb6e3df0423599739d260074

This patch adds support to call the reset_handler() function in BL3-1 in the
cold and warm boot paths when another Boot ROM reset_handler() has already run.

This means the BL1 and BL3-1 versions of the CPU and platform specific reset
handlers may execute different code to each other. This enables a developer to
perform additional actions or undo actions already performed during the first
call of the reset handlers e.g. apply additional errata workarounds.

Typically, the reset handler will be first called from the BL1 Boot ROM. Any
additional functionality can be added to the reset handler when it is called
from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used
to identify whether this is the first version of the reset handler code to be
executed or an overridden version of the code.

The Cortex-A57 errata workarounds are applied only if they have not already been
applied.

Fixes ARM-software/tf-issue#275

Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053