1. 03 May, 2017 1 commit
  2. 05 Dec, 2016 1 commit
    • Jeenu Viswambharan's avatar
      Define and use no_ret macro where no return is expected · a806dad5
      Jeenu Viswambharan authored
      
      
      There are many instances in ARM Trusted Firmware where control is
      transferred to functions from which return isn't expected. Such jumps
      are made using 'bl' instruction to provide the callee with the location
      from which it was jumped to. Additionally, debuggers infer the caller by
      examining where 'lr' register points to. If a 'bl' of the nature
      described above falls at the end of an assembly function, 'lr' will be
      left pointing to a location outside of the function range. This misleads
      the debugger back trace.
      
      This patch defines a 'no_ret' macro to be used when jumping to functions
      from which return isn't expected. The macro ensures to use 'bl'
      instruction for the jump, and also, for debug builds, places a 'nop'
      instruction immediately thereafter (unless instructed otherwise) so as
      to leave 'lr' pointing within the function range.
      
      Change-Id: Ib34c69fc09197cfd57bc06e147cc8252910e01b0
      Co-authored-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      a806dad5
  3. 18 Jul, 2016 1 commit
    • Soby Mathew's avatar
      Rework type usage in Trusted Firmware · 4c0d0390
      Soby Mathew authored
      This patch reworks type usage in generic code, drivers and ARM platform files
      to make it more portable. The major changes done with respect to
      type usage are as listed below:
      
      * Use uintptr_t for storing address instead of uint64_t or unsigned long.
      * Review usage of unsigned long as it can no longer be assumed to be 64 bit.
      * Use u_register_t for register values whose width varies depending on
        whether AArch64 or AArch32.
      * Use generic C types where-ever possible.
      
      In addition to the above changes, this patch also modifies format specifiers
      in print invocations so that they are AArch64/AArch32 agnostic. Only files
      related to upcoming feature development have been reworked.
      
      Change-Id: I9f8c78347c5a52ba7027ff389791f1dad63ee5f8
      4c0d0390
  4. 13 Apr, 2016 1 commit
    • Soby Mathew's avatar
      Migrate platform ports to the new xlat_tables library · 3e4b8fdc
      Soby Mathew authored
      This patch modifies the upstream platform port makefiles to use the new
      xlat_tables library files. This patch also makes mmap region setup common
      between AArch64 and AArch32 for FVP platform port. The file `fvp_common.c`
      is moved from the `plat/arm/board/fvp/aarch64` folder to the parent folder
      as it is not specific to AArch64.
      
      Change-Id: Id2e9aac45e46227b6f83cccfd1e915404018ea0b
      3e4b8fdc
  5. 31 Mar, 2016 1 commit
    • David Wang's avatar
      Add support to load BL31 in DRAM · 4518dd9a
      David Wang authored
      This patch adds an option to the ARM common platforms to load BL31 in the
      TZC secured DRAM instead of the default secure SRAM.
      
      To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
      If TSP is present, then setting this option also sets the TSP location
      to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
      
      To use this feature, BL2 platform code must map in the DRAM used by
      BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
      Currently, only the FVP BL2 platform code maps in this DRAM.
      
      Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
      4518dd9a
  6. 14 Mar, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove all non-configurable dead loops · 1c3ea103
      Antonio Nino Diaz authored
      Added a new platform porting function plat_panic_handler, to allow
      platforms to handle unexpected error situations. It must be
      implemented in assembly as it may be called before the C environment
      is initialized. A default implementation is provided, which simply
      spins.
      
      Corrected all dead loops in generic code to call this function
      instead. This includes the dead loop that occurs at the end of the
      call to panic().
      
      All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
      been removed.
      
      Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
      1c3ea103
  7. 16 Feb, 2016 1 commit
    • Vikram Kanigiri's avatar
      Rework use of interconnect drivers · 6355f234
      Vikram Kanigiri authored
      ARM Trusted Firmware supports 2 different interconnect peripheral
      drivers: CCI and CCN. ARM platforms are implemented using either of the
      interconnect peripherals.
      
      This patch adds a layer of abstraction to help ARM platform ports to
      choose the right interconnect driver and corresponding platform support.
      This is as described below:
      
      1. A set of ARM common functions have been implemented to initialise an
      interconnect and for entering/exiting a cluster from coherency. These
      functions are prefixed as "plat_arm_interconnect_". Weak definitions of
      these functions have been provided for each type of driver.
      
      2.`plat_print_interconnect_regs` macro used for printing CCI registers is
      moved from a common arm_macros.S to cci_macros.S.
      
      3. The `ARM_CONFIG_HAS_CCI` flag used in `arm_config_flags` structure
      is renamed to `ARM_CONFIG_HAS_INTERCONNECT`.
      
      Change-Id: I02f31184fbf79b784175892d5ce1161b65a0066c
      6355f234
  8. 21 Dec, 2015 1 commit
  9. 09 Dec, 2015 4 commits
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL2U for ARM platforms · dcda29f6
      Yatharth Kochar authored
      This patch adds support for Firmware update in BL2U for ARM
      platforms such that TZC initialization is performed on all
      ARM platforms and (optionally) transfer of SCP_BL2U image on
      ARM CSS platforms.
      
      BL2U specific functions are added to handle early_platform and
      plat_arch setup. The MMU is configured to map in the BL2U
      code/data area and other required memory.
      
      Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
      dcda29f6
    • Yatharth Kochar's avatar
      FWU: Add Firmware Update support in BL1 for ARM platforms · 436223de
      Yatharth Kochar authored
      This patch adds Firmware Update support for ARM platforms.
      
      New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide
      platform specific Firmware update code.
      
      BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for
      authenticating NS_BL2U image(For both FVP and JUNO platform).
      
      Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
      436223de
    • Achin Gupta's avatar
      Rework use of ARM GIC drivers on ARM platforms · 27573c59
      Achin Gupta authored
      Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three
      separate drivers instead of providing a single driver that can work on both
      versions of the GIC architecture. These drivers correspond to the following
      software use cases:
      
      1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations
         e.g. GIC-400
      
      2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations
         e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features
      
      3. A deprecated GICv3 driver that operates in legacy mode. This driver can
         operate only in the GICv2 mode in the secure world. On a GICv3 system, this
         driver allows normal world to run in either GICv3 mode (asymmetric mode)
         or in the GICv2 mode. Both modes of operation are deprecated on GICv3
         systems.
      
      ARM platforms implement both versions of the GIC architecture. This patch adds a
      layer of abstraction to help ARM platform ports chose the right GIC driver and
      corresponding platform support. This is as described below:
      
      1. A set of ARM common functions have been introduced to initialise the GIC and
         the driver during cold and warm boot. These functions are prefixed as
         "plat_arm_gic_". Weak definitions of these functions have been provided for
         each type of driver.
      
      2. Each platform includes the sources that implement the right functions
         directly into the its makefile. The FVP can be instantiated with different
         versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option
         to specify which of the three drivers should be included in the build.
      
      3. A list of secure interrupts has to be provided to initialise each of the
        three GIC drivers. For GIC v3.0 the interrupt ids have to be further
        categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two
        types are merged and treated as Group 0 interrupts.
      
        The two lists of interrupts are exported from the platform_def.h. The lists
        are constructed by adding a list of board specific interrupt ids to a list of
        ids common to all ARM platforms and Compute sub-systems.
      
      This patch also makes some fields of `arm_config` data structure in FVP redundant
      and these unused fields are removed.
      
      Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
      27573c59
    • Soby Mathew's avatar
      Prepare platforms to use refactored ARM GIC drivers · f14d1886
      Soby Mathew authored
      This patch adds platform helpers for the new GICv2 and GICv3 drivers in
      plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate
      file in their build according to the GIC driver to be used. The existing
      plat_gic.c is only meant for the legacy GIC driver.
      
      In the case of ARM platforms, the major changes are as follows:
      
      1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU
         interface register values has been modified to detect the type of CPU
         interface being used (System register or memory mappped interface) before
         using the right interface to print the registers.
      
      2. The power management helper function that is called after a core is powered
         up has been further refactored. This is to highlight that the per-cpu
         distributor interface should be initialised only when the core was originally
         powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API
         was used.
      
      3. In the case of CSS platforms, the system power domain restore helper
         `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish`
         handler as the system power domain is always expected to be initialized when
         the `on_finish` handler is invoked.
      
      Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
      f14d1886
  10. 02 Dec, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add Trusted Watchdog support on ARM platforms · 7b4c1405
      Juan Castillo authored
      This patch adds watchdog support on ARM platforms (FVP and Juno).
      A secure instance of SP805 is used as Trusted Watchdog. It is
      entirely managed in BL1, being enabled in the early platform setup
      hook and disabled in the exit hook. By default, the watchdog is
      enabled in every build (even when TBB is disabled).
      
      A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
      has been introduced to allow the user to disable the watchdog at
      build time. This feature may be used for testing or debugging
      purposes.
      
      Specific error handlers for Juno and FVP are also provided in this
      patch. These handlers will be called after an image load or
      authentication error. On FVP, the Table of Contents (ToC) in the FIP
      is erased. On Juno, the corresponding error code is stored in the
      V2M Non-Volatile flags register. In both cases, the CPU spins until
      a watchdog reset is generated after 256 seconds (as specified in
      the TBBR document).
      
      Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
      7b4c1405
  11. 26 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      FVP: Do not power off secondary CPUs when booting an EL3 payload · cdf14088
      Sandrine Bailleux authored
      Normally, in the FVP port, secondary CPUs are immediately powered
      down if they are powered on at reset. However, when booting an EL3
      payload, we need to keep them powered on as the requirement is for
      all CPUs to enter the EL3 payload image. This patch puts them in a
      holding pen instead of powering them off.
      
      Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
      cdf14088
  12. 20 Oct, 2015 1 commit
    • Soby Mathew's avatar
      Reorganise PSCI PM handler setup on ARM Standard platforms · 785fb92b
      Soby Mathew authored
      This patch does the following reorganization to psci power management (PM)
      handler setup for ARM standard platform ports :
      
      1. The mailbox programming required during `plat_setup_psci_ops()` is identical
         for all ARM platforms. Hence the implementation of this API is now moved
         to the common `arm_pm.c` file. Each ARM platform now must define the
         PLAT_ARM_TRUSTED_MAILBOX_BASE macro, which in current platforms is the same
         as ARM_SHARED_RAM_BASE.
      
      2. The PSCI PM handler callback structure, `plat_psci_ops`, must now be
         exported via `plat_arm_psci_pm_ops`. This allows the common implementation
         of `plat_setup_psci_ops()` to return a platform specific `plat_psci_ops`.
         In the case of CSS platforms, a default weak implementation of the same is
         provided in `css_pm.c` which can be overridden by each CSS platform.
      
      3. For CSS platforms, the PSCI PM handlers defined in `css_pm.c` are now
         made library functions and a new header file `css_pm.h` is added to export
         these generic PM handlers. This allows the platform to reuse the
         adequate CSS PM handlers and redefine others which need to be customized
         when overriding the default `plat_arm_psci_pm_ops` in `css_pm.c`.
      
      Change-Id: I277910f609e023ee5d5ff0129a80ecfce4356ede
      785fb92b
  13. 01 Sep, 2015 1 commit
    • Vikram Kanigiri's avatar
      Configure all secure interrupts on ARM platforms · a7270d35
      Vikram Kanigiri authored
      ARM TF configures all interrupts as non-secure except those which
      are present in irq_sec_array. This patch updates the irq_sec_array
      with the missing secure interrupts for ARM platforms.
      
      It also updates the documentation to be inline with the latest
      implementation.
      
      Fixes ARM-software/tf-issues#312
      
      Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
      a7270d35
  14. 13 Aug, 2015 4 commits
    • Soby Mathew's avatar
      PSCI: Add documentation and fix plat_is_my_cpu_primary() · 58523c07
      Soby Mathew authored
      This patch adds the necessary documentation updates to porting_guide.md
      for the changes in the platform interface mandated as a result of the new
      PSCI Topology and power state management frameworks. It also adds a
      new document `platform-migration-guide.md` to aid the migration of existing
      platform ports to the new API.
      
      The patch fixes the implementation and callers of
      plat_is_my_cpu_primary() to use w0 as the return parameter as implied by
      the function signature rather than x0 which was used previously.
      
      Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b
      58523c07
    • Sandrine Bailleux's avatar
      PSCI: Pool platform_mem_init() in common ARM platforms code · a6bd5ffb
      Sandrine Bailleux authored
      Now that the FVP mailbox is no longer zeroed, the function
      platform_mem_init() does nothing both on FVP and on Juno. Therefore,
      this patch pools it as the default implementation on ARM platforms.
      
      Change-Id: I007220f4531f15e8b602c3368a1129a5e3a38d91
      a6bd5ffb
    • Sandrine Bailleux's avatar
      PSCI: Use a single mailbox for warm reset for FVP and Juno · 804040d1
      Sandrine Bailleux authored
      Since there is a unique warm reset entry point, the FVP and Juno
      port can use a single mailbox instead of maintaining one per core.
      The mailbox gets programmed only once when plat_setup_psci_ops()
      is invoked during PSCI initialization. This means mailbox is not
      zeroed out during wakeup.
      
      Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
      804040d1
    • Soby Mathew's avatar
      PSCI: Migrate ARM reference platforms to new platform API · 38dce70f
      Soby Mathew authored
      This patch migrates ARM reference platforms, Juno and FVP, to the new platform
      API mandated by the new PSCI power domain topology and composite power state
      frameworks. The platform specific makefiles now exports the build flag
      ENABLE_PLAT_COMPAT=0 to disable the platform compatibility layer.
      
      Change-Id: I3040ed7cce446fc66facaee9c67cb54a8cd7ca29
      38dce70f
  15. 25 Jun, 2015 1 commit
    • Juan Castillo's avatar
      TBB: add platform API to read the ROTPK information · 95cfd4ad
      Juan Castillo authored
      This patch extends the platform port by adding an API that returns
      either the Root of Trust public key (ROTPK) or its hash. This is
      usually stored in ROM or eFUSE memory. The ROTPK returned must be
      encoded in DER format according to the following ASN.1 structure:
      
          SubjectPublicKeyInfo  ::=  SEQUENCE  {
              algorithm           AlgorithmIdentifier,
              subjectPublicKey    BIT STRING
          }
      
      In case the platform returns a hash of the key:
      
          DigestInfo  ::= SEQUENCE {
              digestAlgorithm     AlgorithmIdentifier,
              keyDigest           OCTET STRING
          }
      
      An implementation for ARM development platforms is provided in this
      patch. When TBB is enabled, the ROTPK hash location must be specified
      using the build option 'ARM_ROTPK_LOCATION'. Available options are:
      
          - 'regs' : return the ROTPK hash stored in the Trusted
            root-key storage registers.
      
          - 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
            BL2 binaries. This hash has been obtained from the development
            RSA public key located in 'plat/arm/board/common/rotpk'.
      
      On FVP, the number of MMU tables has been increased to map and
      access the ROTPK registers.
      
      A new file 'board_common.mk' has been added to improve code sharing
      in the ARM develelopment platforms.
      
      Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
      95cfd4ad
  16. 03 Jun, 2015 1 commit
  17. 28 Apr, 2015 1 commit
    • Dan Handley's avatar
      Move FVP port to plat/arm/board/fvp · 3fc4124c
      Dan Handley authored
      Move the FVP port from plat/fvp to plat/arm/board/fvp. Also rename
      some of the files so they are consistently prefixed with fvp_.
      Update the platform makefiles accordingly.
      
      Change-Id: I7569affc3127d66405f1548fc81b878a858e61b7
      3fc4124c