1. 12 Jan, 2016 1 commit
  2. 05 Aug, 2015 1 commit
  3. 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
  4. 13 Apr, 2015 1 commit
    • Soby Mathew's avatar
      Fix recursive crash prints on FVP AEM model · 6fa11a5e
      Soby Mathew authored
      This patch fixes an issue in the cpu specific register reporting
      of FVP AEM model whereby crash reporting itself triggers an exception
      thus resulting in recursive crash prints. The input to the
      'size_controlled_print' in the crash reporting framework should
      be a NULL terminated string. As there were no cpu specific register
      to be reported on FVP AEM model, the issue was caused by passing 0
      instead of NULL terminated string to the above mentioned function.
      
      Change-Id: I664427b22b89977b389175dfde84c815f02c705a
      6fa11a5e
  5. 08 Apr, 2015 1 commit
    • Kévin Petit's avatar
      Add support to indicate size and end of assembly functions · 8b779620
      Kévin Petit authored
      
      
      In order for the symbol table in the ELF file to contain the size of
      functions written in assembly, it is necessary to report it to the
      assembler using the .size directive.
      
      To fulfil the above requirements, this patch introduces an 'endfunc'
      macro which contains the .endfunc and .size directives. It also adds
      a .func directive to the 'func' assembler macro.
      
      The .func/.endfunc have been used so the assembler can fail if
      endfunc is omitted.
      
      Fixes ARM-Software/tf-issues#295
      
      Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc
      Signed-off-by: default avatarKévin Petit <kevin.petit@arm.com>
      8b779620
  6. 18 Mar, 2015 1 commit
  7. 13 Mar, 2015 1 commit
    • Vikram Kanigiri's avatar
      Initialise cpu ops after enabling data cache · 12e7c4ab
      Vikram Kanigiri authored
      The cpu-ops pointer was initialized before enabling the data cache in the cold
      and warm boot paths. This required a DCIVAC cache maintenance operation to
      invalidate any stale cache lines resident in other cpus.
      
      This patch moves this initialization to the bl31_arch_setup() function
      which is always called after the data cache and MMU has been enabled.
      
      This change removes the need:
       1. for the DCIVAC cache maintenance operation.
       2. to initialise the CPU ops upon resumption from a PSCI CPU_SUSPEND
          call since memory contents are always preserved in this case.
      
      Change-Id: Ibb2fa2f7460d1a1f1e721242025e382734c204c6
      12e7c4ab
  8. 30 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Fix the Cortex-A57 reset handler register usage · 683f788f
      Soby Mathew authored
      The CPU specific reset handlers no longer have the freedom
      of using any general purpose register because it is being invoked
      by the BL3-1 entry point in addition to BL1. The Cortex-A57 CPU
      specific reset handler was overwriting x20 register which was being
      used by the BL3-1 entry point to save the entry point information.
      This patch fixes this bug by reworking the register allocation in the
      Cortex-A57 reset handler to avoid using x20. The patch also
      explicitly mentions the register clobber list for each of the
      callee functions invoked by the reset handler
      
      Change-Id: I28fcff8e742aeed883eaec8f6c4ee2bd3fce30df
      683f788f
  9. 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
  10. 13 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Invalidate the dcache after initializing cpu-ops · 09997346
      Soby Mathew authored
      This patch fixes a crash due to corruption of cpu_ops
      data structure. During the secondary CPU boot, after the
      cpu_ops has been initialized in the per cpu-data, the
      dcache lines need to invalidated so that the update in
      memory can be seen later on when the dcaches are turned ON.
      Also, after initializing the psci per cpu data, the dcache
      lines are flushed so that they are written back to memory
      and dirty dcache lines are avoided.
      
      Fixes ARM-Software/tf-issues#271
      
      Change-Id: Ia90f55e9882690ead61226eea5a5a9146d35f313
      09997346
  11. 29 Oct, 2014 4 commits
    • Soby Mathew's avatar
      Optimize Cortex-A57 cluster power down sequence on Juno · 5541bb3f
      Soby Mathew authored
      This patch optimizes the Cortex-A57 cluster power down sequence by not
      flushing the Level1 data cache. The L1 data cache and the L2 unified
      cache are inclusive. A flush of the L2 by set/way flushes any dirty
      lines from the L1 as well. This is a known safe deviation from the
      Cortex-A57 TRM defined power down sequence. This optimization can be
      enabled by the platform through the 'SKIP_A57_L1_FLUSH_PWR_DWN' build
      flag. Each Cortex-A57 based platform must make its own decision on
      whether to use the optimization.
      
      This patch also renames the cpu-errata-workarounds.md to
      cpu-specific-build-macros.md as this facilitates documentation
      of both CPU Specific errata and CPU Specific Optimization
      build macros.
      
      Change-Id: I299b9fe79e9a7e08e8a0dffb7d345f9a00a71480
      5541bb3f
    • Soby Mathew's avatar
      Optimize barrier usage during Cortex-A57 power down · b1a9631d
      Soby Mathew authored
      This the patch replaces the DSB SY with DSB ISH
      after disabling L2 prefetches during the Cortex-A57
      power down sequence.
      
      Change-Id: I048d12d830c1b974b161224eff079fb9f8ecf52d
      b1a9631d
    • Soby Mathew's avatar
      Apply errata workarounds only when major/minor revisions match. · 7395a725
      Soby Mathew authored
      Prior to this patch, the errata workarounds were applied for any version
      of the CPU in the release build and in the debug build an assert
      failure resulted when the revision did not match. This patch applies
      errata workarounds in the Cortex-A57 reset handler only if the 'variant'
      and 'revision' fields read from the MIDR_EL1 match. In the debug build,
      a warning message is printed for each errata workaround which is not
      applied.
      
      The patch modifies the register usage in 'reset_handler` so
      as to adhere to ARM procedure calling standards.
      
      Fixes ARM-software/tf-issues#242
      
      Change-Id: I51b1f876474599db885afa03346e38a476f84c29
      7395a725
    • Soby Mathew's avatar
      Add support for level specific cache maintenance operations · 8e857916
      Soby Mathew authored
      This patch adds level specific cache maintenance functions
      to cache_helpers.S. The new functions 'dcsw_op_levelx',
      where '1 <= x <= 3', allow to perform cache maintenance by
      set/way for that particular level of cache.  With this patch,
      functions to support cache maintenance upto level 3 have
      been implemented since it is the highest cache level for
      most ARM SoCs.
      
      These functions are now utilized in CPU specific power down
      sequences to implement them as mandated by processor specific
      technical reference manual.
      
      Change-Id: Icd90ce6b51cff5a12863bcda01b93601417fd45c
      8e857916
  12. 20 Aug, 2014 5 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
    • Soby Mathew's avatar
      Add platform API for reset handling · 24fb838f
      Soby Mathew authored
      This patch adds an optional platform API (plat_reset_handler) which allows the
      platform to perform any actions immediately after a cold or warm reset
      e.g. implement errata workarounds. The function is called with MMU and caches
      turned off. This API is weakly defined and does nothing by default but can be
      overriden by a platform with a strong definition.
      
      Change-Id: Ib0acdccbd24bc756528a8bd647df21e8d59707ff
      24fb838f
    • Soby Mathew's avatar
      Introduce framework for CPU specific operations · 9b476841
      Soby Mathew authored
      This patch introduces a framework which will allow CPUs to perform
      implementation defined actions after a CPU reset, during a CPU or cluster power
      down, and when a crash occurs. CPU specific reset handlers have been implemented
      in this patch. Other handlers will be implemented in subsequent patches.
      
      Also moved cpu_helpers.S to the new directory lib/cpus/aarch64/.
      
      Change-Id: I1ca1bade4d101d11a898fb30fea2669f9b37b956
      9b476841