1. 08 Nov, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Standardise header guards across codebase · c3cf06f1
      Antonio Nino Diaz authored
      
      
      All identifiers, regardless of use, that start with two underscores are
      reserved. This means they can't be used in header guards.
      
      The style that this project is now to use the full name of the file in
      capital letters followed by 'H'. For example, for a file called
      "uart_example.h", the header guard is UART_EXAMPLE_H.
      
      The exceptions are files that are imported from other projects:
      
      - CryptoCell driver
      - dt-bindings folders
      - zlib headers
      
      Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c3cf06f1
  2. 04 Oct, 2018 1 commit
  3. 28 Sep, 2018 5 commits
  4. 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
  6. 24 Jul, 2018 1 commit
  7. 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
  8. 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
  9. 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
  10. 28 Feb, 2018 2 commits
  11. 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
  12. 01 Feb, 2018 2 commits
  13. 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
  14. 13 Nov, 2017 2 commits
  15. 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
  16. 24 Oct, 2017 1 commit
  17. 16 Oct, 2017 10 commits
  18. 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
  19. 03 May, 2017 1 commit
  20. 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
  21. 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