GitLab

Use full include paths like it is done for common includes.

This cleanup was started in commit d40e0e08283a ("Sanitise includes
across codebase"), but it only cleaned common files and drivers. This
patch does the same to Arm platforms.

Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Enforce full include path for includes. Deprecate old paths.

The following folders inside include/lib have been left unchanged:

- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}

The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).

For example, this patch had to be created because two headers were
called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3 ("drivers: add tzc380 support").

This problem was introduced in commit 4ecca339

 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.

Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.

Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Mark the initialization functions found in the BL31 boot sequence
as __init so they can be reclaimed when no longer needed.

Change-Id: I687a89346419c7710ef5097feaa325d83c527697
Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>

Change-Id: I5993b425445ee794e6d2a792c244c0af53640655
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Change-Id: I1d85b76af002b8b672fcaeca94939b7420bc8243
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

This patch migrates the ARM Standard platforms to the new BL
handover interface. The arm_blx_early_platform_setup() functions
are also modified to take in 4 arguments. The `ARM_BL31_PLAT_PARAM_VAL`
value passed to BL31 from BL2 is now in arg3 in preparation of dynamic
configuration arguments.

Change-Id: I33e8e61325a19e7a7127b1ff203c3b86921bf153
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

Revision C of the Base FVP has the same memory map as earlier revisions,
but has the following differences:

  - Implements CCI550 instead of CCI400,
  - Has a single instantiation of SMMUv3,
  - CPU MPIDs are shifted left by one level, and has MT bit set in them.

The correct interconnect to program is chosen at run time based on the
FVP revision. Therefore, this patch implements FVP functions for
interconnect programming, rather than depending on ARM generic ones. The
macros used have been renamed to reflect this change.

Additionally, this patch initializes SMMUv3 as part of FVP early
platform setup.

New ARM config flags are introduced for feature queries at run time.

Change-Id: Ic7b7f080953a51fceaf62ce7daa6de0573801f09
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>

To make software license auditing simpler, use SPDX[0] license
identifiers instead of duplicating the license text in every file.

NOTE: Files that have been imported by FreeBSD have not been modified.

[0]: https://spdx.org/



Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>

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

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

On ARM standard platforms, snoop and DVM requests used to be enabled
for the primary CPU's cluster only in the first EL3 bootloader.
In other words, if the platform reset into BL1 then CCI coherency
would be enabled by BL1 only, and not by BL3-1 again.

However, this doesn't cater for platforms that use BL3-1 along with
a non-TF ROM bootloader that doesn't enable snoop and DVM requests.
In this case, CCI coherency is never enabled.

This patch modifies the function bl31_early_platform_setup() on
ARM standard platforms so that it always enables snoop and DVM
requests regardless of whether earlier bootloader stages have
already done it. There is no harm in executing this code twice.

ARM Trusted Firmware Design document updated accordingly.

Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c

Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
some of the files so they are consistently prefixed with fvp_.
Update the platform makefiles accordingly.

Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7

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 patch extends the build option `USE_COHERENT_MEMORY` to
conditionally remove coherent memory from the memory maps of
all boot loader stages. The patch also adds necessary
documentation for coherent memory removal in firmware-design,
porting and user guides.

Fixes ARM-Software/tf-issues#106

Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773

* Create cci_init() function in CCI-400 driver to allow platform
  to provide arguments needed by the driver (i.e. base address
  and cluster indices for the ACE slave interfaces).

* Rename cci_(en|dis)able_coherency to
  cci_(en|dis)able_cluster_coherency to make it clear that
  the driver only enables/disables the coherency of CPU
  clusters and not other devices connected to the CCI-400.

* Update FVP port to use new cci_init() function and remove
  unnecessary CCI defintions from platform_def.h. Also rename
  fvp_cci_setup() to fvp_cci_enable() to more clearly
  differentiate between CCI initialization and enabling.

THIS CHANGE REQUIRES PLATFORM PORTS THAT USE THE CCI-400 DRIVER
TO BE UPDATED

Fixes ARM-software/tf-issues#168

Change-Id: I1946a51409b91217b92285b6375082619f607fec

There is no mechanism which allows the TSPD to specify what SPSR to
use when entering BL3-2 instead of BL3-3. This patch divides the
responsibility between tspd_setup() and tspd_init() for initializing
the TSPD and TSP to support the alternate BL3-2 initialization flow
where BL3-1 handsover control to BL3-2 instead of BL3-3.
SPSR generated by TSPD for TSP is preserved due the new division of
labour which fixes #174.

This patch also moves the cpu_context initialization code from
tspd_setup() to tspd_init() immediately before entering the TSP.
Instead tspd_setup() updates the BL3-2 entrypoint info structure
with the state required for initializing the TSP later.

Fixes  ARM-software/TF-issues#174

Change-Id: Ida0a8a48d466c71d5b07b8c7f2af169b73f96940

Assert a valid security state using the macro sec_state_is_valid().
Replace assert() with panic() in those cases that might arise
because of runtime errors and not programming errors.
Replace panic() with assert() in those cases that might arise
because of programming errors.

Fixes ARM-software/tf-issues#96

Change-Id: I51e9ef0439fd5ff5e0edfef49050b69804bf14d5

This patch adds baud rate and UART clock frequency as parameters
to the pl011 driver api console_init(). This allows each platform
to specify UART clock and baud rate according to their specific
hardware implementation.

Fixes ARM-software/tf-issues#215

Change-Id: Id13eef70a1c530e709b34dd1e6eb84db0797ced2

Refactor the FVP gic code in plat/fvp/fvp_gic.c to be a generic ARM
GIC driver in drivers/arm/gic/arm_gic.c. Provide the platform
specific inputs in the arm_gic_setup() function so that the driver
has no explicit dependency on platform code.

Provide weak implementations of the platform interrupt controller
API in a new file, plat/common/plat_gic.c. These simply call through
to the ARM GIC driver.

Move the only remaining FVP GIC function, fvp_gic_init() to
plat/fvp/aarch64/fvp_common.c and remove plat/fvp/fvp_gic.c

Fixes ARM-software/tf-issues#182

Change-Id: Iea82fe095fad62dd33ba9efbddd48c57717edd21

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

Fixes ARM-software/tf-issues#73

Change-Id: I4cfafa38ab436f5ab22c277cb38f884346a267ab

This patch reworks FVP specific code responsible for determining
the entry point information for BL3-2 and BL3-3 stages when BL3-1
is configured as the reset handler.

Change-Id: Ia661ff0a6a44c7aabb0b6c1684b2e8d3642d11ec

bl2_main() was overwriting any platform set X1 parameter for BL3-1
with the value zero.

This patch ensure that any platform set value is correctly passed
to BL3-1. The FVP port adds a check to verify this parameter is
being passed correctly.

Fixes ARM-software/tf-issues#173

Change-Id: Ifbcda73d3d41d2b04a4baf5614e9d2d21f1717c8

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

FVP specific files and functions containing the word "plat" have been
renamed to use the word "fvp" to distinguish them from the common
platform functionality and porting functions.

Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d

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

At present BL3-1 has access to all of the SRAM, including
regions that are mapped as read-only and non-cacheable by other
firmware images.

This patch restricts BL3-1 to only be able to read/write from
memory used for its own data sections

Change-Id: I26cda1b9ba803d91a9eacda768f3ce7032c6db94

Conflicts:

	plat/fvp/bl31_plat_setup.c

This change adds optional reset vector support to BL3-1
which means BL3-1 entry point can detect cold/warm boot,
initialise primary cpu, set up cci and mail box.

When using BL3-1 as a reset vector it is assumed that
the BL3-1 platform code can determine the location of
the BL3-2 images, or load them as there are no parameters
that can be passed to BL3-1 at reset.

It also fixes the incorrect initialisation of mailbox
registers on the FVP platform

This feature can be enabled by building the code with
make variable RESET_TO_BL31 set as 1

Fixes ARM-software/TF-issues#133
Fixes ARM-software/TF-issues#20

Change-Id: I4e23939b1c518614b899f549f1e8d412538ee570

The issues addressed in this patch are:

1. Remove meminfo_t from the common interfaces in BL3-x,
expecting that platform code will find a suitable mechanism
to determine the memory extents in these images and provide
it to the BL3-x images.

2. Remove meminfo_t and bl31_plat_params_t from all FVP BL3-x
code as the images use link-time information to determine
memory extents.

meminfo_t is still used by common interface in BL1/BL2 for
loading images

Change-Id: I4e825ebf6f515b59d84dc2bdddf6edbf15e2d60f

This patch is based on spec published at
https://github.com/ARM-software/tf-issues/issues/133

It rearranges the bl31_args struct into
bl31_params and bl31_plat_params which provide the
information needed for Trusted firmware and platform
specific data via x0 and x1

On the FVP platform BL3-1 params and BL3-1 plat params
and its constituents are stored at the start of TZDRAM.

The information about memory availability and size for
BL3-1, BL3-2 and BL3-3 is moved into platform specific data.

Change-Id: I8b32057a3d0dd3968ea26c2541a0714177820da9

Instead of having a single version of the MMU setup functions for all
bootloader images that can execute either in EL3 or in EL1, provide
separate functions for EL1 and EL3. Each bootloader image can then
call the appropriate version of these functions. The aim is to reduce
the amount of code compiled in each BL image by embedding only what's
needed (e.g. BL1 to embed only EL3 variants).

Change-Id: Ib86831d5450cf778ae78c9c1f7553fe91274c2fa

This patch moves console_init() to bl32_early_platform_setup(). It
also ensures that console_init() is called in each
blX_early_platform_setup() function before the console is used
e.g. through a printf call in an assert() statement.

Fixes ARM-software/TF-issues#127

Change-Id: I5b1f17e0152bab674d807d2a95ff3689c5d4794e

Reduce the number of header files included from other header
files as much as possible without splitting the files. Use forward
declarations where possible. This allows removal of some unnecessary
"#ifndef __ASSEMBLY__" statements.

Also, review the .c and .S files for which header files really need
including and reorder the #include statements alphabetically.

Fixes ARM-software/tf-issues#31

Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e

Add tag names to all unnamed structs in header files. This
allows forward declaration of structs, which is necessary to
reduce header file nesting (to be implemented in a subsequent
commit).

Also change the typedef names across the codebase to use the _t
suffix to be more conformant with the Linux coding style. The
coding style actually prefers us not to use typedefs at all but
this is considered a step too far for Trusted Firmware.

Also change the IO framework structs defintions to use typedef'd
structs to be consistent with the rest of the codebase.

Change-Id: I722b2c86fc0d92e4da3b15e5cab20373dd26786f

Move the FVP power driver to a directory under the FVP platform
port as this is not a generically usable driver.

Change-Id: Ibc78bd88752eb3e3964336741488349ac345f4f0

BL3-1 architecture setup code programs the system counter frequency
into the CNTFRQ_EL0 register. This frequency is defined by the
platform, though. This patch introduces a new platform hook that
the architecture setup code can call to retrieve this information.
In the ARM FVP port, this returns the first entry of the frequency
modes table from the memory mapped generic timer.

All system counter setup code has been removed from BL1 as some
platforms may not have initialized the system counters at this stage.
The platform specific settings done exclusively in BL1 have been moved
to BL3-1. In the ARM FVP port, this consists in enabling and
initializing the System level generic timer. Also, the frequency change
request in the counter control register has been set to 0 to make it
explicit it's using the base frequency. The CNTCR_FCREQ() macro has been
fixed in this context to give an entry number rather than a bitmask.

In future, when support for firmware update is implemented, there
is a case where BL1 platform specific code will need to program
the counter frequency. This should be implemented at that time.

This patch also updates the relevant documentation.

It properly fixes ARM-software/tf-issues#24

Change-Id: If95639b279f75d66ac0576c48a6614b5ccb0e84b

This reverts commit 1c297bf0
because it introduced a bug: the CNTFRQ_EL0 register was no
longer programmed by all CPUs.  bl31_platform_setup() function
is invoked only in the cold boot path and consequently only
on the primary cpu.

A subsequent commit will correctly implement the necessary changes
to the counter frequency setup code.

Fixes ARM-software/tf-issues#125

Conflicts:

	docs/firmware-design.md
	plat/fvp/bl31_plat_setup.c

Change-Id: Ib584ad7ed069707ac04cf86717f836136ad3ab54

This patch reworks the console driver to ensure that each bootloader stage
initializes it independently. As a result, both BL3-1 and BL2 platform code
now calls console_init() instead of relying on BL1 to perform console setup

Fixes ARM-software/tf-issues#120

Change-Id: Ic4d66e0375e40a2fc7434afcabc8bbb4715c14ab

At present, bl1_arch_setup() and bl31_arch_setup() program the counter
frequency using a value from the memory mapped generic timer. The
generic timer however is not necessarily present on all ARM systems
(although it is architected to be present on all server systems).

This patch moves the timer setup to platform-specific code and updates
the relevant documentation. Also, CNTR.FCREQ is set as the specification
requires the bit corresponding to the counter's frequency to be set when
enabling. Since we intend to use the base frequency, set bit 8.

Fixes ARM-software/tf-issues#24

Change-Id: I32c52cf882253e01f49056f47c58c23e6f422652

This patch adds the following support to the BL3-1 stage:

1. BL3-1 allows runtime services to specify and determine the security
   state of the next image after BL3-1. This has been done by adding
   the `bl31_set_next_image_type()` & `bl31_get_next_image_type()`
   apis. The default security state is non-secure. The platform api
   `bl31_get_next_image_info()` has been modified to let the platform
   decide which is the next image in the desired security state.

2. BL3-1 exports the `bl31_prepare_next_image_entry()` function to
   program entry into the target security state. It uses the apis
   introduced in 1. to do so.

3. BL3-1 reads the information populated by BL2 about the BL3-2 image
   into its internal data structures.

4. BL3-1 introduces a weakly defined reference `bl32_init()` to allow
   initialisation of a BL3-2 image. A runtime service like the Secure
   payload dispatcher will define this function if present.

Change-Id: Icc46dcdb9e475ce6575dd3f9a5dc7a48a83d21d1

This patch reworks BL2 to BL3-1 hand over interface by introducing a
composite structure (bl31_args) that holds the superset of information
that needs to be passed from BL2 to BL3-1.

  - The extents of secure memory available to BL3-1
  - The extents of memory available to BL3-2 (not yet implemented) and
    BL3-3
  - Information to execute BL3-2 (not yet implemented) and BL3-3 images

This patch also introduces a new platform API (bl2_get_bl31_args_ptr)
that needs to be implemented by the platform code to export reference to
bl31_args structure which has been allocated in platform-defined memory.

The platform will initialize the extents of memory available to BL3-3
during early platform setup in bl31_args structure. This obviates the
need for bl2_get_ns_mem_layout platform API.

BL2 calls the bl2_get_bl31_args_ptr function to get a reference to
bl31_args structure. It uses the 'bl33_meminfo' field of this structure
to load the BL3-3 image. It sets the entry point information for the
BL3-3 image in the 'bl33_image_info' field of this structure. The
reference to this structure is passed to the BL3-1 image.

Also fixes issue ARM-software/tf-issues#25

Change-Id: Ic36426196dd5ebf89e60ff42643bed01b3500517