1. 19 Jan, 2018 2 commits
    • Julius Werner's avatar
      drivers: ti: uart: Update 16550 UART driver to support MULTI_CONSOLE_API · 36c42ca1
      Julius Werner authored
      
      
      This patch updates the TI 16550 console driver to support the new
      console API. The driver will continue to support the old API as well by
      checking the MULTI_CONSOLE_API compile-time flag.
      
      Change-Id: I60a44b7ba3c35c74561824c04b8dbe3e3039324c
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      36c42ca1
    • Julius Werner's avatar
      Add default crash console code to hook up to new console API · 17cd67d2
      Julius Werner authored
      
      
      This patch expands the weak stubs for the plat_crash_console_xxx
      functions in common platform code to use the new console API for crash
      output. This should make crash console output "just work" for most cases
      without the need for the platform to explicitly set up a crash console.
      For cases where the normal console framework doesn't work (e.g. very
      early crashes, before the platform can register any consoles), platforms
      are still able to override the functions just like before.
      
      This feature requires the MULTI_CONSOLE_API compile-time flag to work.
      For builds which don't have it set, this patch has no practical effect.
      
      Change-Id: I80dd161cb43f9db59a0bad2dae33c6560cfac584
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      17cd67d2
  2. 12 Dec, 2017 3 commits
    • Julius Werner's avatar
      Add new function-pointer-based console API · 9536bae6
      Julius Werner authored
      
      
      This patch overhauls the console API to allow for multiple console
      instances of different drivers that are active at the same time. Instead
      of binding to well-known function names (like console_core_init),
      consoles now provide a register function (e.g. console_16550_register())
      that will hook them into the list of active consoles. All console
      operations will be dispatched to all consoles currently in the list.
      
      The new API will be selected by the build-time option MULTI_CONSOLE_API,
      which defaults to ${ERROR_DEPRECATED} for now. The old console API code
      will be retained to stay backwards-compatible to older platforms, but
      should no longer be used for any newly added platforms and can hopefully
      be removed at some point in the future.
      
      The new console API is intended to be used for both normal (bootup) and
      crash use cases, freeing platforms of the need to set up the crash
      console separately. Consoles can be individually configured to be active
      active at boot (until first handoff to EL2), at runtime (after first
      handoff to EL2), and/or after a crash. Console drivers should set a sane
      default upon registration that can be overridden with the
      console_set_scope() call. Code to hook up the crash reporting mechanism
      to this framework will be added with a later patch.
      
      This patch only affects AArch64, but the new API could easily be ported
      to AArch32 as well if desired.
      
      Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9536bae6
    • 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
    • Julius Werner's avatar
      utils_def: Add REGSZ and make BIT() assembly-compatible · 155a1006
      Julius Werner authored
      
      
      In assembly code it can be useful to have a constant for the width of a
      register in the current architecture, so this patch adds one to
      <utils_def.h> and replaces the existing custom one in crash_reporting.S
      with that. It also fixes up the BIT() macro in the same file so that it
      can be safely used in assembly code.
      
      Change-Id: I10513a311f3379e767396e6ddfbae8d2d8201464
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      155a1006
  3. 11 Dec, 2017 1 commit
  4. 10 Dec, 2017 1 commit
  5. 09 Dec, 2017 7 commits
  6. 08 Dec, 2017 1 commit
  7. 06 Dec, 2017 10 commits
  8. 05 Dec, 2017 5 commits
  9. 04 Dec, 2017 1 commit
  10. 02 Dec, 2017 1 commit
  11. 01 Dec, 2017 3 commits
  12. 30 Nov, 2017 3 commits
    • 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
    • David Cunado's avatar
      Enable SVE for Non-secure world · 1a853370
      David Cunado authored
      
      
      This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set
      to one EL3 will check to see if the Scalable Vector Extension (SVE) is
      implemented when entering and exiting the Non-secure world.
      
      If SVE is implemented, EL3 will do the following:
      
      - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled.
      
      - Exit from Non-secure world: SIMD, FP and SVE functionality is
        disabled. As SIMD and FP registers are part of the SVE Z-registers
        then any use of SIMD / FP functionality would corrupt the SVE
        registers.
      
      The build option default is 1. The SVE functionality is only supported
      on AArch64 and so the build option is set to zero when the target
      archiecture is AArch32.
      
      This build option is not compatible with the CTX_INCLUDE_FPREGS - an
      assert will be raised on platforms where SVE is implemented and both
      ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1.
      
      Also note this change prevents secure world use of FP&SIMD registers on
      SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on
      such platforms unless ENABLE_SVE_FOR_NS is set to 0.
      
      Additionally, on the first entry into the Non-secure world the SVE
      functionality is enabled and the SVE Z-register length is set to the
      maximum size allowed by the architecture. This includes the use case
      where EL2 is implemented but not used.
      
      Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      1a853370
    • Siva Durga Prasad Paladugu's avatar
      Update Xilinx maintainer details · c503be26
      Siva Durga Prasad Paladugu authored
      
      
      This patch updates Xilinx maintainers details
      as sorenb is no more the maintainer for xilinx
      and the email id is invalid now.
      Signed-off-by: default avatarSiva Durga Prasad Paladugu <sivadur@xilinx.com>
      c503be26
  13. 29 Nov, 2017 2 commits
    • Soby Mathew's avatar
      Juno AArch32: Remove duplicate definition of bl2 platform API · a9f9b608
      Soby Mathew authored
      
      
      The bl2_early_platform_setup() and bl2_platform_setup() were
      redefined for Juno AArch32 eventhough CSS platform layer had
      same definition for them. The CSS definitions definitions were
      previously restricted to EL3_PAYLOAD_BASE builds and this is now
      modified to include the Juno AArch32 builds as well thus
      allowing us to remove the duplicate definitions in Juno platform
      layer.
      
      Change-Id: Ibd1d8c1428cc1d51ac0ba90f19f5208ff3278ab5
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      a9f9b608
    • Soby Mathew's avatar
      ARM platforms: Fixup AArch32 builds · 5744e874
      Soby Mathew authored
      
      
      This patch fixes a couple of issues for AArch32 builds on ARM reference
      platforms :
      
      1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and
         AArch32 build. Since BL31 is not present in AArch32 mode, this meant that
         the BL31 memory is empty when built for AArch32. Hence this patch allocates
         BL32 to the memory region occupied by BL31 for AArch32 builds.
      
         As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot
         be used to control the load address of BL32 in AArch32 mode which was
         never the intention of the macro anyway.
      
      2. A static assert is added to sp_min linker script to check that the progbits
         are within the bounds expected when overlaid with other images.
      
      3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks
         involved when building Juno for AArch32 mode, the build option SPD needed to
         specifed. This patch corrects this and also updates the documentation in the
         user-guide.
      
      4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As
         a result the previous assumption that BL31 must be always present is removed
         and the certificates for BL31 is only generated if `NEED_BL31` is defined.
      
      Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8
      Signed-off-by: default avatarSoby Mathew <soby.mathew@arm.com>
      5744e874