1. 08 Nov, 2018 1 commit
  2. 01 Nov, 2018 1 commit
  3. 31 Oct, 2018 1 commit
  4. 25 Oct, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Add plat_crash_console_flush to platforms without it · 9c675b37
      Antonio Nino Diaz authored
      
      
      Even though at this point plat_crash_console_flush is optional, it will
      stop being optional in a following patch.
      
      The console driver of warp7 doesn't support flush, so the implementation
      is a placeholder.
      
      TI had ``plat_crash_console_init`` and ``plat_crash_console_putc``, but
      they weren't global so they weren't actually used. Also, they were
      calling the wrong functions.
      
      imx8_helpers.S only has placeholders for all of the functions.
      
      Change-Id: I8d17bbf37c7dad74e134c61ceb92acb9af497718
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      9c675b37
  5. 28 Sep, 2018 1 commit
  6. 26 Sep, 2018 1 commit
    • Haojian Zhuang's avatar
      hikey: fix build issue for clang · 00a64624
      Haojian Zhuang authored
      
      
      plat/hisilicon/hikey/include/plat_macros.S:19:55: error: unexpected token in '.asciz' directive
       .asciz "gicd_ispendr regs (Offsets 0x200 - 0x278)\n" " Offset:\t\t\tvalue\n"
                                                            ^
      Makefile:720: recipe for target 'build/hikey/debug/bl1/cortex_a53.o' failed
      make: *** [build/hikey/debug/bl1/cortex_a53.o] Error 1
      
      Merge two lines into one line.
      Signed-off-by: default avatarHaojian Zhuang <haojian.zhuang@linaro.org>
      00a64624
  7. 22 Aug, 2018 2 commits
  8. 10 Aug, 2018 2 commits
  9. 22 Jul, 2018 1 commit
  10. 20 Jul, 2018 1 commit
  11. 06 Jul, 2018 1 commit
    • Teddy Reed's avatar
      hikey: Add development TBB support · e59a3bff
      Teddy Reed authored
      
      
      This patch adds experimental support for TRUSTED_BOARD_BOOT to the
      Hikey. This is adapted from the RPi3 and QEMU implementations.
      
      Since the Hikey starts from BL2 the TRUSTED_BOARD_BOOT ROT begins there
      too. When TRUSTED_BOARD_BOOT is defined, the BL1 build is skipped.
      
      See the following example:
      
      make \
       PLAT=hikey \
       BL33=u-boot.bin \
       SCP_BL2=mcuimage.bin \
       TRUSTED_BOARD_BOOT=1 \
       MBEDTLS_DIR=../../mbedtls \
       GENERATE_COT=1 \
       all fip
      Signed-off-by: default avatarTeddy Reed <teddy.reed@gmail.com>
      e59a3bff
  12. 14 Jun, 2018 1 commit
    • Roberto Vargas's avatar
      Make TF UUID RFC 4122 compliant · 03364865
      Roberto Vargas authored
      
      
      RFC4122 defines that fields are stored in network order (big endian),
      but TF-A stores them in machine order (little endian by default in TF-A).
      We cannot change the future UUIDs that are already generated, but we can store
      all the bytes using arrays and modify fiptool to generate the UUIDs with
      the correct byte order.
      
      Change-Id: I97be2d3168d91f4dee7ccfafc533ea55ff33e46f
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      03364865
  13. 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
  14. 11 Apr, 2018 3 commits
  15. 27 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Clean usage of void pointers to access symbols · 9f85f9e3
      Joel Hutton authored
      
      
      Void pointers have been used to access linker symbols, by declaring an
      extern pointer, then taking the address of it. This limits symbols
      values to aligned pointer values. To remove this restriction an
      IMPORT_SYM macro has been introduced, which declares it as a char
      pointer and casts it to the required type.
      
      Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
      Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9f85f9e3
  16. 26 Mar, 2018 1 commit
  17. 12 Mar, 2018 1 commit
    • Michael Brandl's avatar
      plat/hikey: boot memory layout to dedicated file · 4368ae07
      Michael Brandl authored
      
      
      Boot memory layout is specific for a platform, but should not be
      mixed up with other platform specific attributes. A separate file is
      much cleaner and better to compare with other platforms. Take a look
      at plat/poplar where it is done the same way.
      
      Moved hikey_def.h to system include folder and moved includes from
      hikey_def.h to more general platform_def.h.
      Signed-off-by: default avatarMichael Brandl <git@fineon.pw>
      4368ae07
  18. 06 Mar, 2018 1 commit
  19. 05 Mar, 2018 4 commits
  20. 27 Feb, 2018 1 commit
  21. 07 Feb, 2018 1 commit
  22. 01 Feb, 2018 2 commits
  23. 30 Jan, 2018 1 commit
  24. 29 Jan, 2018 1 commit
  25. 27 Jan, 2018 1 commit
  26. 24 Jan, 2018 2 commits
  27. 30 Nov, 2017 1 commit
    • David Cunado's avatar
      Do not enable SVE on pre-v8.2 platforms · 3872fc2d
      David Cunado authored
      
      
      Pre-v8.2 platforms such as the Juno platform does not have
      the Scalable Vector Extensions implemented and so the build
      option ENABLE_SVE is set to zero.
      
      This has a minor performance improvement with no functional
      impact.
      
      Change-Id: Ib072735db7a0247406f8b60e325b7e28b1e04ad1
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      3872fc2d
  28. 22 Nov, 2017 1 commit
  29. 01 Nov, 2017 1 commit
  30. 18 Oct, 2017 2 commits