Skip to content

GitLab

Switch branch/tag
  1. 01 Oct, 2018 1 commit
  3. 28 Sep, 2018 3 commits
  5. 21 Sep, 2018 1 commit
  7. 30 Aug, 2018 2 commits
    • Douglas Raillard's avatar
      backtrace: Introduce backtrace function · 0c62883f
      Douglas Raillard authored 
      

This function diplays the backtrace, the current EL and security state
to allow a post-processing tool to choose the right binary to interpret
the dump.

The output can be fed to GNU addr2line to resolve function names given
an ELF binary compiled with debug information. The "-i" flag is
recommended to improve display in case of inlined functions. The *.dump
files generated during the build process can also be used.

The function works in AArch64 and AArch32. In AArch32 it only works in
A32 mode (without T32 interworking), which is enforced in the Makefile.

Sample output of a backtrace at EL3:

    BACKTRACE: START: function_name
    0: EL3: 0x798
    1: EL3: 0x538
    2: EL3: 0x550
    3: EL3: 0x55c
    4: EL3: 0x568
    5: EL3: 0x5a8
    6: EL3: 0xf4
    BACKTRACE: END: function_name

In order to enable it the new option ENABLE_BACKTRACE must be set to 1.
This option is set to 1 by default only in AArch64 debug builds. As
usual, it can be overridden by the platform makefile and in the build
command line.

Change-Id: Icaff39b0e5188329728be2f3c72b868b2368e794
Co-authored-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      0c62883f
    • Antonio Nino Diaz's avatar
      Allow manually setting the AArch32 instruction set · 8fd9d4d5
      Antonio Nino Diaz authored 
      

At the moment the AArch32 instruction set isn't specified in the command
line, which means that the compiler is free to choose the one it sees
fit. This decision may change between compiler versions, so it is better
to specify it manually.

The build option AARCH32_INSTRUCTION_SET has been introduced for this
reason. This option can be set to T32 or A32 to pass the correct flags
to the compiler.

The current behaviour is to default to T32 due to it's smaller size.

Change-Id: I02297eb1d9404b5868ff7c054fbff9b3cda7fdb6
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      8fd9d4d5
  9. 22 Aug, 2018 2 commits
  11. 20 Aug, 2018 1 commit
    • Jeenu Viswambharan's avatar
      AArch64: Enable MPAM for lower ELs · 5f835918
      Jeenu Viswambharan authored 
      

Memory Partitioning And Monitoring is an Armv8.4 feature that enables
various memory system components and resources to define partitions.
Software running at various ELs can then assign themselves to the
desired partition to control their performance aspects.

With this patch, when ENABLE_MPAM_FOR_LOWER_ELS is set to 1, EL3 allows
lower ELs to access their own MPAM registers without trapping to EL3.
This patch however doesn't make use of partitioning in EL3; platform
initialisation code should configure and use partitions in EL3 if
required.

Change-Id: I5a55b6771ccaa0c1cffc05543d2116b60cbbcdcd
Co-authored-by: default avatarJames Morse <james.morse@arm.com>
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      5f835918
  13. 03 Aug, 2018 4 commits
  15. 11 Jul, 2018 3 commits
  17. 03 Jul, 2018 1 commit
    • Sandrine Bailleux's avatar
      AArch32: Force compiler to align memory accesses · a9c4dde3
      Sandrine Bailleux authored 
      Alignment fault checking is always enabled in TF (by setting the
SCTLR.A bit). Thus, all instructions that load or store one or more
registers have an alignment check that the address being accessed is
aligned to the size of the data element(s) being accessed. If this
check fails it causes an Alignment fault, which is taken as a Data
Abort exception.

The compiler needs to be aware that it must not emit load and store
instructions resulting in unaligned accesses. It already is for
AArch64 builds (see commit fa1d3712

 "Add -mstrict-align to the gcc
options"), this patch does the same for AArch32 builds.

Change-Id: Ic885796bc6ed0ff392aae2d49f3a13f517e0169f
Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      a9c4dde3
  19. 18 Jun, 2018 1 commit
    • Yann Gautier's avatar
      Build: add cpp build processing for dtb · 01d237cb
      Yann Gautier authored 
      

This is an add-on feature that allows processing
device tree with external includes.

"-Iinclude" is also added to INCLUDES.
It allows inclusion of dt-bindings files either in dts files or drivers,
as those files will be in include/dt-bindings/.

"-i fdts" is added to the DTC command line.
As the pre-processed files are in build directory, the DT source directory
has to be explicitely included, to manages /include/ directives.

fixes arm-software/tf-issues#595
Signed-off-by: default avatarLionel Debieve <lionel.debieve@st.com>
Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      01d237cb
  21. 18 May, 2018 1 commit
  23. 04 May, 2018 3 commits
    • Jeenu Viswambharan's avatar
      RAS: Add fault injection support · 1a7c1cfe
      Jeenu Viswambharan authored 
      

The ARMv8.4 RAS extensions introduce architectural support for software
to inject faults into the system in order to test fault-handling
software. This patch introduces the build option FAULT_HANDLING_SUPPORT
to allow for lower ELs to use registers in the Standard Error Record to
inject fault. The build option RAS_EXTENSIONS must also be enabled along
with fault injection.

This feature is intended for testing purposes only, and is advisable to
keep disabled for production images.

Change-Id: I6f7a4454b15aec098f9505a10eb188c2f928f7ea
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      1a7c1cfe
    • 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
  25. 01 May, 2018 1 commit
    • Roberto Vargas's avatar
      Remove the unused macro NDEBUG · 379dcab7
      Roberto Vargas authored 
      

The C standards specify that this macro is used to
disable asserts but, in our code, the assert macro
is controlled with ENABLE_ASSERTIONS. Having this macro
here creates confusion about the behaviour of assert.

Change-Id: Iab8689a14dc2b8790729857d56585ce43c0c4f51
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      379dcab7
  27. 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
  29. 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
  31. 03 Apr, 2018 1 commit
  33. 20 Mar, 2018 1 commit
  35. 16 Mar, 2018 1 commit
  37. 01 Mar, 2018 1 commit
    • Dan Handley's avatar
      Improve MULTI_CONSOLE_API deprecation warnings · bc1a03c7
      Dan Handley authored 
      

For platforms that have not migrated to MULTI_CONSOLE_API == 1, there
are a lot of confusing deprecated declaration warnings relating to
use of console_init() and console_uninit(). Some of these relate to use
by the generic code, not the platform code. These functions are not really
deprecated but *removed* when MULTI_CONSOLE_API == 1.

This patch consolidates these warnings into a single preprocessor warning.
The __deprecated attribute is removed from the console_init() and
console_uninit() declarations.

For preprocessor warnings like this to not cause fatal build errors,
this patch adds -Wno-error=cpp to the build flags when
ERROR_DEPRECATED == 0.
This option (and -Wno-error=deprecated-declarations) is now added to
CPPFLAGS instead of TF_CFLAGS to ensure the build flags are used in the
assembler as well as the compiler.

This patch also disentangles the MULTI_CONSOLE_API and ERROR_DEPRECATED
build flags by defaulting MULTI_CONSOLE_API to 0 instead of
ERROR_DEPRECATED. This allows platforms that have not migrated to
MULTI_CONSOLE_API to use ERROR_DEPRECATED == 1 to emit a more meaningful
build error.

Finally, this patch bans use of MULTI_CONSOLE_API == 1 and AARCH32, since
the AArch32 console implementation does not support
MULTI_CONSOLE_API == 1.

Change-Id: If762165ddcb90c28aa7a4951aba70cb15c2b709c
Signed-off-by: default avatarDan Handley <dan.handley@arm.com>
      bc1a03c7
  39. 28 Feb, 2018 1 commit
  41. 26 Feb, 2018 2 commits
    • Soby Mathew's avatar
      Makefile: Add `all` target to MAKE_DTBS · 38c14d88
      Soby Mathew authored 
      

This patch makes some minor changes to `MAKE_DTBS` make macro
and adds `dtbs` target to the `all` make target.

Change-Id: I1c5b4a603ada31d2dac2ed73da9ff707b410dd11
Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      38c14d88
    • 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
  43. 06 Feb, 2018 1 commit
  45. 01 Feb, 2018 6 commits
    • Masahiro Yamada's avatar
      plat/common: move arch-agnostic fallback functions to C file · 0fc50a86
      Masahiro Yamada authored 
      

When we add a new callback, we need to duplicate fallbacks among
plat/common/{aarch32,aarch64}/platform_helpers.S  This is tedious.

I created a new C file, then moved 3 functions:
  plat_error_handler
  bl2_plat_preload_setup
  plat_try_next_boot_source

They are called from C, so I do not see a good reason to implement
them in assembly.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0fc50a86
    • Masahiro Yamada's avatar
      Build: change the first parameter of TOOL_ADD_IMG to lowercase · 33950dd8
      Masahiro Yamada authored 
      

In the next commit, I need the image name in lowercase because
output files are generally named in lowercase.

Unfortunately, TOOL_ADD_IMG takes the first argument in uppercase
since we generally use uppercase Make variables.

make_helpers/build_macros.mk provides 'uppercase' macro to convert
a string into uppercase, but 'lowercase' does not exist.  We can
implement it if we like, but it would be more straightforward to
change the argument of TOOL_ADD_IMG.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      33950dd8
    • Masahiro Yamada's avatar
      Build: rename FIP_ADD_IMG to TOOL_ADD_IMG · c939d13a
      Masahiro Yamada authored 
      

Now FIP_ADD_IMG takes care of both fiptool and cert_create
symmetrically.  Rename it so that it matches the behavior.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      c939d13a
    • Masahiro Yamada's avatar
      Build: merge build macros between FIP_ and FWU_FIP_ · 1dc0714f
      Masahiro Yamada authored 
      

The build system supports generating two FIP images, fip and fwu_fip.
Accordingly, we have similar build macros.

   FIP_ADD_PAYLOAD   <-->  FWU_FIP_ADD_PAYLOAD
   CERT_ADD_CMD_OPT  <-->  FWU_CERT_ADD_CMD_OPT
   FIP_ADD_IMG       <-->  FWU_FIP_ADD_IMG

The duplicated code increases the maintenance burden.  Also, the build
rule of BL2U looks clumsy - we want to call MAKE_BL to compile it from
source files, but we want to put it in fwu_fip.  We can not do it in a
single macro call since the current MAKE_BL does not support fwu_fip.

To refactor those in a clean way is to support one more argument to
specify the FIP prefix.  If it is empty, the images are targeted to
fip, whereas if the argument is "FWU_", targeted to fwu_fip.

The build macros prefixed with FWU_ go away.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      1dc0714f
    • Masahiro Yamada's avatar
      Build: refactor BL32 build rules · 9cd15239
      Masahiro Yamada authored 
      This complicated if-conditional combo was introduced by commit
70d1fc53

 ("Fix build error when `BL32` is not defined") in order
to fix the compile error of "make all" when SPD=opteed is given.

The requirement for the build system is like follows:

 - If both BL32 and BL32_SOURCES are defined, the former takes
   precedence.

 - If BL32 is undefined but BL32_SOURCES is defined, we compile
   BL32 from the source files.

 - We want to let the build fail if neither of them is defined,
   but we want to check it only when we are building FIP.

Refactor the code to not call FIP_ADD_IMG twice.  The behavior is
still the same.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      9cd15239
    • Masahiro Yamada's avatar
      Build: replace $(call MAKE_TOOL_ARGS,...) with $(call FIP_ADD_IMG,...) · 76d27d24
      Masahiro Yamada authored 
      

We use $(call MAKE_TOOL_ARGS,...) or $(call FIP_ADD_IMG,...) where we
expect externally built images.  The difference between the two is
check_* target.  It now checks if the given path exists, so it is a
good thing to use $(call FIP_ADD_IMG,...) in all the places.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      76d27d24