1. 30 Jan, 2017 1 commit
    • Jeenu Viswambharan's avatar
      Report errata workaround status to console · 10bcd761
      Jeenu Viswambharan authored
      
      
      The errata reporting policy is as follows:
      
        - If an errata workaround is enabled:
      
          - If it applies (i.e. the CPU is affected by the errata), an INFO
            message is printed, confirming that the errata workaround has been
            applied.
      
          - If it does not apply, a VERBOSE message is printed, confirming
            that the errata workaround has been skipped.
      
        - If an errata workaround is not enabled, but would have applied had
          it been, a WARN message is printed, alerting that errata workaround
          is missing.
      
      The CPU errata messages are printed by both BL1 (primary CPU only) and
      runtime firmware on debug builds, once for each CPU/errata combination.
      
      Relevant output from Juno r1 console when ARM Trusted Firmware is built
      with PLAT=juno LOG_LEVEL=50 DEBUG=1:
      
        VERBOSE: BL1: cortex_a57: errata workaround for 806969 was not applied
        VERBOSE: BL1: cortex_a57: errata workaround for 813420 was not applied
        INFO:    BL1: cortex_a57: errata workaround for disable_ldnp_overread was applied
        WARNING: BL1: cortex_a57: errata workaround for 826974 was missing!
        WARNING: BL1: cortex_a57: errata workaround for 826977 was missing!
        WARNING: BL1: cortex_a57: errata workaround for 828024 was missing!
        WARNING: BL1: cortex_a57: errata workaround for 829520 was missing!
        WARNING: BL1: cortex_a57: errata workaround for 833471 was missing!
        ...
        VERBOSE: BL31: cortex_a57: errata workaround for 806969 was not applied
        VERBOSE: BL31: cortex_a57: errata workaround for 813420 was not applied
        INFO:    BL31: cortex_a57: errata workaround for disable_ldnp_overread was applied
        WARNING: BL31: cortex_a57: errata workaround for 826974 was missing!
        WARNING: BL31: cortex_a57: errata workaround for 826977 was missing!
        WARNING: BL31: cortex_a57: errata workaround for 828024 was missing!
        WARNING: BL31: cortex_a57: errata workaround for 829520 was missing!
        WARNING: BL31: cortex_a57: errata workaround for 833471 was missing!
        ...
        VERBOSE: BL31: cortex_a53: errata workaround for 826319 was not applied
        INFO:    BL31: cortex_a53: errata workaround for disable_non_temporal_hint was applied
      
      Also update documentation.
      
      Change-Id: Iccf059d3348adb876ca121cdf5207bdbbacf2aba
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      10bcd761
  2. 23 Jan, 2017 1 commit
    • Masahiro Yamada's avatar
      Use #ifdef for IMAGE_BL* instead of #if · 3d8256b2
      Masahiro Yamada authored
      
      
      One nasty part of ATF is some of boolean macros are always defined
      as 1 or 0, and the rest of them are only defined under certain
      conditions.
      
      For the former group, "#if FOO" or "#if !FOO" must be used because
      "#ifdef FOO" is always true.  (Options passed by $(call add_define,)
      are the cases.)
      
      For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
      checking the value of an undefined macro is strange.
      
      Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like
      follows:
      
        $(eval IMAGE := IMAGE_BL$(call uppercase,$(3)))
      
        $(OBJ): $(2)
                @echo "  CC      $$<"
                $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@
      
      This means, IMAGE_BL* is defined when building the corresponding
      image, but *undefined* for the other images.
      
      So, IMAGE_BL* belongs to the latter group where we should use #ifdef
      or #ifndef.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      3d8256b2
  3. 15 Dec, 2016 1 commit
    • Jeenu Viswambharan's avatar
      Add provision to extend CPU operations at more levels · 5dd9dbb5
      Jeenu Viswambharan authored
      
      
      Various CPU drivers in ARM Trusted Firmware register functions to handle
      power-down operations. At present, separate functions are registered to
      power down individual cores and clusters.
      
      This scheme operates on the basis of core and cluster, and doesn't cater
      for extending the hierarchy for power-down operations. For example,
      future CPUs might support multiple threads which might need powering
      down individually.
      
      This patch therefore reworks the CPU operations framework to allow for
      registering power down handlers on specific level basis. Henceforth:
      
        - Generic code invokes CPU power down operations by the level
          required.
      
        - CPU drivers explicitly mention CPU_NO_RESET_FUNC when the CPU has no
          reset function.
      
        - CPU drivers register power down handlers as a list: a mandatory
          handler for level 0, and optional handlers for higher levels.
      
      All existing CPU drivers are adapted to the new CPU operations framework
      without needing any functional changes within.
      
      Also update firmware design guide.
      
      Change-Id: I1826842d37a9e60a9e85fdcee7b4b8f6bc1ad043
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      5dd9dbb5
  4. 21 Sep, 2016 2 commits
    • Yatharth Kochar's avatar
      AArch32: Add support for ARM Cortex-A32 MPCore Processor · 03a3042b
      Yatharth Kochar authored
      This patch adds ARM Cortex-A32 MPCore Processor support
      in the CPU specific operations framework. It also includes
      this support for the Base FVP port.
      
      Change-Id: If3697b88678df737c29f79cf3fa1ea2cb6fa565d
      03a3042b
    • Yatharth Kochar's avatar
      AArch32: Common changes needed for BL1/BL2 · 1a0a3f06
      Yatharth Kochar authored
      This patch adds common changes to support AArch32 state in
      BL1 and BL2. Following are the changes:
      
      * Added functions for disabling MMU from Secure state.
      * Added AArch32 specific SMC function.
      * Added semihosting support.
      * Added reporting of unhandled exceptions.
      * Added uniprocessor stack support.
      * Added `el3_entrypoint_common` macro that can be
        shared by BL1 and BL32 (SP_MIN) BL stages. The
        `el3_entrypoint_common` is similar to the AArch64
        counterpart with the main difference in the assembly
        instructions and the registers that are relevant to
        AArch32 execution state.
      * Enabled `LOAD_IMAGE_V2` flag in Makefile for
        `ARCH=aarch32` and added check to make sure that
        platform has not overridden to disable it.
      
      Change-Id: I33c6d8dfefb2e5d142fdfd06a0f4a7332962e1a3
      1a0a3f06
  5. 10 Aug, 2016 1 commit
    • Soby Mathew's avatar
      AArch32: Add support in TF libraries · e33b78a6
      Soby Mathew authored
      This patch adds AArch32 support to cpu ops, context management,
      per-cpu data and spinlock libraries. The `entrypoint_info`
      structure is modified to add support for AArch32 register
      arguments. The CPU operations for AEM generic cpu in AArch32
      mode is also added.
      
      Change-Id: I1e52e79f498661d8f31f1e7b3a29e222bc7a4483
      e33b78a6
  6. 12 Jul, 2016 1 commit
  7. 01 Jun, 2016 1 commit
    • Yatharth Kochar's avatar
      Add support for ARM Cortex-A73 MPCore Processor · 2460ac18
      Yatharth Kochar authored
      This patch adds ARM Cortex-A73 MPCore Processor support
      in the CPU specific operations framework. It also includes
      this support for the Base FVP port.
      
      Change-Id: I0e26b594f2ec1d28eb815db9810c682e3885716d
      2460ac18
  8. 21 Apr, 2016 5 commits
  9. 08 Feb, 2016 1 commit
    • Sandrine Bailleux's avatar
      Disable non-temporal hint on Cortex-A53/57 · 54035fc4
      Sandrine Bailleux authored
      The LDNP/STNP instructions as implemented on Cortex-A53 and
      Cortex-A57 do not behave in a way most programmers expect, and will
      most probably result in a significant speed degradation to any code
      that employs them. The ARMv8-A architecture (see Document ARM DDI
      0487A.h, section D3.4.3) allows cores to ignore the non-temporal hint
      and treat LDNP/STNP as LDP/STP instead.
      
      This patch introduces 2 new build flags:
      A53_DISABLE_NON_TEMPORAL_HINT and A57_DISABLE_NON_TEMPORAL_HINT
      to enforce this behaviour on Cortex-A53 and Cortex-A57. They are
      enabled by default.
      
      The string printed in debug builds when a specific CPU errata
      workaround is compiled in but skipped at runtime has been
      generalised, so that it can be reused for the non-temporal hint use
      case as well.
      
      Change-Id: I3e354f4797fd5d3959872a678e160322b13867a1
      54035fc4
  10. 12 Jan, 2016 1 commit
  11. 14 Dec, 2015 1 commit
  12. 19 Nov, 2015 1 commit
    • Sandrine Bailleux's avatar
      Juno R2: Configure the correct L2 RAM latency values · 1dbe3159
      Sandrine Bailleux authored
      The default reset values for the L2 Data & Tag RAM latencies on the
      Cortex-A72 on Juno R2 are not suitable. This patch modifies
      the Juno platform reset handler to configure the right settings
      on Juno R2.
      
      Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8
      1dbe3159
  13. 24 Aug, 2015 1 commit
  14. 05 Aug, 2015 1 commit
  15. 24 Jul, 2015 1 commit
    • Varun Wadekar's avatar
      Add "Project Denver" CPU support · 3a8c55f6
      Varun Wadekar authored
      
      
      Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is
      fully ARMv8 architecture compatible.  Each of the two Denver cores
      implements a 7-way superscalar microarchitecture (up to 7 concurrent
      micro-ops can be executed per clock), and includes a 128KB 4-way L1
      instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2
      cache, which services both cores.
      
      Denver implements an innovative process called Dynamic Code Optimization,
      which optimizes frequently used software routines at runtime into dense,
      highly tuned microcode-equivalent routines. These are stored in a
      dedicated, 128MB main-memory-based optimization cache. After being read
      into the instruction cache, the optimized micro-ops are executed,
      re-fetched and executed from the instruction cache as long as needed and
      capacity allows.
      
      Effectively, this reduces the need to re-optimize the software routines.
      Instead of using hardware to extract the instruction-level parallelism
      (ILP) inherent in the code, Denver extracts the ILP once via software
      techniques, and then executes those routines repeatedly, thus amortizing
      the cost of ILP extraction over the many execution instances.
      
      Denver also features new low latency power-state transitions, in addition
      to extensive power-gating and dynamic voltage and clock scaling based on
      workloads.
      Signed-off-by: default avatarVarun Wadekar <vwadekar@nvidia.com>
      3a8c55f6
  16. 27 Apr, 2015 1 commit
    • Dan Handley's avatar
      Add header guards to asm macro files · e2bf57f8
      Dan Handley authored
      Some assembly files containing macros are included like header files
      into other assembly files. This will cause assembler errors if they
      are included multiple times.
      
      Add header guards to assembly macro files to avoid assembler errors.
      
      Change-Id: Ia632e767ed7df7bf507b294982b8d730a6f8fe69
      e2bf57f8
  17. 18 Mar, 2015 1 commit
  18. 26 Jan, 2015 1 commit
    • Yatharth Kochar's avatar
      Call reset handlers upon BL3-1 entry. · 79a97b2e
      Yatharth Kochar authored
      This patch adds support to call the reset_handler() function in BL3-1 in the
      cold and warm boot paths when another Boot ROM reset_handler() has already run.
      
      This means the BL1 and BL3-1 versions of the CPU and platform specific reset
      handlers may execute different code to each other. This enables a developer to
      perform additional actions or undo actions already performed during the first
      call of the reset handlers e.g. apply additional errata workarounds.
      
      Typically, the reset handler will be first called from the BL1 Boot ROM. Any
      additional functionality can be added to the reset handler when it is called
      from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used
      to identify whether this is the first version of the reset handler code to be
      executed or an overridden version of the code.
      
      The Cortex-A57 errata workarounds are applied only if they have not already been
      applied.
      
      Fixes ARM-software/tf-issue#275
      
      Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
      79a97b2e
  19. 21 Aug, 2014 1 commit
    • Sandrine Bailleux's avatar
      Juno: Implement initial platform port · 01b916bf
      Sandrine Bailleux authored
      This patch adds the initial port of the ARM Trusted Firmware on the Juno
      development platform. This port does not support a BL3-2 image or any PSCI APIs
      apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected
      Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno
      platform errata (Defect id 831273).
      
      Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
      01b916bf
  20. 20 Aug, 2014 3 commits
    • Soby Mathew's avatar
      Add support for selected Cortex-A57 errata workarounds · d9bdaf2d
      Soby Mathew authored
      This patch adds workarounds for selected errata which affect the Cortex-A57 r0p0
      part. Each workaround has a build time flag which should be used by the platform
      port to enable or disable the corresponding workaround. The workarounds are
      disabled by default. An assertion is raised if the platform enables a workaround
      which does not match the CPU revision at runtime.
      
      Change-Id: I9ae96b01c6ff733d04dc733bd4e67dbf77b29fb0
      d9bdaf2d
    • Soby Mathew's avatar
      Add CPU specific crash reporting handlers · d3f70af6
      Soby Mathew authored
      This patch adds handlers for dumping Cortex-A57 and Cortex-A53 specific register
      state to the CPU specific operations framework. The contents of CPUECTLR_EL1 are
      dumped currently.
      
      Change-Id: I63d3dbfc4ac52fef5e25a8cf6b937c6f0975c8ab
      d3f70af6
    • Soby Mathew's avatar
      Add CPU specific power management operations · add40351
      Soby Mathew authored
      This patch adds CPU core and cluster power down sequences to the CPU specific
      operations framework introduced in a earlier patch. Cortex-A53, Cortex-A57 and
      generic AEM sequences have been added. The latter is suitable for the
      Foundation and Base AEM FVPs. A pointer to each CPU's operations structure is
      saved in the per-cpu data so that it can be easily accessed during power down
      seqeunces.
      
      An optional platform API has been introduced to allow a platform to disable the
      Accelerator Coherency Port (ACP) during a cluster power down sequence. The weak
      definition of this function (plat_disable_acp()) does not take any action. It
      should be overriden with a strong definition if the ACP is present on a
      platform.
      
      Change-Id: I8d09bd40d2f528a28d2d3f19b77101178778685d
      add40351