1. 07 Dec, 2018 3 commits
    • Julius Werner's avatar
      drivers/console: Link console framework code by default · 985ee0b7
      Julius Werner authored
      
      
      This patch makes the build system link the console framework code by
      default, like it already does with other common libraries (e.g. cache
      helpers). This should not make a difference in practice since TF is
      linked with --gc-sections, so the linker will garbage collect all
      functions and data that are not referenced by any other code. Thus, if a
      platform doesn't want to include console code for size reasons and
      doesn't make any references to console functions, the code will not be
      included in the final binary.
      
      To avoid compatibility issues with older platform ports, only make this
      change for the MULTI_CONSOLE_API.
      
      Change-Id: I153a9dbe680d57aadb860d1c829759ba701130d3
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      985ee0b7
    • Julius Werner's avatar
      plat/common/crash_console_helpers.S: Fix MULTI_CONSOLE_API support · 63c52d00
      Julius Werner authored
      Crash reporting via the default consoles registered by MULTI_CONSOLE_API
      has been broken since commit d35cc347
      
       (Console: Use callee-saved
      registers), which was introduced to allow console drivers written in C.
      It's not really possible with the current crash reporting framework to
      support console drivers in C, however we should make sure that the
      existing assembly drivers that do support crash reporting continue to
      work through the MULTI_CONSOLE_API.
      
      This patch fixes the problem by creating custom console_putc() and
      console_flush() implementations for the crash reporting case that do not
      use the stack. Platforms that want to use this feature will have to link
      plat/common/aarch64/crash_console_helpers.S explicitly.
      
      Also update the documentation to better reflect the new reality (of this
      being an option rather than the expected default for most platforms).
      
      Change-Id: Id0c761e5e2fddaf25c277bc7b8ab603946ca73cb
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      63c52d00
    • Julius Werner's avatar
      plat/common: Remove duplication of plat_crash_console functions/stubs · b2f7c9dd
      Julius Werner authored
      Commit e74afb65 (Deprecate weak crash console functions) deprecated the
      default inclusion of weak definitions for plat_crash_console functions
      in plat/common/aarch64/platform_helpers.S. The code was later copied out
      to plat/common/aarch64/crash_console_helpers.S so platforms can link it
      explicitly if they want to. However, since deprecation does not mean
      removal, the same code is also still duplicated in platform_helpers.S.
      
      The duplicated code contains both empty stubs for the !MULTI_CONSOLE_API
      case, and a real implementation that used to work but was broken by
      commit d35cc347
      
       (Console: Use callee-saved registers) for
      MULTI_CONSOLE_API. It's not great to have both of these duplicated in
      two files, so this patch splits them up: in platform_helpers.S we'll
      only keep the empty stubs (guarded by !ERROR_DEPRECATED), which should
      not regress functionality since the MULTI_CONSOLE_API implementation was
      already broken anyway. In crash_console_helpers.S, we'll only keep the
      MULTI_CONSOLE_API version, which is enough both as an implementation in
      itself and as a sample for how to reimplement these functions in a
      platform-specific file.
      
      Change-Id: I83d95a90ab6aac597dc2ea2f2797ac2c8ed075d4
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      b2f7c9dd
  2. 26 Nov, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Synchronise arch.h and arch_helpers.h with TF-A-Tests · 932b3ae2
      Antonio Nino Diaz authored
      
      
      The headers forked at some point in the past and have diverged a lot. In
      order to make it easier to share code between TF-A-Tests and TF-A, this
      patch synchronises most of the definitions in the mentioned headers.
      
      This is not a complete sync, it has to be followed by more cleanup.
      
      This patch also removes the read helpers for the AArch32 instructions
      ats1cpr and ats1hr (they are write-only).
      
      Change-Id: Id13ecd7aeb83bd2318cd47156d71a42f1c9f6ba2
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      932b3ae2
  3. 23 Nov, 2018 1 commit
    • Sathees Balya's avatar
      juno: Add romlib support · afa5cfea
      Sathees Balya authored
      
      
      This patch adds support to build a combined BL1
      and ROMLIB binary file with the right page
      alignment in Juno. When USE_ROMLIB=1 is set for
      Juno, it generates the combined file
      bl1_romlib.bin which needs to be used instead of
      bl1.bin
      
      Change-Id: I407efbe48d3e522fa6ef855538a9587193cb1919
      Signed-off-by: default avatarSathees Balya <sathees.balya@arm.com>
      afa5cfea
  4. 21 Nov, 2018 1 commit
  5. 20 Nov, 2018 1 commit
  6. 19 Nov, 2018 1 commit
    • Pete Batard's avatar
      rpi3: add RPI3_USE_UEFI_MAP build option · 4dcf1fad
      Pete Batard authored
      
      
      The default Raspberry Pi 3 memory mapping for ATF is geared towards
      the use of uboot + Linux. This creates issues when trying to use
      ATF with an UEFI payload and Windows on ARM64.
      
      We therefore introduce new build option RPI3_USE_UEFI_MAP, that
      enables the build process to use an alternate memory mapping that
      is compatible with UEFI + Windows (as well as UEFI + Linux).
      
      Fixes ARM-software/tf-issues#649
      Signed-off-by: default avatarPete Batard <pete@akeo.ie>
      4dcf1fad
  7. 15 Nov, 2018 4 commits
  8. 14 Nov, 2018 5 commits
    • Andre Przywara's avatar
      allwinner: power: Add DCDC6 power rail · 793c38f0
      Andre Przywara authored
      
      
      The DCDC6 power rail is typically driving VDD_SYS in the SoC, so it is
      on by default and uses the default voltage.
      
      As there seems to be at least on board using a different voltage, add
      the rail to the list of known voltage lines, so we can setup the right
      voltage as early as possible.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      793c38f0
    • Andre Przywara's avatar
      allwinner: power: add enable switches for DCDC1/5 · a561e41b
      Andre Przywara authored
      
      
      The DCDC1 and DCDC5 power rails didn't specify the enable bits. This
      isn't critical, since those rails are on by default (and are needed for
      every board), but it is inconsistent.
      
      Add the respective enable bits for those two rails.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      a561e41b
    • Andre Przywara's avatar
      allwinner: power: fix DRIVEVBUS pin setup · d93eb446
      Andre Przywara authored
      
      
      The DRIVEVBUS pin setup was broken in two ways:
      - To configure this pin as an output pin, one has to *clear* the bit in
        register 0x8f. It is 0 by default, but rebooting from Linux might have
        left this bit set.
      - Doing this just configures the pin as an output pin, but doesn't
        actually drive power to it. This is done via bit 2 in register 0x30.
      
      Fix the routine to both properly configure the pin and drive power to
      it. Add an axp_clrsetbits() helper on the way.
      
      Now this isn't really perfect, still:
      We only need to setup the PMIC power rails that are needed for U-Boot.
      DRIVEVBUS typically controls the VBUS voltage for the host function of
      an USB-OTG port, something we typically don't want in U-Boot (fastboot,
      using the USB *device* functionality, is much more common). The
      BananaPi-M64 uses the regulator in this way, but the Remix Mini PC
      actually controls the power of both its USB ports via this line.
      
      Technically we should differentiate here: if DRIVEVBUS controls a
      microUSB-B socket, the power should stay off, any host-type A sockets
      should be supplied, though.
      For now just always enable the power, that shouldn't really hurt the
      USB-OTG functionality anyway.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      d93eb446
    • Andre Przywara's avatar
      allwinner: A64/H5: setup missing bus clocks · 19a7507a
      Andre Przywara authored
      
      
      The legacy Allwinner ATF port used to setup some clocks, and U-Boot is
      still relying on this. We don't need to setup the full set, as the SPL
      is doing most of it, but it misses one clock (AHB2) and programs another
      (AHB1) to quite conservative values.
      
      Fix this up during the platform setup to improve USB and Ethernet
      performance, iperf values go up by 31% in my setup with that patch.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      19a7507a
    • Sughosh Ganu's avatar
      SPM: Register Secure Partition priority level with ehf module · 5681b292
      Sughosh Ganu authored
      
      
      Register a priority level, PLAT_SP_PRI, for secure partition with EL3
      exception handling framework(ehf) module.
      
      The secure partition manager(SPM) would raise the core's priority to
      PLAT_SP_PRI before entering the secure partition, to protect the core
      from getting interrupted while in secure partition.
      
      Change-Id: I686897f052a4371e0efa9b929c07d3ad77249e95
      Signed-off-by: default avatarSughosh Ganu <sughosh.ganu@arm.com>
      5681b292
  9. 13 Nov, 2018 1 commit
    • Pete Batard's avatar
      rpi3: add RPI3_RUNTIME_UART build option · 6d5c61de
      Pete Batard authored
      
      
      Some OSes (e.g. Ubuntu 18.04 LTS on Raspberry Pi 3) may disable the
      runtime UART in a manner that prevents the system from rebooting if
      ATF tries to send runtime messages there.
      
      Also, we don't want the firmware to share the UART with normal
      world, as this can be a DoS attack vector into the secure world.
      
      This patch fixes these 2 issues by introducing new build option
      RPI3_RUNTIME_UART, that disables the runtime UART by default.
      
      Fixes ARM-software/tf-issues#647
      Signed-off-by: default avatarPete Batard <pete@akeo.ie>
      6d5c61de
  10. 09 Nov, 2018 2 commits
    • Yann Gautier's avatar
      stm32mp1: correct some static analysis tools issues · 3e6fab43
      Yann Gautier authored
      
      
      These issues wer found by sparse:
      
      drivers/st/clk/stm32mp1_clk.c:1524:19:
       warning: incorrect type in assignment (different base types)
          expected restricted fdt32_t const [usertype] *pkcs_cell
          got unsigned int const [usertype] *
      
      plat/st/stm32mp1/plat_image_load.c:13:6:
       warning: symbol 'plat_flush_next_bl_params' was not declared.
       Should it be static?
      plat/st/stm32mp1/plat_image_load.c:21:16:
       warning: symbol 'plat_get_bl_image_load_info' was not declared.
       Should it be static?
      plat/st/stm32mp1/plat_image_load.c:29:13:
       warning: symbol 'plat_get_next_bl_params' was not declared.
       Should it be static?
      
      plat/st/stm32mp1/bl2_io_storage.c:40:10:
       warning: symbol 'block_buffer' was not declared. Should it be static?
      Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      3e6fab43
    • Siva Durga Prasad Paladugu's avatar
      arm64: versal: Add support for new Xilinx Versal ACAPs · f91c3cb1
      Siva Durga Prasad Paladugu authored
      
      
      Xilinx is introducing Versal, an adaptive compute acceleration platform
      (ACAP), built on 7nm FinFET process technology. Versal ACAPs combine Scalar
      Processing Engines, Adaptable Hardware Engines, and Intelligent Engines with
      leading-edge memory and interfacing technologies to deliver powerful
      heterogeneous acceleration for any application. The Versal AI Core series has
      five devices, offering 128 to 400 AI Engines. The series includes dual-core Arm
      Cortex-A72 application processors, dual-core Arm Cortex-R5 real-time
      processors, 256KB of on-chip memory with ECC, more than 1,900 DSP engines
      optimized for high-precision floating point with low latency.
      
      This patch adds Virtual QEMU platform support for
      this SoC "versal_virt".
      Signed-off-by: default avatarSiva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
      Signed-off-by: default avatarMichal Simek <michal.simek@xilinx.com>
      f91c3cb1
  11. 08 Nov, 2018 4 commits
  12. 06 Nov, 2018 3 commits
  13. 05 Nov, 2018 1 commit
  14. 01 Nov, 2018 4 commits
  15. 31 Oct, 2018 2 commits
  16. 30 Oct, 2018 5 commits
  17. 29 Oct, 2018 1 commit