Skip to content

GitLab

Switch branch/tag
  1. 28 Sep, 2018 5 commits
  3. 04 Sep, 2018 1 commit
    • John Tsichritzis's avatar
      Prepare Mbed TLS drivers for shared heap · 6d01a463
      John Tsichritzis authored 
      

The Mbed TLS drivers, in order to work, need a heap for internal usage.
This heap, instead of being directly referenced by the drivers, now it
is being accessed indirectly through a pointer. Also, the heap, instead
of being part of the drivers, now it is being received through the
plat_get_mbedtls_heap() function. This function requests a heap from the
current BL image which utilises the Mbed TLS drivers.

Those changes create the opportunity for the Mbed TLS heap to be shared
among different images, thus saving memory. A default heap
implementation is provided but it can be overridden by a platform
specific, optimised implemenetation.

Change-Id: I286a1f10097a9cdcbcd312201eea576c18d157fa
Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      6d01a463
  5. 22 Aug, 2018 1 commit
  7. 24 Jul, 2018 1 commit
  9. 04 May, 2018 1 commit
    • Jeenu Viswambharan's avatar
      AArch64: Introduce External Abort handling · 76454abf
      Jeenu Viswambharan authored 
      

At present, any External Abort routed to EL3 is reported as an unhandled
exception and cause a panic. This patch enables ARM Trusted Firmware to
handle External Aborts routed to EL3.

With this patch, when an External Abort is received at EL3, its handling
is delegated to plat_ea_handler() function. Platforms can provide their
own implementation of this function. This patch adds a weak definition
of the said function that prints out a message and just panics.

In order to support handling External Aborts at EL3, the build option
HANDLE_EA_EL3_FIRST must be set to 1.

Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to
compilation; this patch fixes that too.

Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      76454abf
  11. 07 Apr, 2018 1 commit
    • Jiafei Pan's avatar
      Add support for BL2 in XIP memory · 7d173fc5
      Jiafei Pan authored 
      

In some use-cases BL2 will be stored in eXecute In Place (XIP) memory,
like BL1. In these use-cases, it is necessary to initialize the RW sections
in RAM, while leaving the RO sections in place. This patch enable this
use-case with a new build option, BL2_IN_XIP_MEM. For now, this option
is only supported when BL2_AT_EL3 is 1.
Signed-off-by: default avatarJiafei Pan <Jiafei.Pan@nxp.com>
      7d173fc5
  13. 27 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Clean usage of void pointers to access symbols · 9f85f9e3
      Joel Hutton authored 
      

Void pointers have been used to access linker symbols, by declaring an
extern pointer, then taking the address of it. This limits symbols
values to aligned pointer values. To remove this restriction an
IMPORT_SYM macro has been introduced, which declares it as a char
pointer and casts it to the required type.

Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9f85f9e3
  15. 28 Feb, 2018 2 commits
  17. 26 Feb, 2018 3 commits
    • Soby Mathew's avatar
      BL1: Deprecate the `bl1_init_bl2_mem_layout()` API · 101d01e2
      Soby Mathew authored 
      

The `bl1_init_bl2_mem_layout()` API is now deprecated. The default weak
implementation of `bl1_plat_handle_post_image_load()` calculates the
BL2 memory layout and populates the same in x1(r1). This ensures
compatibility for the deprecated API.

Change-Id: Id44bdc1f572dc42ee6ceef4036b3a46803689315
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      101d01e2
    • Soby Mathew's avatar
      Introduce the new BL handover interface · a6f340fe
      Soby Mathew authored 
      

This patch introduces a new BL handover interface. It essentially allows
passing 4 arguments between the different BL stages. Effort has been made
so as to be compatible with the previous handover interface. The previous
blx_early_platform_setup() platform API is now deprecated and the new
blx_early_platform_setup2() variant is introduced. The weak compatiblity
implementation for the new API is done in the `plat_bl_common.c` file.
Some of the new arguments in the new API will be reserved for generic
code use when dynamic configuration support is implemented. Otherwise
the other registers are available for platform use.

Change-Id: Ifddfe2ea8e32497fe1beb565cac155ad9d50d404
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a6f340fe
    • Soby Mathew's avatar
      Add image_id to bl1_plat_handle_post/pre_image_load() · 566034fc
      Soby Mathew authored 
      

This patch adds an argument to bl1_plat_post/pre_image_load() APIs
to make it more future proof. The default implementation of
these are moved to `plat_bl1_common.c` file.

These APIs are now invoked appropriately in the FWU code path prior
to or post image loading by BL1 and are not restricted
to LOAD_IMAGE_V2.

The patch also reorganizes some common platform files. The previous
`plat_bl2_el3_common.c` and `platform_helpers_default.c` files are
merged into a new `plat_bl_common.c` file.

NOTE: The addition of an argument to the above mentioned platform APIs
is not expected to have a great impact because these APIs were only
recently added and are unlikely to be used.

Change-Id: I0519caaee0f774dd33638ff63a2e597ea178c453
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      566034fc
  19. 01 Feb, 2018 2 commits
  21. 18 Jan, 2018 1 commit
    • Roberto Vargas's avatar
      bl2-el3: Add BL2_EL3 image · b1d27b48
      Roberto Vargas authored 
      

This patch enables BL2 to execute at the highest exception level
without any dependancy on TF BL1. This enables platforms which already
have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL
stages without need for BL1.  This is not currently possible because
BL2 executes at S-EL1 and cannot jump straight to EL3.

Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      b1d27b48
  23. 13 Nov, 2017 2 commits
  25. 08 Nov, 2017 1 commit
    • Antonio Nino Diaz's avatar
      SPM: Introduce Secure Partition Manager · 2fccb228
      Antonio Nino Diaz authored 
      

A Secure Partition is a software execution environment instantiated in
S-EL0 that can be used to implement simple management and security
services. Since S-EL0 is an unprivileged exception level, a Secure
Partition relies on privileged firmware e.g. ARM Trusted Firmware to be
granted access to system and processor resources. Essentially, it is a
software sandbox that runs under the control of privileged software in
the Secure World and accesses the following system resources:

- Memory and device regions in the system address map.
- PE system registers.
- A range of asynchronous exceptions e.g. interrupts.
- A range of synchronous exceptions e.g. SMC function identifiers.

A Secure Partition enables privileged firmware to implement only the
absolutely essential secure services in EL3 and instantiate the rest in
a partition. Since the partition executes in S-EL0, its implementation
cannot be overly complex.

The component in ARM Trusted Firmware responsible for managing a Secure
Partition is called the Secure Partition Manager (SPM). The SPM is
responsible for the following:

- Validating and allocating resources requested by a Secure Partition.
- Implementing a well defined interface that is used for initialising a
  Secure Partition.
- Implementing a well defined interface that is used by the normal world
  and other secure services for accessing the services exported by a
  Secure Partition.
- Implementing a well defined interface that is used by a Secure
  Partition to fulfil service requests.
- Instantiating the software execution environment required by a Secure
  Partition to fulfil a service request.

Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f
Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
Co-authored-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
Co-authored-by: default avatarAchin Gupta <achin.gupta@arm.com>
Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2fccb228
  27. 24 Oct, 2017 1 commit
  29. 16 Oct, 2017 10 commits
  31. 11 Sep, 2017 1 commit
    • Soby Mathew's avatar
      Implement log framework · 7f56e9a3
      Soby Mathew authored 
      

This patch gives users control over logging messages printed from the C
code using the LOG macros defined in debug.h Users now have the ability
to reduce the log_level at run time using the tf_log_set_max_level()
function. The default prefix string can be defined by platform by
overriding the `plat_log_get_prefix()` platform API which is also
introduced in this patch.

The new log framework results in saving of some RO data. For example,
when BL1 is built for FVP with LOG_LEVEL=LOG_LEVEL_VERBOSE, resulted
in saving 384 bytes of RO data and increase of 8 bytes of RW data. The
framework also adds about 108 bytes of code to the release build of FVP.

Fixes ARM-software/tf-issues#462

Change-Id: I476013d9c3deedfdd4c8b0b0f125665ba6250554
Co-authored-by: default avatarEleanor Bonnici <Eleanor.bonnici@arm.com>
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      7f56e9a3
  33. 03 May, 2017 1 commit
  35. 31 Mar, 2017 2 commits
    • Douglas Raillard's avatar
      Add support for GCC stack protection · 51faada7
      Douglas Raillard authored 
      

Introduce new build option ENABLE_STACK_PROTECTOR. It enables
compilation of all BL images with one of the GCC -fstack-protector-*
options.

A new platform function plat_get_stack_protector_canary() is introduced.
It returns a value that is used to initialize the canary for stack
corruption detection. Returning a random value will prevent an attacker
from predicting the value and greatly increase the effectiveness of the
protection.

A message is printed at the ERROR level when a stack corruption is
detected.

To be effective, the global data must be stored at an address
lower than the base of the stacks. Failure to do so would allow an
attacker to overwrite the canary as part of an attack which would void
the protection.

FVP implementation of plat_get_stack_protector_canary is weak as
there is no real source of entropy on the FVP. It therefore relies on a
timer's value, which could be predictable.

Change-Id: Icaaee96392733b721fa7c86a81d03660d3c1bc06
Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      51faada7
    • Antonio Nino Diaz's avatar
      Add and use plat_crash_console_flush() API · 801cf93c
      Antonio Nino Diaz authored 
      

This API makes sure that all the characters sent to the crash console
are output before returning from it.

Porting guide updated.

Change-Id: I1785f970a40f6aacfbe592b6a911b1f249bb2735
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      801cf93c
  37. 13 Feb, 2017 1 commit
    • dp-arm's avatar
      PSCI: Decouple PSCI stat residency calculation from PMF · 04c1db1e
      dp-arm authored 
      

This patch introduces the following three platform interfaces:

* void plat_psci_stat_accounting_start(const psci_power_state_t *state_info)

  This is an optional hook that platforms can implement in order
  to perform accounting before entering a low power state.  This
  typically involves capturing a timestamp.

* void plat_psci_stat_accounting_stop(const psci_power_state_t *state_info)

  This is an optional hook that platforms can implement in order
  to perform accounting after exiting from a low power state.  This
  typically involves capturing a timestamp.

* u_register_t plat_psci_stat_get_residency(unsigned int lvl,
	const psci_power_state_t *state_info,
	unsigned int last_cpu_index)

  This is an optional hook that platforms can implement in order
  to calculate the PSCI stat residency.

If any of these interfaces are overridden by the platform, it is
recommended that all of them are.

By default `ENABLE_PSCI_STAT` is disabled.  If `ENABLE_PSCI_STAT`
is set but `ENABLE_PMF` is not set then an alternative PSCI stat
collection backend must be provided.  If both are set, then default
weak definitions of these functions are provided, using PMF to
calculate the residency.

NOTE: Previously, platforms did not have to explicitly set
`ENABLE_PMF` since this was automatically done by the top-level
Makefile.

Change-Id: I17b47804dea68c77bc284df15ee1ccd66bc4b79b
Signed-off-by: default avatardp-arm <dimitris.papastamos@arm.com>
      04c1db1e
  39. 26 Jan, 2017 1 commit
    • David Cunado's avatar
      Resolve build errors flagged by GCC 6.2 · 9edac047
      David Cunado authored 
      

With GCC 6.2 compiler, more C undefined behaviour is being flagged as
warnings, which result in build errors in ARM TF build.

The specific issue that this patch resolves is the use of (1 << 31),
which is predominantly used in case statements, where 1 is represented
as a signed int. When shifted to msb the behaviour is undefined.

The resolution is to specify 1 as an unsigned int using a convenience
macro ULL(). A duplicate macro MAKE_ULL() is replaced.

Fixes ARM-software/tf-issues#438

Change-Id: I08e3053bbcf4c022ee2be33a75bd0056da4073e1
Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      9edac047
  41. 18 Jan, 2017 1 commit