Skip to content

GitLab

Switch branch/tag
  1. 04 May, 2018 3 commits
    • Jeenu Viswambharan's avatar
      AArch64: Introduce RAS handling · 14c6016a
      Jeenu Viswambharan authored 
      

RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional
extensions to base ARMv8.0 architecture.

This patch adds build system support to enable RAS features in ARM
Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for
this.

With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is
inserted at all EL3 vector entry and exit. ESBs will synchronize pending
external aborts before entering EL3, and therefore will contain and
attribute errors to lower EL execution. Any errors thus synchronized are
detected via. DISR_EL1 register.

When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1.

Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      14c6016a
    • 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
    • Jeenu Viswambharan's avatar
      AArch64: Refactor GP register restore to separate function · ef653d93
      Jeenu Viswambharan authored 
      

At present, the function that restores general purpose registers also
does ERET. Refactor the restore code to restore general purpose
registers without ERET to complement the save function.

The macro save_x18_to_x29_sp_el0 was used only once, and is therefore
removed, and its contents expanded inline for readability.

No functional changes, but with this patch:

  - The SMC return path will incur an branch-return and an additional
    register load.

  - The unknown SMC path restores registers x0 to x3.

Change-Id: I7a1a63e17f34f9cde810685d70a0ad13ca3b7c50
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      ef653d93
  3. 03 May, 2018 1 commit
  5. 02 May, 2018 1 commit
  7. 01 May, 2018 5 commits
  9. 27 Apr, 2018 3 commits
    • Masahiro Yamada's avatar
      types: use int-ll64 for both aarch32 and aarch64 · 0a2d5b43
      Masahiro Yamada authored 
      Since commit 031dbb12

 ("AArch32: Add essential Arch helpers"),
it is difficult to use consistent format strings for printf() family
between aarch32 and aarch64.

For example, uint64_t is defined as 'unsigned long long' for aarch32
and as 'unsigned long' for aarch64.  Likewise, uintptr_t is defined
as 'unsigned int' for aarch32, and as 'unsigned long' for aarch64.

A problem typically arises when you use printf() in common code.

One solution could be, to cast the arguments to a type long enough
for both architectures.  For example, if 'val' is uint64_t type,
like this:

  printf("val = %llx\n", (unsigned long long)val);

Or, somebody may suggest to use a macro provided by <inttypes.h>,
like this:

  printf("val = %" PRIx64 "\n", val);

But, both would make the code ugly.

The solution adopted in Linux kernel is to use the same typedefs for
all architectures.  The fixed integer types in the kernel-space have
been unified into int-ll64, like follows:

    typedef signed char           int8_t;
    typedef unsigned char         uint8_t;

    typedef signed short          int16_t;
    typedef unsigned short        uint16_t;

    typedef signed int            int32_t;
    typedef unsigned int          uint32_t;

    typedef signed long long      int64_t;
    typedef unsigned long long    uint64_t;

[ Linux commit: 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf ]

This gets along with the codebase shared between 32 bit and 64 bit,
with the data model called ILP32, LP64, respectively.

The width for primitive types is defined as follows:

                   ILP32           LP64
    int            32              32
    long           32              64
    long long      64              64
    pointer        32              64

'long long' is 64 bit for both, so it is used for defining uint64_t.
'long' has the same width as pointer, so for uintptr_t.

We still need an ifdef conditional for (s)size_t.

All 64 bit architectures use "unsigned long" size_t, and most 32 bit
architectures use "unsigned int" size_t.  H8/300, S/390 are known as
exceptions; they use "unsigned long" size_t despite their architecture
is 32 bit.

One idea for simplification might be to define size_t as 'unsigned long'
across architectures, then forbid the use of "%z" string format.
However, this would cause a distortion between size_t and sizeof()
operator.  We have unknowledge about the native type of sizeof(), so
we need a guess of it anyway.  I want the following formula to always
return 1:

  __builtin_types_compatible_p(size_t, typeof(sizeof(int)))

Fortunately, ARM is probably a majority case.  As far as I know, all
32 bit ARM compilers use "unsigned int" size_t.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0a2d5b43
    • Masahiro Yamada's avatar
      arch_helpers: use u_register_t for register read/write · 8f4dbaab
      Masahiro Yamada authored 
      

u_register_t is preferred rather than uint64_t.  This is more
consistent with the aarch32 implementation.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      8f4dbaab
    • Masahiro Yamada's avatar
      Fix pointer type mismatch of handlers · 57d1e5fa
      Masahiro Yamada authored 
      Commit 4c0d0390

 ("Rework type usage in Trusted Firmware") changed
the type usage in struct declarations, but did not touch the definition
side.  Fix the type mismatch.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      57d1e5fa
  11. 26 Apr, 2018 2 commits
    • Dimitris Papastamos's avatar
      Merge pull request #1345 from dbasehore/udelay · a8d9550b
      Dimitris Papastamos authored 
      rockchip/rk3399: Fix sram_udelay
      a8d9550b
    • Antonio Nino Diaz's avatar
      xlat: Set AP[1] to 1 when it is RES1 · 01c0a38e
      Antonio Nino Diaz authored 
      

According to the ARMv8 ARM issue C.a:

    AP[1] is valid only for stage 1 of a translation regime that can
    support two VA ranges. It is RES 1 when stage 1 translations can
    support only one VA range.

This means that, even though this bit is ignored, it should be set to 1
in the EL3 and EL2 translation regimes.

For translation regimes consisting on EL0 and a higher regime this bit
selects between control at EL0 or at the higher Exception level. The
regimes that support two VA ranges are EL1&0 and EL2&0 (the later one
is only available since ARMv8.1).

This fix has to be applied to both versions of the translation tables
library.

Change-Id: If19aaf588551bac7aeb6e9a686cf0c2068e7c181
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      01c0a38e
  13. 24 Apr, 2018 2 commits
  15. 23 Apr, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Add support for the SMC Calling Convention 2.0 · 2f370465
      Antonio Nino Diaz authored 
      

Due to differences in the bitfields of the SMC IDs, it is not possible
to support SMCCC 1.X and 2.0 at the same time.

The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build
option that specifies the major version of the SMCCC that the Trusted
Firmware supports. The only two allowed values are 1 and 2, and it
defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it.

Note: Support for SMCCC v2.0 is an experimental feature to enable
prototyping of secure partition specifications. Support for this
convention is disabled by default and could be removed without notice.

Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2f370465
  17. 21 Apr, 2018 1 commit
  19. 18 Apr, 2018 3 commits
  21. 17 Apr, 2018 2 commits
  23. 16 Apr, 2018 3 commits
  25. 13 Apr, 2018 10 commits
  27. 12 Apr, 2018 3 commits