1. 19 Mar, 2020 1 commit
  2. 03 Mar, 2020 1 commit
    • Max Shvetsov's avatar
      SPMD: Adds partially supported EL2 registers. · 2825946e
      Max Shvetsov authored
      
      
      This patch adds EL2 registers that are supported up to ARMv8.6.
      ARM_ARCH_MINOR has to specified to enable save/restore routine.
      
      Note: Following registers are still not covered in save/restore.
       * AMEVCNTVOFF0<n>_EL2
       * AMEVCNTVOFF1<n>_EL2
       * ICH_AP0R<n>_EL2
       * ICH_AP1R<n>_EL2
       * ICH_LR<n>_EL2
      
      Change-Id: I4813f3243e56e21cb297b31ef549a4b38d4876e1
      Signed-off-by: default avatarMax Shvetsov <maksims.svecovs@arm.com>
      2825946e
  3. 12 Feb, 2020 1 commit
  4. 03 Apr, 2019 1 commit
  5. 05 Feb, 2019 1 commit
  6. 31 Jan, 2019 1 commit
    • Stephen Wolfe's avatar
      spd: trusty: pass max affinity level to Trusty · 1ffaaec9
      Stephen Wolfe authored
      
      
      During System Suspend, the entire system loses its state. To allow Trusty
      to save/restore its context and allow its TAs to participate in the suspend
      process, it needs to look at the max affinity level being suspended. This
      patch passes the max affinity level to Trusty to enable to do so.
      
      Change-Id: If7838dae10c3f5a694baedb15ec56fbad41f2b36
      Signed-off-by: default avatarVarun Wadekar <vwadekar@nvidia.com>
      1ffaaec9
  7. 24 Jan, 2019 1 commit
  8. 23 Jan, 2019 1 commit
    • Anthony Zhou's avatar
      spd: trusty : fix defects flagged by MISRA scan · 591054a3
      Anthony Zhou authored
      
      
      Main Fixes:
      
      Use int32_t replace int [Rule 4.6]
      
      Added explicit casts (e.g. 0U) to integers in order for them to be
        compatible with whatever operation they're used in [Rule 10.1]
      
      Force operands of an operator to the same type category [Rule 10.4]
      
      Fixed if statement conditional to be essentially boolean [Rule 14.4]
      
      Voided non c-library functions whose return types are not used
      [Rule 17.7]
      
      Change-Id: I98caa330c371757eb2dfb9438448cb99115ed907
      Signed-off-by: default avatarAnthony Zhou <anzhou@nvidia.com>
      591054a3
  9. 15 Jan, 2019 1 commit
    • Paul Beesley's avatar
      Correct typographical errors · 8aabea33
      Paul Beesley authored
      
      
      Corrects typos in core code, documentation files, drivers, Arm
      platforms and services.
      
      None of the corrections affect code; changes are limited to comments
      and other documentation.
      
      Change-Id: I5c1027b06ef149864f315ccc0ea473e2a16bfd1d
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      8aabea33
  10. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  11. 18 Sep, 2018 1 commit
  12. 27 Apr, 2018 2 commits
    • Masahiro Yamada's avatar
      types: use int-ll64 for both aarch32 and aarch64 · 0a2d5b43
      Masahiro Yamada authored
      Since commit 031dbb12
      
       ("AArch32: Add essential Arch helpers"),
      it is difficult to use consistent format strings for printf() family
      between aarch32 and aarch64.
      
      For example, uint64_t is defined as 'unsigned long long' for aarch32
      and as 'unsigned long' for aarch64.  Likewise, uintptr_t is defined
      as 'unsigned int' for aarch32, and as 'unsigned long' for aarch64.
      
      A problem typically arises when you use printf() in common code.
      
      One solution could be, to cast the arguments to a type long enough
      for both architectures.  For example, if 'val' is uint64_t type,
      like this:
      
        printf("val = %llx\n", (unsigned long long)val);
      
      Or, somebody may suggest to use a macro provided by <inttypes.h>,
      like this:
      
        printf("val = %" PRIx64 "\n", val);
      
      But, both would make the code ugly.
      
      The solution adopted in Linux kernel is to use the same typedefs for
      all architectures.  The fixed integer types in the kernel-space have
      been unified into int-ll64, like follows:
      
          typedef signed char           int8_t;
          typedef unsigned char         uint8_t;
      
          typedef signed short          int16_t;
          typedef unsigned short        uint16_t;
      
          typedef signed int            int32_t;
          typedef unsigned int          uint32_t;
      
          typedef signed long long      int64_t;
          typedef unsigned long long    uint64_t;
      
      [ Linux commit: 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf ]
      
      This gets along with the codebase shared between 32 bit and 64 bit,
      with the data model called ILP32, LP64, respectively.
      
      The width for primitive types is defined as follows:
      
                         ILP32           LP64
          int            32              32
          long           32              64
          long long      64              64
          pointer        32              64
      
      'long long' is 64 bit for both, so it is used for defining uint64_t.
      'long' has the same width as pointer, so for uintptr_t.
      
      We still need an ifdef conditional for (s)size_t.
      
      All 64 bit architectures use "unsigned long" size_t, and most 32 bit
      architectures use "unsigned int" size_t.  H8/300, S/390 are known as
      exceptions; they use "unsigned long" size_t despite their architecture
      is 32 bit.
      
      One idea for simplification might be to define size_t as 'unsigned long'
      across architectures, then forbid the use of "%z" string format.
      However, this would cause a distortion between size_t and sizeof()
      operator.  We have unknowledge about the native type of sizeof(), so
      we need a guess of it anyway.  I want the following formula to always
      return 1:
      
        __builtin_types_compatible_p(size_t, typeof(sizeof(int)))
      
      Fortunately, ARM is probably a majority case.  As far as I know, all
      32 bit ARM compilers use "unsigned int" size_t.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0a2d5b43
    • Masahiro Yamada's avatar
      Fix pointer type mismatch of handlers · 57d1e5fa
      Masahiro Yamada authored
      Commit 4c0d0390
      
       ("Rework type usage in Trusted Firmware") changed
      the type usage in struct declarations, but did not touch the definition
      side.  Fix the type mismatch.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      57d1e5fa
  13. 21 Apr, 2018 1 commit
  14. 21 Mar, 2018 1 commit
  15. 02 Mar, 2018 1 commit
  16. 01 Mar, 2018 3 commits
  17. 22 Feb, 2018 1 commit
  18. 25 Jan, 2018 4 commits
  19. 19 Sep, 2017 1 commit
    • Aijun Sun's avatar
      trusty: save/restore FPU registers in world switch · ab609e1a
      Aijun Sun authored
      
      
      Currently, Trusty OS/LK implemented FPU context switch in internal
      thread switch but does not implement the proper mechanism for world
      switch. This commit just simply saves/restores FPU registes in world
      switch to prevent FPU context from being currupted when Trusty OS uses
      VFP in its applications.
      
      It should be noted that the macro *CTX_INCLUDE_FPREGS* must be defined
      in trusty.mk if Trusty OS uses VFP
      Signed-off-by: default avatarAijun Sun <aijun.sun@spreadtrum.com>
      ab609e1a
  20. 12 Jul, 2017 1 commit
    • Isla Mitchell's avatar
      Fix order of #includes · 2a4b4b71
      Isla Mitchell authored
      
      
      This fix modifies the order of system includes to meet the ARM TF coding
      standard. There are some exceptions in order to retain header groupings,
      minimise changes to imported headers, and where there are headers within
      the #if and #ifndef statements.
      
      Change-Id: I65085a142ba6a83792b26efb47df1329153f1624
      Signed-off-by: default avatarIsla Mitchell <isla.mitchell@arm.com>
      2a4b4b71
  21. 04 May, 2017 1 commit
  22. 03 May, 2017 1 commit
  23. 06 Mar, 2017 6 commits
  24. 23 Feb, 2017 1 commit
  25. 30 Nov, 2016 1 commit
  26. 23 Nov, 2016 2 commits
    • Sandrine Bailleux's avatar
      Fix a coding style issue in trusty.c · 48c1c39f
      Sandrine Bailleux authored
      
      
      This patch fixes the following coding style error reported
      by the checkpatch.pl script:
      
        Bad function definition - void el3_exit() should probably
        be void el3_exit(void)
      
      There is another one but it's a false positive so there's no
      point in fixing it:
      
        space prohibited after that '&' (ctx:WxW)
        +#define SMC_NR(entity, fn, fastcall, smc64) ((((fastcall) & 0x1) << 31) | \
                                                                  ^
      Change-Id: I34de0337c7216dabd16395879f13845a60ee6df0
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      48c1c39f
    • Sandrine Bailleux's avatar
      Fix compilation warning in Trusty SPD · 696f41ec
      Sandrine Bailleux authored
      
      
      In release builds, the Trusty SPD fails to build because of an unused
      variable. Note that this warning message doesn't show in debug builds
      because INFO() messages are not compiled out like in release mode.
      
      This patch fixes this issue by removing this variable and using its
      value in place directly in the INFO() macro call.
      
      Change-Id: I1f552421181a09412315eef4eaca586012022018
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      696f41ec
  27. 08 Nov, 2016 1 commit