1. 25 Jul, 2016 1 commit
    • Antonio Nino Diaz's avatar
      ARM platforms: Define common image sizes · 0289970d
      Antonio Nino Diaz authored
      Compile option `ARM_BOARD_OPTIMISE_MMAP` has been renamed to
      `ARM_BOARD_OPTIMISE_MEM` because it now applies not only to defines
      related to the translation tables but to the image size as well.
      
      The defines `PLAT_ARM_MAX_BL1_RW_SIZE`, `PLAT_ARM_MAX_BL2_SIZE` and
      `PLAT_ARM_MAX_BL31_SIZE` have been moved to the file board_arm_def.h.
      This way, ARM platforms no longer have to set their own values if
      `ARM_BOARD_OPTIMISE_MEM=0` and they can specify optimized values
      otherwise. The common sizes have been set to the highest values used
      for any of the current build configurations.
      
      This is needed because in some build configurations some images are
      running out of space. This way there is a common set of values known
      to work for all of them and it can be optimized for each particular
      platform if needed.
      
      The space reserved for BL2 when `TRUSTED_BOARD_BOOT=0` has been
      increased. This is needed because when memory optimisations are
      disabled the values for Juno of `PLAT_ARM_MMAP_ENTRIES` and
      `MAX_XLAT_TABLES` are higher. If in this situation the code is
      compiled in debug mode and with "-O0", the code won't fit.
      
      Change-Id: I70a3d8d3a0b0cad1d6b602c01a7ea334776e718e
      0289970d
  2. 18 Jul, 2016 5 commits
  3. 15 Jul, 2016 4 commits
  4. 12 Jul, 2016 1 commit
  5. 11 Jul, 2016 1 commit
  6. 08 Jul, 2016 14 commits
    • Sandrine Bailleux's avatar
      ARM CSS platforms: Map flash as execute-never by default · 91fad655
      Sandrine Bailleux authored
      On ARM CSS platforms, the whole flash used to be mapped as executable.
      This is not required, given that the flash is used to store the BL1
      and FIP images and:
      
       - The FIP is not executed in place, its images are copied to RAM
         and executed from there.
      
       - BL1 is executed in place from flash but only its code needs to be
         mapped as executable and platform code takes care of re-mapping
         BL1's read-only section as executable.
      
      Therefore, this patch now maps the flash as non-executable by default
      on these platforms. This increases security by restricting the
      executable region to what is strictly needed.
      
      This patch also adds some comments to clarify the memory mapping
      attributes on these platforms.
      
      Change-Id: I4db3c145508bea1f43fbe0f6dcd551e1aec1ecd3
      91fad655
    • Sandrine Bailleux's avatar
      Add some verbose traces in arm_setup_page_tables() · 84aaf559
      Sandrine Bailleux authored
      This patch adds some verbose traces in the arm_setup_page_tables()
      function to print the extents of the different memory regions it maps.
      
      Change-Id: Ia3ae1053e7ebf3579601ff9238b0e3791eb1e9e4
      84aaf559
    • Sandrine Bailleux's avatar
      ARM platforms: Add support for SEPARATE_CODE_AND_RODATA · 0af559a8
      Sandrine Bailleux authored
      The arm_setup_page_tables() function used to expect a single set of
      addresses defining the extents of the whole read-only section, code
      and read-only data mixed up, which was mapped as executable.
      
      This patch changes this behaviour. arm_setup_page_tables() now
      expects 2 separate sets of addresses:
      
       - the extents of the code section;
       - the extents of the read-only data section.
      
      The code is mapped as executable, whereas the data is mapped as
      execute-never. New #defines have been introduced to identify the
      extents of the code and the read-only data section. Given that
      all BL images except BL1 share the same memory layout and linker
      script structure, these #defines are common across these images.
      The slight memory layout differences in BL1 have been handled by
      providing values specific to BL1.
      
      Note that this patch also affects the Xilinx platform port, which
      uses the arm_setup_page_tables() function. It has been updated
      accordingly, such that the memory mappings on this platform are
      unchanged. This is achieved by passing null values as the extents
      of the read-only data section so that it is ignored. As a result,
      the whole read-only section is still mapped as executable.
      
      Fixes ARM-software/tf-issues#85
      
      Change-Id: I1f95865c53ce6e253a01286ff56e0aa1161abac5
      0af559a8
    • Sandrine Bailleux's avatar
      ARM platforms: Include BL2U's RO section in total memory region · b2c96eed
      Sandrine Bailleux authored
      This patch changes the base address of the "total" Trusted SRAM region
      seen by the BL2U image. It used to start just after BL2U's read-only
      section (i.e. at address BL2U_RO_LIMIT), it now starts from the base
      address of the BL2U image (i.e. at address BL2U_BASE). In other words,
      the "total" memory region now includes BL2U's own read-only section.
      
      This does not change BL2U's resulting memory mappings because the
      read-only section was already mapped in BL2U, it just wasn't part of
      this total memory region.
      
      Change-Id: I2da16ac842469023b41904eaa8d13ed678d65671
      b2c96eed
    • Sandrine Bailleux's avatar
      ARM platforms: Restrict mapping of Trusted ROM in BL1 · af419dd6
      Sandrine Bailleux authored
      At the moment, on ARM platforms, BL1 maps everything from BL1_RO_BASE
      to BL1_RO_LIMIT. BL1_RO_LIMIT, as defined in the porting guide, is
      the maximum address in Trusted ROM that BL1's actual content _can_
      occupy. The actual portion of ROM occupied by BL1 can be less than
      that, which means that BL1 might map more Trusted ROM than it actually
      needs to.
      
      This patch changes BL1's memory mappings on ARM platforms to restrict
      the region of Trusted ROM it maps. It uses the symbols exported by
      the linker to figure out the actual extents of BL1's ROM footprint.
      
      This change increases the number of page tables used on FVP by 1.
      On FVP, we used to map the whole Trusted ROM. As it is 64MB large,
      we used to map it as blocks of 2MB using level-2 translation table
      entries. We now need a finer-grained mapping, which requires an
      additional level-3 translation table.
      
      On ARM CSS platforms, the number of translation tables is unchanged.
      The BL1 image resides in flash at address 0x0BEC0000. This address is
      not aligned on a 2MB-boundary so a level-3 translation table was
      already required to map this memory.
      
      Change-Id: I317a93fd99c40e70d0f13cc3d7a570f05c6c61eb
      af419dd6
    • Sandrine Bailleux's avatar
      TSP: Print BL32_BASE rather than __RO_START__ · a604623c
      Sandrine Bailleux authored
      In debug builds, the TSP prints its image base address and size.
      The base address displayed corresponds to the start address of the
      read-only section, as defined in the linker script.
      
      This patch changes this to use the BL32_BASE address instead, which is
      the same address as __RO_START__ at the moment but has the advantage
      to be independent of the linker symbols defined in the linker script
      as well as the layout and order of the sections.
      
      Change-Id: I032d8d50df712c014cbbcaa84a9615796ec902cc
      a604623c
    • Sandrine Bailleux's avatar
      Introduce SEPARATE_CODE_AND_RODATA build flag · 5d1c104f
      Sandrine Bailleux authored
      At the moment, all BL images share a similar memory layout: they start
      with their code section, followed by their read-only data section.
      The two sections are contiguous in memory. Therefore, the end of the
      code section and the beginning of the read-only data one might share
      a memory page. This forces both to be mapped with the same memory
      attributes. As the code needs to be executable, this means that the
      read-only data stored on the same memory page as the code are
      executable as well. This could potentially be exploited as part of
      a security attack.
      
      This patch introduces a new build flag called
      SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
      on separate memory pages. This in turn allows independent control of
      the access permissions for the code and read-only data.
      
      This has an impact on memory footprint, as padding bytes need to be
      introduced between the code and read-only data to ensure the
      segragation of the two. To limit the memory cost, the memory layout
      of the read-only section has been changed in this case.
      
       - When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
         the read-only section still looks like this (padding omitted):
      
         |        ...        |
         +-------------------+
         | Exception vectors |
         +-------------------+
         |  Read-only data   |
         +-------------------+
         |       Code        |
         +-------------------+ BLx_BASE
      
         In this case, the linker script provides the limits of the whole
         read-only section.
      
       - When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
         read-only data are swapped, such that the code and exception
         vectors are contiguous, followed by the read-only data. This
         gives the following new layout (padding omitted):
      
         |        ...        |
         +-------------------+
         |  Read-only data   |
         +-------------------+
         | Exception vectors |
         +-------------------+
         |       Code        |
         +-------------------+ BLx_BASE
      
         In this case, the linker script now exports 2 sets of addresses
         instead: the limits of the code and the limits of the read-only
         data. Refer to the Firmware Design guide for more details. This
         provides platform code with a finer-grained view of the image
         layout and allows it to map these 2 regions with the appropriate
         access permissions.
      
      Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
      
      Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
      5d1c104f
    • Sandrine Bailleux's avatar
      Introduce round_up/down() macros · 0146ae64
      Sandrine Bailleux authored
      This patch introduces the round_up() and round_down() macros,
      which round up (respectively down) a value to a given boundary.
      The boundary must be a power of two.
      
      Change-Id: I589dd1074aeb5ec730dd523b4ebf098d55a7e967
      0146ae64
    • Sandrine Bailleux's avatar
      Introduce utils.h header file · ed81f3eb
      Sandrine Bailleux authored
      This patch introduces a new header file: include/lib/utils.h.
      Its purpose is to provide generic macros and helper functions that
      are independent of any BL image, architecture, platform and even
      not specific to Trusted Firmware.
      
      For now, it contains only 2 macros: ARRAY_SIZE() and
      IS_POWER_OF_TWO(). These were previously defined in bl_common.h and
      xlat_tables.c respectively.
      
      bl_common.h includes utils.h to retain compatibility for platforms
      that relied on bl_common.h for the ARRAY_SIZE() macro. Upstream
      platform ports that use this macro have been updated to include
      utils.h.
      
      Change-Id: I960450f54134f25d1710bfbdc4184f12c049a9a9
      ed81f3eb
    • Sandrine Bailleux's avatar
      BL1: Add linker symbol identifying end of ROM content · c02fcc4a
      Sandrine Bailleux authored
      This patch adds a new linker symbol in BL1's linker script named
      '__BL1_ROM_END__', which marks the end of BL1's ROM content. This
      covers BL1's code, read-only data and read-write data to relocate
      in Trusted SRAM. The address of this new linker symbol is exported
      to C code through the 'BL1_ROM_END' macro.
      
      The section related to linker symbols in the Firmware Design guide
      has been updated and improved.
      
      Change-Id: I5c442ff497c78d865ffba1d7d044511c134e11c7
      c02fcc4a
    • Sandrine Bailleux's avatar
      xlat lib: Introduce MT_EXECUTE/MT_EXECUTE_NEVER attributes · b9161469
      Sandrine Bailleux authored
      This patch introduces the MT_EXECUTE/MT_EXECUTE_NEVER memory mapping
      attributes in the translation table library to specify the
      access permissions for instruction execution of a memory region.
      These new attributes should be used only for normal, read-only
      memory regions. For other types of memory, the translation table
      library still enforces the following rules, regardless of the
      MT_EXECUTE/MT_EXECUTE_NEVER attribute:
      
       - Device memory is always marked as execute-never.
       - Read-write normal memory is always marked as execute-never.
      
      Change-Id: I8bd27800a8c1d8ac1559910caf4a4840cf25b8b0
      b9161469
    • Sandrine Bailleux's avatar
      xlat lib: Refactor mmap_desc() function · bcbe19af
      Sandrine Bailleux authored
      This patch clarifies the mmap_desc() function by adding some comments
      and reorganising its code. No functional change has been introduced.
      
      Change-Id: I873493be17b4e60a89c1dc087dd908b425065401
      bcbe19af
    • Sandrine Bailleux's avatar
      Introduce arm_setup_page_tables() function · b5fa6563
      Sandrine Bailleux authored
      This patch introduces the arm_setup_page_tables() function to
      set up page tables on ARM platforms. It replaces the
      arm_configure_mmu_elx() functions and does the same thing except
      that it doesn't enable the MMU at the end. The idea is to reduce
      the amount of per-EL code that is generated by the C preprocessor
      by splitting the memory regions definitions and page tables creation
      (which is generic) from the MMU enablement (which is the only per-EL
      configuration).
      
      As a consequence, the call to the enable_mmu_elx() function has been
      moved up into the plat_arch_setup() hook. Any other ARM standard
      platforms that use the functions `arm_configure_mmu_elx()` must be
      updated.
      
      Change-Id: I6f12a20ce4e5187b3849a8574aac841a136de83d
      b5fa6563
    • Soby Mathew's avatar
      Derive stack alignment from CACHE_WRITEBACK_GRANULE · 663db206
      Soby Mathew authored
      The per-cpu stacks should be aligned to the cache-line size and
      the `declare_stack` helper in asm_macros.S macro assumed a
      cache-line size of 64 bytes. The platform defines the cache-line
      size via CACHE_WRITEBACK_GRANULE macro. This patch modifies
      `declare_stack` helper macro to derive stack alignment from the
      platform defined macro.
      
      Change-Id: I1e1b00fc8806ecc88190ed169f4c8d3dd25fe95b
      663db206
  7. 07 Jul, 2016 1 commit
    • Soby Mathew's avatar
      GIC: Ensure SGIs and PPIs are Group0 before setup · 47c6876a
      Soby Mathew authored
      The legacy GIC driver assumes that the SGIs and PPIs are Group0 during
      initialization. This is true if the driver is the first one to initialize
      the GIC hardware after reset. But in some cases, earlier BL stages could
      have already initialized the GIC hardware which means that SGI and PPI
      configuration are not the expected reset values causing assertion failure
      in `gicd_set_ipriorityr()`. This patch explicitly resets the SGI and PPI
      to Group0 prior to their initialization in the driver. The same patch is
      not done in the GICv2-only driver because unlike in the legacy driver,
      `gicd_set_ipriorityr()` of GICv2 driver doesn't enforce this policy and
      the appropriate group is set irrespective of the initial value.
      
      Fixes ARM-software/tf-issues#396
      
      Change-Id: I521d35caa37470ce542c796c2ba99716e4763105
      47c6876a
  8. 06 Jul, 2016 1 commit
  9. 05 Jul, 2016 1 commit
    • Yatharth Kochar's avatar
      Fix `cert_create` tool for Segmentation fault · f16db56a
      Yatharth Kochar authored
      With the introduction of commit `96103d5a`, the Certificate
      Generation tool is not able to generate FWU certificate and
      while doing so it does segmentation fault.
      
      This happens because it is now required to pass non-volatile
      counter values to the `cert_create` tool from the command line
      for creating the trusted firmware certificates.
      
      But in case of creating FWU certificate these counter values are not
      being passed to the tool and as a consequence the `cert_create` tool
      try to use the NULL argument and errors out with Segmentation fault.
      
      This patch fixes this issue by providing a check before using the
      command line argument passed in the case of `EXT_TYPE_NVCOUNTER`
      certificate extension.
      
      Change-Id: Ie17d0c1502b52aaa8500f3659c2da2448ab0347a
      f16db56a
  10. 04 Jul, 2016 2 commits
  11. 16 Jun, 2016 3 commits
    • Soby Mathew's avatar
      Enable PSCI_STAT_COUNT/RESIDENCY for ARM standard platforms · d75f2578
      Soby Mathew authored
      This patch enables optional PSCI functions `PSCI_STAT_COUNT` and
      `PSCI_STAT_RESIDENCY` for ARM standard platforms. The optional platform
      API 'translate_power_state_by_mpidr()' is implemented for the Juno
      platform. 'validate_power_state()' on Juno downgrades PSCI CPU_SUSPEND
      requests for the system power level to the cluster power level.
      Hence, it is not suitable for validating the 'power_state' parameter
      passed in a PSCI_STAT_COUNT/RESIDENCY call.
      
      Change-Id: I9548322676fa468d22912392f2325c2a9f96e4d2
      d75f2578
    • Yatharth Kochar's avatar
      Add optional PSCI STAT residency & count functions · 170fb93d
      Yatharth Kochar authored
      This patch adds following optional PSCI STAT functions:
      
      - PSCI_STAT_RESIDENCY: This call returns the amount of time spent
        in power_state in microseconds, by the node represented by the
        `target_cpu` and the highest level of `power_state`.
      
      - PSCI_STAT_COUNT: This call returns the number of times a
        `power_state` has been used by the node represented by the
        `target_cpu` and the highest power level of `power_state`.
      
      These APIs provides residency statistics for power states that has
      been used by the platform. They are implemented according to v1.0
      of the PSCI specification.
      
      By default this optional feature is disabled in the PSCI
      implementation. To enable it, set the boolean flag
      `ENABLE_PSCI_STAT` to 1. This also sets `ENABLE_PMF` to 1.
      
      Change-Id: Ie62e9d37d6d416ccb1813acd7f616d1ddd3e8aff
      170fb93d
    • Yatharth Kochar's avatar
      Add Performance Measurement Framework(PMF) · a31d8983
      Yatharth Kochar authored
      This patch adds Performance Measurement Framework(PMF) in the
      ARM Trusted Firmware. PMF is implemented as a library and the
      SMC interface is provided through ARM SiP service.
      
      The PMF provides capturing, storing, dumping and retrieving the
      time-stamps, by enabling the development of services by different
      providers, that can be easily integrated into ARM Trusted Firmware.
      The PMF capture and retrieval APIs can also do appropriate cache
      maintenance operations to the timestamp memory when the caller
      indicates so.
      
      `pmf_main.c` consists of core functions that implement service
      registration, initialization, storing, dumping and retrieving
      the time-stamp.
      `pmf_smc.c` consists SMC handling for registered PMF services.
      `pmf.h` consists of the macros that can be used by the PMF service
      providers to register service and declare time-stamp functions.
      `pmf_helpers.h` consists of internal macros that are used by `pmf.h`
      
      By default this feature is disabled in the ARM trusted firmware.
      To enable it set the boolean flag `ENABLE_PMF` to 1.
      
      NOTE: The caller is responsible for specifying the appropriate cache
      maintenance flags and for acquiring/releasing appropriate locks
      before/after capturing/retrieving the time-stamps.
      
      Change-Id: Ib45219ac07c2a81b9726ef6bd9c190cc55e81854
      a31d8983
  12. 15 Jun, 2016 2 commits
  13. 13 Jun, 2016 4 commits