Skip to content

GitLab

Switch branch/tag
  1. 17 May, 2018 6 commits
  3. 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
  5. 26 Mar, 2018 1 commit
  7. 15 Mar, 2018 15 commits
  9. 27 Feb, 2018 1 commit
  11. 29 Jan, 2018 1 commit
  13. 09 Jan, 2018 3 commits
  15. 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
  17. 17 Oct, 2017 1 commit
  19. 18 Sep, 2017 1 commit
  21. 14 Jul, 2017 1 commit
  23. 02 Jul, 2017 1 commit
  25. 03 May, 2017 1 commit
  27. 06 Apr, 2017 1 commit
  29. 20 Mar, 2017 1 commit
  31. 06 Feb, 2017 1 commit
    • Douglas Raillard's avatar
      Replace some memset call by zeromem · 32f0d3c6
      Douglas Raillard authored 
      

Replace all use of memset by zeromem when zeroing moderately-sized
structure by applying the following transformation:
memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x))

As the Trusted Firmware is compiled with -ffreestanding, it forbids the
compiler from using __builtin_memset and forces it to generate calls to
the slow memset implementation. Zeromem is a near drop in replacement
for this use case, with a more efficient implementation on both AArch32
and AArch64.

Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e
Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      32f0d3c6
  33. 18 Jan, 2017 2 commits
    • Masahiro Yamada's avatar
      Move BL_COHERENT_RAM_BASE/END defines to common_def.h · 47497053
      Masahiro Yamada authored 
      

We have lots of duplicated defines (and comment blocks too).
Move them to include/plat/common/common_def.h.

While we are here, suffix the end address with _END instead of
_LIMIT.  The _END is a better fit to indicate the linker-derived
real end address.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      47497053
    • Masahiro Yamada's avatar
      Use *_END instead of *_LIMIT for linker derived end addresses · ecdc898d
      Masahiro Yamada authored 
      

The usage of _LIMIT seems odd here, so rename as follows:
  BL_CODE_LIMIT     --> BL_CODE_END
  BL_RO_DATA_LIMIT  --> BL_RO_DATA_END
  BL1_CODE_LIMIT    --> BL1_CODE_END
  BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END

Basically, we want to use _LIMIT and _END properly as follows:
  *_SIZE + *_MAX_SIZE = *_LIMIT
  *_SIZE + *_SIZE     = *_END

The _LIMIT is generally defined by platform_def.h to indicate the
platform-dependent memory constraint.  So, its typical usage is
  ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
in a linker script.

On the other hand, _END is used to indicate the end address of the
compiled image, i.e. we do not know it until the image is linked.

Here, all of these macros belong to the latter, so should be
suffixed with _END.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ecdc898d