1. 15 May, 2018 1 commit
    • Lin Huang's avatar
      rockchip/rk3399: improve pmu powermode configure when suspend · 133598cb
      Lin Huang authored
      
      
      we need to enable PMU_WKUP_RST_EN for pmu powermode configure, since
      enable wakeup reset will hold the soc status, so the SOC will not affect
      by some power or other single glitch when resume, and keep the soc in the
      right status. And it not need to enable DDRIO_RET_HW_DE_REQ, the ddr resume
      will do it manual.
      
      Change-Id: Ib4af897ffb3cb63dc2aa9a6002e5d9ef86ee4a49
      Signed-off-by: default avatarLin Huang <hl@rock-chips.com>
      133598cb
  2. 11 May, 2018 3 commits
    • Dimitris Papastamos's avatar
      Merge pull request #1372 from antonio-nino-diaz-arm/an/arm-multi-console · da9d1d59
      Dimitris Papastamos authored
      Arm platforms: Migrate to multi console driver
      da9d1d59
    • Antonio Nino Diaz's avatar
      plat/arm: Migrate AArch64 port to the multi console driver · 2f18aa1f
      Antonio Nino Diaz authored
      
      
      The old API is deprecated and will eventually be removed.
      
      Arm platforms now use the multi console driver for boot and runtime
      consoles. However, the crash console uses the direct console API because
      it doesn't need any memory access to work. This makes it more robust
      during crashes.
      
      The AArch32 port of the Trusted Firmware doesn't support this new API
      yet, so it is only enabled in AArch64 builds. Because of this, the
      common code must maintain compatibility with both systems. SP_MIN
      doesn't have to be updated because it's only used in AArch32 builds.
      The TSP is only used in AArch64, so it only needs to support the new
      API without keeping support for the old one.
      
      Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this
      causes the UARTs to reset (except for the one used by the TSP). This
      means that they must be unregistered when suspending and re-registered
      when resuming. This wasn't a problem with the old driver because it just
      restarted the UART, and there were no problems associated with
      registering and unregistering consoles.
      
      The size of BL31 has been increased in builds with SPM.
      
      Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2f18aa1f
    • Antonio Nino Diaz's avatar
      multi console: Assert that consoles aren't registered twice · c2e05bb7
      Antonio Nino Diaz authored
      
      
      In the multi console driver, allowing to register the same console more
      than once may result in an infinte loop when putc is called.
      
      If, for example, a boot message is trying to be printed, but the
      consoles in the loop in the linked list are runtime consoles, putc will
      iterate forever looking for a console that can print boot messages (or
      a NULL pointer that will never come).
      
      This loop in the linked list can occur after restoring the system from a
      system suspend. The boot console is registered during the cold boot in
      BL31, but the runtime console is registered even in the warm boot path.
      Consoles are always added to the start of the linked list when they are
      registered, so this it what should happen if they were actually
      different structures:
      
         console_list -> NULL
         console_list -> BOOT -> NULL
         console_list -> RUNTIME -> BOOT -> NULL
         console_list -> RUNTIME -> RUNTIME -> BOOT -> NULL
      
      In practice, the two runtime consoles are the same one, so they create
      this loop:
      
         console_list -> RUNTIME -.    X -> BOOT -> NULL
                             ^    |
                             `----'
      
      This patch adds an assertion to detect this problem. The assertion will
      fail whenever the same structure tries to be registered while being on
      the list.
      
      In order to assert this, console_is_registered() has been implemented.
      It returns 1 if the specified console is registered, 0 if not.
      
      Change-Id: I922485e743775ca9bd1af9cbd491ddd360526a6d
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c2e05bb7
  3. 09 May, 2018 3 commits
  4. 08 May, 2018 2 commits
  5. 03 May, 2018 8 commits
  6. 02 May, 2018 2 commits
  7. 01 May, 2018 8 commits
  8. 30 Apr, 2018 1 commit
  9. 27 Apr, 2018 4 commits
    • Antonio Nino Diaz's avatar
      checkpatch: Ignore SPDX_LICENSE_TAG · 90582e4d
      Antonio Nino Diaz authored
      
      
      The Linux kernel expects the SPDX license tag in the first line of each
      source code file in a comment.
      
      In the context of the Linux kernel repository this makes sense because
      they have many different license headers across their codebase. Moving
      the tag to the first line of the source code files makes it easier for
      analyzers to see the license of each file.
      
      In the Trusted Firmware, we control all headers and make sure that they
      follow the same pattern, so this is not needed.
      
      Change-Id: Ie19802c7b65b1bdd63da9ece64311aec1f8ad7fe
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      90582e4d
    • 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
      arch_helpers: use u_register_t for register read/write · 8f4dbaab
      Masahiro Yamada authored
      
      
      u_register_t is preferred rather than uint64_t.  This is more
      consistent with the aarch32 implementation.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      8f4dbaab
    • 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
  10. 26 Apr, 2018 3 commits
    • Yann Gautier's avatar
      BL2_AT_EL3: do not try to disable MMU twice on AARCH32 · 01a1f7c2
      Yann Gautier authored
      
      
      If BL2_AT_EL3 is enabled, bl2_run_next_image is called at the end of BL2.
      This function calls disable_mmu_icache_secure.
      It is then useless to call it in bl2_main in that case.
      
      fixes arm-software/tf-issues#582
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      01a1f7c2
    • Dimitris Papastamos's avatar
      Merge pull request #1345 from dbasehore/udelay · a8d9550b
      Dimitris Papastamos authored
      rockchip/rk3399: Fix sram_udelay
      a8d9550b
    • Antonio Nino Diaz's avatar
      xlat: Set AP[1] to 1 when it is RES1 · 01c0a38e
      Antonio Nino Diaz authored
      
      
      According to the ARMv8 ARM issue C.a:
      
          AP[1] is valid only for stage 1 of a translation regime that can
          support two VA ranges. It is RES 1 when stage 1 translations can
          support only one VA range.
      
      This means that, even though this bit is ignored, it should be set to 1
      in the EL3 and EL2 translation regimes.
      
      For translation regimes consisting on EL0 and a higher regime this bit
      selects between control at EL0 or at the higher Exception level. The
      regimes that support two VA ranges are EL1&0 and EL2&0 (the later one
      is only available since ARMv8.1).
      
      This fix has to be applied to both versions of the translation tables
      library.
      
      Change-Id: If19aaf588551bac7aeb6e9a686cf0c2068e7c181
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      01c0a38e
  11. 24 Apr, 2018 2 commits
  12. 23 Apr, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Add support for the SMC Calling Convention 2.0 · 2f370465
      Antonio Nino Diaz authored
      
      
      Due to differences in the bitfields of the SMC IDs, it is not possible
      to support SMCCC 1.X and 2.0 at the same time.
      
      The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build
      option that specifies the major version of the SMCCC that the Trusted
      Firmware supports. The only two allowed values are 1 and 2, and it
      defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it.
      
      Note: Support for SMCCC v2.0 is an experimental feature to enable
      prototyping of secure partition specifications. Support for this
      convention is disabled by default and could be removed without notice.
      
      Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2f370465
  13. 21 Apr, 2018 1 commit
  14. 18 Apr, 2018 1 commit