1. 05 Aug, 2019 2 commits
    • Heiko Stuebner's avatar
      rockchip: make uart baudrate configurable · 30970e0f
      Heiko Stuebner authored
      
      
      A previous patch already allowed to configure the uart output from the
      devicetree, but on Rockchip platforms we also have the issue of different
      vendors using different baudrates for their uarts.
      
      For example, rk3399 has a default baudrate of 115200 which is true for
      ChromeOS-devices and boards from Theobroma-Systems, while all the boards
      using the vendor boot chain actually use a baudrate of 1500000.
      
      Similarly the newly added px30 has a default of said 1500000 but some
      boards may want to use the more widely used 115200.
      
      The devicetree stdout-path node already contains the desired baudrate,
      so add simple code to parse it from there and override the default,
      which stays unchanged.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Change-Id: I7412139c3df3073a1996eb508ec08642ec6af90d
      30970e0f
    • Heiko Stuebner's avatar
      rockchip: px30: add uart5 as option for serial output · 5f441a7b
      Heiko Stuebner authored
      
      
      The px30 mini-evb can use either uart2 (muxed with the sd-card pins) or
      uart5 via its pin header for serial output. Uart5 is especially useful
      when needing to boot from the sd-card, where uart2 obviously is not
      useable.
      
      So add the uart5 constants and it as uart option for the serial-param
      handler.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Change-Id: Ib88df7a55d761ee104d312c9953a13de3beba1c4
      5f441a7b
  2. 24 Jul, 2019 3 commits
    • Julius Werner's avatar
      plat/rockchip: Use new bl31_params_parse_helper() · 3e02c743
      Julius Werner authored
      
      
      The Rockchip platform is a prime candidate for switching to the new
      bl31_params_parse_helper(), so switch it over. This will allow BL2
      implementations on this platform to transparently switch over to the
      version 2 parameter structure.
      
      Change-Id: I540741d2425c93f66c8697ce749a351eb2b3a7e8
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      3e02c743
    • Julius Werner's avatar
      Factor out cross-BL API into export headers suitable for 3rd party code · 57bf6057
      Julius Werner authored
      
      
      This patch adds a new include/export/ directory meant for inclusion in
      third-party code. This is useful for cases where third-party code needs
      to interact with TF-A interfaces and data structures (such as a custom
      BL2-implementation like coreboot handing off to BL31). Directly
      including headers from the TF-A repository avoids having to duplicate
      all these definitions (and risk them going stale), but with the current
      header structure this is not possible because handoff API definitions
      are too deeply intertwined with other TF code/headers and chain-include
      other headers that will not be available in the other environment.
      
      The new approach aims to solve this by separating only the parts that
      are really needed into these special headers that are self-contained and
      will not chain-include other (non-export) headers. TF-A code should
      never include them directly but should instead always include the
      respective wrapper header, which will include the required prerequisites
      (like <stdint.h>) before including the export header. Third-party code
      can include the export headers via its own wrappers that make sure the
      necessary definitions are available in whatever way that environment can
      provide them.
      
      Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      57bf6057
    • Julius Werner's avatar
      plat/rockchip: Switch to use new common BL aux parameter library · c1185ffd
      Julius Werner authored
      
      
      This patch changes all Rockchip platforms to use the new common BL aux
      parameter helpers. Since the parameter space is now cleanly split in
      generic and vendor-specific parameters and the COREBOOT_TABLE
      parameter is now generic, the parameter type number for that parameter
      has to change. Since it only affects coreboot which always builds TF as
      a submodule and includes its headers directly to get these constants,
      this should not cause any issues. In general, after this point, we
      should avoid changing already assigned parameter type numbers whenever
      possible.
      
      Change-Id: Ic99ddd1e91ff5e5fe212fa30c793a0b8394c9dad
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      c1185ffd
  3. 09 Jul, 2019 1 commit
    • XiaoDong Huang's avatar
      rockchip: px30: support px30 · 010d6ae3
      XiaoDong Huang authored
      
      
      px30 is a Quad-core soc and Cortex-a53 inside.
      This patch supports the following functions:
      1. basic platform setup
      2. power up/off cpus
      3. suspend/resume cpus
      4. suspend/resume system
      5. reset system
      6. power off system
      
      Change-Id: I73d55aa978096c078242be921abe0ddca9e8f67e
      Signed-off-by: default avatarXiaoDong Huang <derrick.huang@rock-chips.com>
      010d6ae3
  4. 29 May, 2019 1 commit
  5. 01 May, 2019 1 commit
    • Christoph Müllner's avatar
      rockchip: Allow console device to be set by DTB. · 220c33a2
      Christoph Müllner authored
      
      
      Currently the compile-time constant PLAT_RK_UART_BASE defines
      which UART is used as console device. E.g. on RK3399 it is set
      to UART2. That means, that a single bl31 image can not be used
      for two boards, which just differ on the UART console.
      
      This patch addresses this limitation by parsing the "stdout-path"
      property from the "chosen" node in the DTB. The expected property
      string is expected to have the form "serialN:XXX", with
      N being either 0, 1, 2, 3 or 4. When the property is found, it will
      be used to override PLAT_RK_UART_BASE.
      
      Tested on RK3399-Q7, with a stdout-path of "serial0:115200n8".
      Signed-off-by: default avatarChristoph Müllner <christophm30@gmail.com>
      Change-Id: Iafe1320e77ab006c121f8d52745d54cef68a48c7
      220c33a2
  6. 26 Apr, 2019 1 commit
    • Heiko Stuebner's avatar
      rockchip: only include libfdt in non-coreboot cases · 4200e5aa
      Heiko Stuebner authored
      
      
      While mainline u-boot always expects to submit the devicetree
      as platform param, coreboot always uses the existing parameter
      structure. As libfdt is somewhat big, it makes sense to limit
      its inclusion to where necessary and thus only to non-coreboot
      builds.
      
      libfdt itself will get build in all cases, but only the non-
      coreboot build will actually reference and thus include it.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Change-Id: I4c5bc28405a14e6070917e48a526bfe77bab2fb7
      4200e5aa
  7. 25 Apr, 2019 3 commits
    • Heiko Stuebner's avatar
      rockchip: add common aarch32 support · 82e18f89
      Heiko Stuebner authored
      
      
      There are a number or ARMv7 Rockchip SoCs that are very similar in their
      bringup routines to the existing arm64 SoCs, so there is quite a high
      commonality possible here.
      
      Things like virtualization also need psci and hyp-mode and instead of
      trying to cram this into bootloaders like u-boot, barebox or coreboot
      (all used in the field), re-use the existing infrastructure in TF-A
      for this (both Rockchip plat support and armv7 support in general).
      
      So add core support for aarch32 Rockchip SoCs, with actual soc support
      following in a separate patch.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Change-Id: I298453985b5d8434934fc0c742fda719e994ba0b
      82e18f89
    • Heiko Stuebner's avatar
      rockchip: Allow socs with undefined wfe check bits · 3b5b888d
      Heiko Stuebner authored
      
      
      Some older socs like the rk3288 do not have the necessary registers
      to check the wfi/wfe state of the cpu cores. Allow this case an "just"
      do an additional delay similar to how the Linux kernel handles smp
      right now.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Change-Id: I0f67af388b06b8bfb4a9bac411b4900ac266a77a
      3b5b888d
    • Heiko Stuebner's avatar
      rockchip: move pmusram assembler code to a aarch64 subdir · c3aaabaf
      Heiko Stuebner authored
      
      
      The current code doing power-management from sram is highly
      arm64-specific so should live in a corresponding subdirectory
      and not in the common area.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Change-Id: I3b79ac26f70fd189d4d930faa6251439a644c5d9
      c3aaabaf
  8. 14 Mar, 2019 1 commit
    • Heiko Stuebner's avatar
      rockchip: add an fdt parsing stub for platform param · 7029e806
      Heiko Stuebner authored
      
      
      The Rockchip ATF platform can be entered from both Coreboot and U-Boot.
      While Coreboot does submit the list of linked parameter structs as
      platform param, upstream u-boot actually always provides a pointer
      to a devicetree as parameter.
      This results in current ATF not running at all when started from U-Boot.
      
      To fix this, add a stub that checks if the parameter is a fdt so we
      can at least boot and not get stuck. Later on we can extend this with
      actual parsing of information from the devicetree.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
      7029e806
  9. 28 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      rockchip: Fix GICv2 interrupts · d31dcdc5
      Antonio Nino Diaz authored
      After the removal of deprecated interfaces in TF 2.0 the migration to
      the new GIC driver interfaces was done incorrectly in rk3328 and rk3368:
      2d6f1f01
      
       ("rockchip: Migrate to new interfaces").
      
      In the GICv2 driver it is mandated that all interrupts are Group 0
      interrupts. This patch simply moves all Group 1 interrupts to Group 0.
      
      Change-Id: I224c0135603eb5b81bd512976361500c0d129a91
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      d31dcdc5
  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. 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
  12. 10 Oct, 2018 1 commit
  13. 28 Sep, 2018 1 commit
    • Antonio Nino Diaz's avatar
      rockchip: Migrate to new interfaces · 2d6f1f01
      Antonio Nino Diaz authored
      
      
      - Migrate to new GIC interfaces.
      - Migrate to bl31_early_platform_setup2().
      - Use bl31_warm_entrypoint() instead of psci_entrypoint().
      - Use PLAT_VIRT_ADDR_SPACE_SIZE and PLAT_PHY_ADDR_SPACE_SIZE.
      - Update Makefile paths.
      - Remove references to removed build options.
      - Use private definition of bl31_params_t.
      
      Change-Id: I860341594b5c868b2fcaa59d23957ee718472ef1
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2d6f1f01
  14. 15 Aug, 2018 1 commit
  15. 11 Jul, 2018 1 commit
  16. 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
  17. 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
  18. 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
  19. 26 Mar, 2018 1 commit
  20. 26 Jan, 2018 1 commit
  21. 19 Jan, 2018 2 commits
    • Julius Werner's avatar
      rockchip: Move to MULTI_CONSOLE_API · 890abc33
      Julius Werner authored
      
      
      This patch changes all Rockchip platforms to use the new
      MULTI_CONSOLE_API. The platform-specific plat_crash_console
      implementations are removed so that the platform can use the ones from
      the common platform code instead.
      
      Also change the registers used in plat_crash_print_regs. The existing
      use of x16 and x17 has always been illegal, since those registers are
      reserved for use by the linker as a temporary scratch registers in
      intra-procedure-call veneers and can never be expected to maintain their
      values across a function call.
      
      Change-Id: I8249424150be8d5543ed4af93b56756795a5288f
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      890abc33
    • Julius Werner's avatar
      rockchip: Use coreboot-supplied serial console on coreboot systems · 3c250b9a
      Julius Werner authored
      
      
      This patch changes all Rockchip platforms to initialize the serial
      console with information supplied by coreboot rather than hardcoded
      base address and divisor values if BL31 is run on top of coreboot.
      Moving the BL2-to-BL31 parameter parsing as early as possible to ensure
      that the console is available for all following code.
      
      Also update the Rockchip platform to use MULTI_CONSOLE_API.
      
      Change-Id: I670d350fa2f8b8133539f91ac14977ab47db60d9
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      3c250b9a
  22. 12 Dec, 2017 1 commit
    • Julius Werner's avatar
      rockchip: Implement a panic handler that will reboot the system · a33e763c
      Julius Werner authored
      
      
      The current Rockchip platform code retains the "common" default panic
      handler which simply hangs the system (until the watchdog kicks in, if
      enabled). This is usually not a great user experience.
      
      This patch implements a Rockchip-specific panic handler that calls the
      platform's reboot implementation to reset the system.
      
      Change-Id: I4cbe09c48f1b3f86ebdfc0108c186565f9ffc119
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      a33e763c
  23. 29 Aug, 2017 2 commits
  24. 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
  25. 14 Jul, 2017 1 commit
  26. 14 Jun, 2017 1 commit
  27. 08 Jun, 2017 3 commits
  28. 10 May, 2017 2 commits
  29. 03 May, 2017 1 commit