1. 16 Jan, 2019 4 commits
  2. 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
  3. 18 Dec, 2018 1 commit
  4. 08 Nov, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Standardise header guards across codebase · c3cf06f1
      Antonio Nino Diaz authored
      
      
      All identifiers, regardless of use, that start with two underscores are
      reserved. This means they can't be used in header guards.
      
      The style that this project is now to use the full name of the file in
      capital letters followed by 'H'. For example, for a file called
      "uart_example.h", the header guard is UART_EXAMPLE_H.
      
      The exceptions are files that are imported from other projects:
      
      - CryptoCell driver
      - dt-bindings folders
      - zlib headers
      
      Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c3cf06f1
  5. 28 Sep, 2018 1 commit
  6. 22 Aug, 2018 1 commit
  7. 27 Apr, 2018 1 commit
    • 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
  8. 08 Mar, 2018 1 commit
  9. 17 Feb, 2018 1 commit
    • Andreas Färber's avatar
      tegra: Fix mmap_region_t struct mismatch · 28db3e96
      Andreas Färber authored
      Commit fdb1964c
      
       ("xlat: Introduce
      MAP_REGION2() macro") added a granularity field to mmap_region_t.
      
      Tegra platforms were using the v2 xlat_tables implementation in
      common/tegra_common.mk, but v1 xlat_tables.h headers in soc/*/plat_setup.c
      where arrays are being defined. This caused the next physical address to
      be read as granularity, causing EINVAL error and triggering an assert.
      
      Consistently use xlat_tables_v2.h header to avoid this.
      
      Fixes ARM-software/tf-issues#548.
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      28db3e96
  10. 21 Sep, 2017 1 commit
    • Antonio Nino Diaz's avatar
      Fix type of `unsigned long` constants · e47ac1fd
      Antonio Nino Diaz authored
      
      
      The type `unsigned long` is 32 bit wide in AArch32, but 64 bit wide in
      AArch64. This is inconsistent and that's why we avoid using it as per
      the Coding Guidelines. This patch changes all `UL` occurrences to `U`
      or `ULL` depending on the context so that the size of the constant is
      clear.
      
      This problem affected the macro `BIT(nr)`. As long as this macro is used
      to fill fields of registers, that's not a problem, since all registers
      are 32 bit wide in AArch32 and 64 bit wide in AArch64. However, if the
      macro is used to fill the fields of a 64-bit integer, it won't be able
      to set the upper 32 bits in AArch32.
      
      By changing the type of this macro to `unsigned long long` the behaviour
      is always the same regardless of the architecture, as this type is
      64-bit wide in both cases.
      
      Some Tegra platform files have been modified by this patch.
      
      Change-Id: I918264c03e7d691a931f0d1018df25a2796cc221
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      e47ac1fd
  11. 15 Aug, 2017 1 commit
    • Julius Werner's avatar
      Add new alignment parameter to func assembler macro · 64726e6d
      Julius Werner authored
      
      
      Assembler programmers are used to being able to define functions with a
      specific aligment with a pattern like this:
      
          .align X
        myfunction:
      
      However, this pattern is subtly broken when instead of a direct label
      like 'myfunction:', you use the 'func myfunction' macro that's standard
      in Trusted Firmware. Since the func macro declares a new section for the
      function, the .align directive written above it actually applies to the
      *previous* section in the assembly file, and the function it was
      supposed to apply to is linked with default alignment.
      
      An extreme case can be seen in Rockchip's plat_helpers.S which contains
      this code:
      
        [...]
        endfunc plat_crash_console_putc
      
        .align 16
        func platform_cpu_warmboot
        [...]
      
      This assembles into the following plat_helpers.o:
      
        Sections:
        Idx Name                             Size  [...]  Algn
         9 .text.plat_crash_console_putc 00010000  [...]  2**16
        10 .text.platform_cpu_warmboot   00000080  [...]  2**3
      
      As can be seen, the *previous* function actually got the alignment
      constraint, and it is also 64KB big even though it contains only two
      instructions, because the .align directive at the end of its section
      forces the assembler to insert a giant sled of NOPs. The function we
      actually wanted to align has the default constraint. This code only
      works at all because the linker just happens to put the two functions
      right behind each other when linking the final image, and since the end
      of plat_crash_console_putc is aligned the start of platform_cpu_warmboot
      will also be. But it still wastes almost 64KB of image space
      unnecessarily, and it will break under certain circumstances (e.g. if
      the plat_crash_console_putc function becomes unused and its section gets
      garbage-collected out).
      
      There's no real way to fix this with the existing func macro. Code like
      
       func myfunc
       .align X
      
      happens to do the right thing, but is still not really correct code
      (because the function label is inserted before the .align directive, so
      the assembler is technically allowed to insert padding at the beginning
      of the function which would then get executed as instructions if the
      function was called). Therefore, this patch adds a new parameter with a
      default value to the func macro that allows overriding its alignment.
      
      Also fix up all existing instances of this dangerous antipattern.
      
      Change-Id: I5696a07e2fde896f21e0e83644c95b7b6ac79a10
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      64726e6d
  12. 14 Jul, 2017 1 commit
  13. 15 Jun, 2017 1 commit
    • Anthony Zhou's avatar
      Tegra186: mce: fix MISRA defects · ab712fd8
      Anthony Zhou authored
      
      
      Main fixes:
      
      * 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]
      * Added curly braces ({}) around if/while statements in order to
        make them compound [Rule 15.6]
      * Added parentheses [Rule 12.1]
      * Voided non C-library functions whose return types are not used [Rule 17.7]
      
      Change-Id: I91404edec2e2194b1ce2672d2a3fc6a1f5bf41f1
      Signed-off-by: default avatarAnthony Zhou <anzhou@nvidia.com>
      Signed-off-by: default avatarVarun Wadekar <vwadekar@nvidia.com>
      ab712fd8
  14. 14 Jun, 2017 2 commits
  15. 03 May, 2017 1 commit
  16. 01 May, 2017 4 commits
  17. 26 Apr, 2017 1 commit
  18. 21 Apr, 2017 1 commit
  19. 17 Apr, 2017 1 commit
  20. 13 Apr, 2017 4 commits
  21. 07 Apr, 2017 10 commits