1. 17 May, 2018 1 commit
  2. 16 May, 2018 7 commits
  3. 15 May, 2018 9 commits
  4. 14 May, 2018 2 commits
    • Sandrine Bailleux's avatar
      Fix doc for bl31_plat_get_next_image_ep_info() · 1ec1ebf7
      Sandrine Bailleux authored
      
      
      In the porting guide, fix the function name and the argument type to
      reflect the code.
      
      Change-Id: Iac8d69af403194de5586bc0d5890da531e3c8da2
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      1ec1ebf7
    • Antonio Nino Diaz's avatar
      Replace bootwrapped kernel instructions from User Guide · 32412a8a
      Antonio Nino Diaz authored
      
      
      The instructions to boot the bootwrapped kernel were outdated.
      
      Also, the bootwrapped kernel boot flow isn't really useful. It was meant
      to be a replacement for the Trusted Firmware-A, not to be used as the next
      step during boot.
      
      The instructions have been removed in favour of the new build option
      ARM_LINUX_KERNEL_AS_BL33. This new system directly boots the Linux
      kernel from BL31, and requires RESET_TO_BL31 to be 1. Also, the kernel
      has to be preloaded in memory, so PRELOADED_BL33_BASE has to be set to its
      address. This way, the runtime services of the Trusted Firmware-A are
      available for the kernel in the least possible amount of time.
      
      This new system requires the DTB to be patched so that the kernel knows
      where the ramdisk is. A short script to add this information to the DTB
      has been added to the User Guide. The information related to it can be
      found in the following file in the Linux kernel tree:
      ``Documentation/devicetree/bindings/chosen.txt``
      
      Change-Id: Ide135580959e09f6aa8e4425f37ea55d97439178
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      32412a8a
  5. 11 May, 2018 8 commits
    • Chris Kay's avatar
      css: Do not map the non-secure RAM as secure · d0223211
      Chris Kay authored
      
      
      Change-Id: I7e73c0ab134da11c49f990b739245110c59eac2b
      Signed-off-by: default avatarChris Kay <chris.kay@arm.com>
      d0223211
    • Chris Kay's avatar
      css: Fix erroneous non-secure RAM base address/size for SGI-575 · d7ecac73
      Chris Kay authored
      
      
      SGI-575's NSRAM is neither in the same place nor the same size as Juno's.
      
      Change-Id: Id6d692e9c7e9c1360014bb525eda966ebe29c823
      Signed-off-by: default avatarChris Kay <chris.kay@arm.com>
      d7ecac73
    • Chris Kay's avatar
      plat/arm: Fix incorrect bounds check in ARM_CASSERT_MMAP · 053b4f92
      Chris Kay authored
      
      
      The bounds check in ARM_CASSERT_MMAP does not take into account the
      array sentinel in plat_arm_mmap. This commit fixes this, and adds an
      additional check to ensure the number of entries in the array is
      within the bounds of PLAT_ARM_MMAP_ENTRIES.
      
      Change-Id: Ie6df10c0aa0890d62826bc3224ad7b3e36fd53e2
      Signed-off-by: default avatarChris Kay <chris.kay@arm.com>
      053b4f92
    • Chris Kay's avatar
      plat/arm: Fix incorrect number of reserved memory map entries · 3450fd62
      Chris Kay authored
      
      
      There are three calls to mmap_add_region() that always occur in
      arm_setup_page_tables(), and two further calls based on whether coherent
      memory is enabled, and whether SPM is enabled in BL31.
      
      This commit adapts the ARM_BL_REGIONS definition to match the number of
      calls made inside arm_setup_page_tables() so that the MAX_MMAP_REGIONS
      is realigned with what is actually occurring.
      
      Change-Id: I7adc05951abccf2cbd5c86280eb874911e6a1566
      Signed-off-by: default avatarChris Kay <chris.kay@arm.com>
      3450fd62
    • 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: Introduce ARM_LINUX_KERNEL_AS_BL33 build option · b726c169
      Antonio Nino Diaz authored
      
      
      Normally, BL33 needs to contain a boot loader like U-Boot or UEFI that
      eventually gives control to the OS. However, in some cases, this boot
      sequence may be too slow. For example, when doing tests in a
      cycle-accurate emulator, the user may only be interested in the
      interaction between the Trusted Firmware and the OS, not in the boot
      process itself.
      
      The new option ARM_LINUX_KERNEL_AS_BL33 allows BL33 to contain the Linux
      kernel image by changing the value of registers x0-x3 to the values
      expected by the kernel. This option requires the device tree blob (DTB)
      to be present in memory. Its address must be specified in the newly
      introduced ARM_PRELOADED_DTB_BASE build option. For now, it only supports
      AArch64 kernels.
      
      This option is only available when RESET_TO_BL31=1. For this reason
      the BL33 binary must be preloaded in memory and PRELOADED_BL33_BASE must
      be used.
      
      For example, if the kernel is loaded at 0x80080000 and the DTB is loaded
      at address 0x82000000, the firmware could be built like this:
      
          CROSS_COMPILE=aarch64-linux-gnu-  \
          make PLAT=fvp DEBUG=1             \
          RESET_TO_BL31=1                   \
          ARM_LINUX_KERNEL_AS_BL33=1        \
          PRELOADED_BL33_BASE=0x80080000    \
          ARM_PRELOADED_DTB_BASE=0x82000000 \
          all fip
      
      Change-Id: If9dc847c65ae2d0c27b51f0fd44fc06b28497db9
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      b726c169
    • 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
  6. 09 May, 2018 4 commits
  7. 08 May, 2018 2 commits
  8. 04 May, 2018 7 commits
    • Jeenu Viswambharan's avatar
      ARM Platforms: Support RAS · 0b9ce906
      Jeenu Viswambharan authored
      
      
        - Assign 0x10 for RAS exceptions on ARM platforms, and install
          EHF priority descriptor.
      
        - Call the common RAS initialisation from ARM BL31 setup.
      
        - Add empty definitions for platform error records and RAS interrupts.
      
      Change-Id: I0675f299b7840be4c83a9c7a81073a95c605dc90
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      0b9ce906
    • Jeenu Viswambharan's avatar
      RAS: Add fault injection support · 1a7c1cfe
      Jeenu Viswambharan authored
      
      
      The ARMv8.4 RAS extensions introduce architectural support for software
      to inject faults into the system in order to test fault-handling
      software. This patch introduces the build option FAULT_HANDLING_SUPPORT
      to allow for lower ELs to use registers in the Standard Error Record to
      inject fault. The build option RAS_EXTENSIONS must also be enabled along
      with fault injection.
      
      This feature is intended for testing purposes only, and is advisable to
      keep disabled for production images.
      
      Change-Id: I6f7a4454b15aec098f9505a10eb188c2f928f7ea
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      1a7c1cfe
    • Jeenu Viswambharan's avatar
      RAS: Allow individual interrupt registration · ca6d9185
      Jeenu Viswambharan authored
      
      
      EHF currently allows for registering interrupt handlers for a defined
      priority ranges. This is primarily targeted at various EL3 dispatchers
      to own ranges of secure interrupt priorities in order to delegate
      execution to lower ELs.
      
      The RAS support added by earlier patches necessitates registering
      handlers based on interrupt number so that error handling agents shall
      receive and handle specific Error Recovery or Fault Handling interrupts
      at EL3.
      
      This patch introduces a macro, RAS_INTERRUPTS() to declare an array of
      interrupt numbers and handlers. Error handling agents can use this macro
      to register handlers for individual RAS interrupts. The array is
      expected to be sorted in the increasing order of interrupt numbers.
      
      As part of RAS initialisation, the list of all RAS interrupts are sorted
      based on their ID so that, given an interrupt, its handler can be looked
      up with a simple binary search.
      
      For an error handling agent that wants to handle a RAS interrupt,
      platform must:
      
        - Define PLAT_RAS_PRI to be the priority of all RAS exceptions.
      
        - Enumerate interrupts to have the GIC driver program individual EL3
          interrupts to the required priority range. This is required by EHF
          even before this patch.
      
      Documentation to follow.
      
      Change-Id: I9471e4887ff541f8a7a63309e9cd8f771f76aeda
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      ca6d9185
    • Jeenu Viswambharan's avatar
      RAS: Add support for node registration · 362599ec
      Jeenu Viswambharan authored
      
      
      Previous patches added frameworks for handling RAS errors. This patch
      introduces features that the platform can use to enumerate and iterate
      RAS nodes:
      
        - The REGISTER_RAS_NODES() can be used to expose an array of
          ras_node_info_t structures. Each ras_node_info_t describes a RAS
          node, along with handlers for probing the node for error, and if
          did record an error, another handler to handle it.
      
        - The macro for_each_ras_node() can be used to iterate over the
          registered RAS nodes, probe for, and handle any errors.
      
      The common platform EA handler has been amended using error handling
      primitives introduced by both this and previous patches.
      
      Change-Id: I2e13f65a88357bc48cd97d608db6c541fad73853
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      362599ec
    • Jeenu Viswambharan's avatar
      RAS: Add helpers to access Standard Error Records · 30d81c36
      Jeenu Viswambharan authored
      
      
      The ARMv8 RAS Extensions introduced Standard Error Records which are a
      set of standard registers through which:
      
        - Platform can configure RAS node policy; e.g., notification
          mechanism;
      
        - RAS nodes can record and expose error information for error handling
          agents.
      
      Standard Error Records can either be accessed via. memory-mapped
      or System registers. This patch adds helper functions to access
      registers and fields within an error record.
      
      Change-Id: I6594ba799f4a1789d7b1e45b3e17fd40e7e0ba5c
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      30d81c36
    • Jeenu Viswambharan's avatar
      AArch64: Introduce RAS handling · 14c6016a
      Jeenu Viswambharan authored
      
      
      RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional
      extensions to base ARMv8.0 architecture.
      
      This patch adds build system support to enable RAS features in ARM
      Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for
      this.
      
      With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is
      inserted at all EL3 vector entry and exit. ESBs will synchronize pending
      external aborts before entering EL3, and therefore will contain and
      attribute errors to lower EL execution. Any errors thus synchronized are
      detected via. DISR_EL1 register.
      
      When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1.
      
      Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      14c6016a
    • Jeenu Viswambharan's avatar
      AArch64: Introduce External Abort handling · 76454abf
      Jeenu Viswambharan authored
      
      
      At present, any External Abort routed to EL3 is reported as an unhandled
      exception and cause a panic. This patch enables ARM Trusted Firmware to
      handle External Aborts routed to EL3.
      
      With this patch, when an External Abort is received at EL3, its handling
      is delegated to plat_ea_handler() function. Platforms can provide their
      own implementation of this function. This patch adds a weak definition
      of the said function that prints out a message and just panics.
      
      In order to support handling External Aborts at EL3, the build option
      HANDLE_EA_EL3_FIRST must be set to 1.
      
      Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to
      compilation; this patch fixes that too.
      
      Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      76454abf