1. 09 Feb, 2021 2 commits
    • Andre Przywara's avatar
      plat/arm: Remove ARM_LINUX_KERNEL_AS_BL33 relying on RESET_TO_BL31 · e27340a7
      Andre Przywara authored
      
      
      So far the ARM platform Makefile would require that RESET_TO_BL31 is set
      when we ask for the ARM_LINUX_KERNEL_AS_BL33 feature.
      There is no real technical reason for that, and the one place in the
      code where this was needed has been fixed.
      
      Remove the requirement of those two options to be always enabled
      together.
      This enables the direct kernel boot feature for the Foundation FVP
      (as described in the documentation), which requires a BL1/FIP
      combination to boot, so cannot use RESET_TO_BL31.
      
      Change-Id: I6814797b6431b6614d684bab3c5830bfd9481851
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      e27340a7
    • Andre Przywara's avatar
      plat/arm: Always allow ARM_LINUX_KERNEL_AS_BL33 · c99b8c89
      Andre Przywara authored
      
      
      At the moment we have the somewhat artifical limitation of
      ARM_LINUX_KERNEL_AS_BL33 only being used together with RESET_TO_BL31.
      
      However there does not seem to be a good technical reason for that,
      it was probably just to differentate between two different boot flows.
      
      Move the initial register setup for ARM_LINUX_KERNEL_AS_BL33 out of the
      RESET_TO_BL31 #ifdef, so that we initialise the registers in any case.
      
      This allows to use a preloaded kernel image when using BL1 and FIP.
      
      Change-Id: I832df272d3829f077661f4ee6d3dd9a276a0118f
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      c99b8c89
  2. 20 Jan, 2021 3 commits
    • Ming Huang's avatar
      plat/arm/css/sgi: Fix assert expression issue · 0301d09c
      Ming Huang authored
      
      
      Violation of MISRA-C Rule 14.4
      Signed-off-by: default avatarMing Huang <huangming@linux.alibaba.com>
      Change-Id: I44ef50dadb54fb056a91f3de962b6e63ba6d7ac4
      0301d09c
    • Ming Huang's avatar
      plat/arm/css/sgi: Fix bl32 receive event - 0xC4000061 issue · 9feb1e2f
      Ming Huang authored
      
      
      The issue is that, when interrupt is triggered and RAS handler
      is entered, after interrupt handler finishes, TF-A will re-enter
      bl32 and then crash.
      sdei_dispatch_event() may return failing result in some cases,
      for example kernel may not have registered a handler or RAS event
      may happen early during boot. We restore the NS context when
      sdei_dispatch_event() returns failing result.
      
      error log :
      Received delegated event
      X0 :  0xC4000061
      X1 :  0x0
      X2 :  0x0
      X3 :  0x0
      Received event - 0xC4000061 on cpu 0
      UnRecognized Event - 0xC4000061
      Failed delegated event 0xC4000061, Status Invalid Parameter
      Unhandled Exception in EL3.
      x30            = 0x000000000401f700
      x0             = 0xfffffffffffffffe
      x1             = 0xfffffffffffffffe
      x2             = 0x00000000600003c0
      Signed-off-by: default avatarMing Huang <huangming@linux.alibaba.com>
      Change-Id: I9802e9a32eee0ac3b5a8bcc0362d0b0e3b71dc9f
      9feb1e2f
    • Jagadeesh Ujja's avatar
      plat/arm: css: Turn ON/OFF redistributor in sync with GIC CPU interface ON/OFF · 4d8c1819
      Jagadeesh Ujja authored
      
      
      Turn ON/OFF GIC redistributor in sync with GIC CPU interface ON/OFF.
      
      Issue :
      The Linux prompt hangs when all the cores in a cluster are turned OFF
      and we try to turn ON a core in that cluster. Previously when TF-A turns
      ON a core, TF-A first turns ON the redistributor followed by the core.
      This did not match the flow when turning OFF a core, as TF-A did not
      turn OFF redistributor when the corresponding core[s] are disabled.
      This hang is resolved by disabling redistributor as cores are disabled,
      keeping them in sync.
      Signed-off-by: default avatarJagadeesh Ujja <jagadeesh.ujja@arm.com>
      Change-Id: Ifd04fdcfd47b45e00f874f15b098471883d023f0
      4d8c1819
  3. 11 Jan, 2021 2 commits
  4. 07 Jan, 2021 1 commit
    • Pali Rohár's avatar
      Makefile: Do not mark file targets as .PHONY target · a9812206
      Pali Rohár authored
      
      
      Only non-file targets should be set a .PHONY. Otherwise if file target is
      set as .PHONY then targets which depends on those file .PHONY targets would
      be always rebuilt even when their prerequisites are not changed.
      
      File target which needs to be always rebuilt can be specified in Make
      system via having a prerequisite on some .PHONY target, instead of marking
      whole target as .PHONY. In Makefile projects it is common to create empty
      .PHONY target named FORCE for this purpose.
      
      This patch changes all file targets which are set as .PHONY to depends on
      new .PHONY target FORCE, to ensure that these file targets are always
      rebuilt (as before). Basically they are those targets which calls external
      make subprocess.
      
      After FORCE target is specified in main Makefile, remove it from other
      Makefile files to prevent duplicate definitions.
      Signed-off-by: default avatarPali Rohár <pali@kernel.org>
      Change-Id: Iee3b4e0de93879b95eb29a1745a041538412e69e
      a9812206
  5. 16 Dec, 2020 1 commit
  6. 14 Dec, 2020 2 commits
  7. 09 Dec, 2020 6 commits
  8. 08 Dec, 2020 4 commits
  9. 30 Nov, 2020 1 commit
  10. 28 Oct, 2020 1 commit
    • David Horstmann's avatar
      Use constant stack size with RECLAIM_INIT_CODE · 3ed5606b
      David Horstmann authored
      
      
      Currently, when RECLAIM_INIT_CODE is set, the
      stacks are scaled to ensure that the entirety
      of the init section can be reclaimed as stack.
      
      This causes an issue in lib/psci/aarch64/psci_helpers.S,
      where the stack size is used for cache operations in
      psci_do_pwrdown_cache_maintenance(). If the stacks
      are scaled, then the PSCI code may fail to invalidate
      some of the stack memory before power down.
      
      Resizing stacks is also not good for stability in general,
      since code that works with a small number of cores may
      overflow the stack when the number of cores is increased.
      
      Change to make every stack be PLATFORM_STACK_SIZE big,
      and allow the total stack to be smaller than the
      init section.
      
      Any pages of the init section not reclaimed as
      stack will be set to read-only and execute-never,
      for security.
      
      Change-Id: I10b3884981006431f2fcbec3864c81d4a8c246e8
      Signed-off-by: default avatarDavid Horstmann <david.horstmann@arm.com>
      3ed5606b
  11. 21 Oct, 2020 1 commit
  12. 20 Oct, 2020 5 commits
  13. 12 Oct, 2020 1 commit
    • Jimmy Brisson's avatar
      Increase type widths to satisfy width requirements · d7b5f408
      Jimmy Brisson authored
      
      
      Usually, C has no problem up-converting types to larger bit sizes. MISRA
      rule 10.7 requires that you not do this, or be very explicit about this.
      This resolves the following required rule:
      
          bl1/aarch64/bl1_context_mgmt.c:81:[MISRA C-2012 Rule 10.7 (required)]<None>
          The width of the composite expression "0U | ((mode & 3U) << 2U) | 1U |
          0x3c0U" (32 bits) is less that the right hand operand
          "18446744073709547519ULL" (64 bits).
      
      This also resolves MISRA defects such as:
      
          bl2/aarch64/bl2arch_setup.c:18:[MISRA C-2012 Rule 12.2 (required)]
          In the expression "3U << 20", shifting more than 7 bits, the number
          of bits in the essential type of the left expression, "3U", is
          not allowed.
      
      Further, MISRA requires that all shifts don't overflow. The definition of
      PAGE_SIZE was (1U << 12), and 1U is 8 bits. This caused about 50 issues.
      This fixes the violation by changing the definition to 1UL << 12. Since
      this uses 32bits, it should not create any issues for aarch32.
      
      This patch also contains a fix for a build failure in the sun50i_a64
      platform. Specifically, these misra fixes removed a single and
      instruction,
      
          92407e73        and     x19, x19, #0xffffffff
      
      from the cm_setup_context function caused a relocation in
      psci_cpus_on_start to require a linker-generated stub. This increased the
      size of the .text section and caused an alignment later on to go over a
      page boundary and round up to the end of RAM before placing the .data
      section. This sectionn is of non-zero size and therefore causes a link
      error.
      
      The fix included in this reorders the functions during link time
      without changing their ording with respect to alignment.
      
      Change-Id: I76b4b662c3d262296728a8b9aab7a33b02087f16
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      d7b5f408
  14. 09 Oct, 2020 1 commit
    • Jimmy Brisson's avatar
      Don't return error information from console_flush · 831b0e98
      Jimmy Brisson authored
      
      
      And from crash_console_flush.
      
      We ignore the error information return by console_flush in _every_
      place where we call it, and casting the return type to void does not
      work around the MISRA violation that this causes. Instead, we collect
      the error information from the driver (to avoid changing that API), and
      don't return it to the caller.
      
      Change-Id: I1e35afe01764d5c8f0efd04f8949d333ffb688c1
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      831b0e98
  15. 06 Oct, 2020 1 commit
    • Usama Arif's avatar
      plat/arm: common: add guard for arm_get_rotpk_info_regs · 3bfcc9d7
      Usama Arif authored
      
      
      Only define arm_get_rotpk_info_regs if ROTPK is in registers,
      i.e. (ARM_ROTPK_LOCATION_ID == ARM_ROTPK_REGS_ID). This will
      allow platform build without definition of TZ_PUB_KEY_HASH_BASE
      if dedicated registers for ROTPK are not available on the platform.
      
      Change-Id: I74ee2d5007f5d876a031a1efca20ebee2dede0c7
      Signed-off-by: default avatarUsama Arif <usama.arif@arm.com>
      3bfcc9d7
  16. 05 Oct, 2020 2 commits
  17. 02 Oct, 2020 1 commit
  18. 29 Sep, 2020 5 commits
    • Andre Przywara's avatar
      arm_fpga: Add post-build linker script · 01301b11
      Andre Przywara authored
      
      
      For the Arm Ltd. FPGAs to run, we need to load several payloads into the
      FPGA's memory:
      - Some trampoline code at address 0x0, to jump to BL31's entry point.
      - The actual BL31 binary at the beginning of DRAM.
      - The (generic) DTB image to describe the hardware.
      - The actual non-secure payloads (kernel, ramdisks, ...)
      
      The latter is application specific, but the first three blobs are rather
      generic.
      Since the uploader tool supports ELF binaries, it seems helpful to
      combine these three images into one .axf file, as this also simplifies
      the command line.
      
      Add a post-build linker script, that combines those three bits into one
      ELF file, together with their specific load addresses.
      Include a call to "ld" with this linker script in the platform Makefile,
      so it will be build automatically. The result will be called "bl31.axf".
      
      Change-Id: I4a90da16fa1e0e83b51d19e5b1daf61f5a0bbfca
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      01301b11
    • Andre Przywara's avatar
      arm_fpga: Add ROM trampoline · f45c6d86
      Andre Przywara authored
      
      
      The application cores of the FPGAs used in Arm Ltd. start execution at
      address 0x0. This is the location of some (emulated) ROM area (which can
      be written to by the uploading tool).
      Since the arm_fpga port is configured to run from DRAM, we load BL31 to
      the beginning of DRAM (mapped at 2GB). This requires some small
      trampoline code in the "ROM" to jump to the BL31 entry point.
      
      To avoid some extra magic binary, add a tiny assembly file with that
      trivial jump instruction to the tree, so this binary can be created
      alongside BL31.
      
      Change-Id: I9e4439fc0f093fa24dd49a8377c9edb030fbb477
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      f45c6d86
    • Andre Przywara's avatar
      arm_fpga: Add devicetree file · b48883c7
      Andre Przywara authored
      
      
      The FPGA images used in Arm Ltd. focus on CPU cores, so they share a
      common platform, with a minimal set of peripherals (interconnect, GIC,
      UART).
      This allows to support most platforms with a single devicetree file.
      The topology and number of CPU cores differ, but those will added at
      runtime, in BL31. Other adjustments (GICR size, SPE node, command line)
      are also done at this point.
      
      Add the common devicetree file to TF-A's build system, so it can be
      build together with BL31. At runtime, the resulting .dtb file should be
      uploaded to the address given with FPGA_PRELOADED_DTB_BASE at build time.
      
      Change-Id: I3206d6131059502ec96896e95329865452c9d83e
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      b48883c7
    • Andre Przywara's avatar
      arm_fpga: Remove SPE PMU DT node if SPE is not available · 40a0de19
      Andre Przywara authored
      
      
      The Statistical Profiling Extension (SPE) is an architectural feature we
      can safely detect at runtime. However it still relies on one piece of
      platform-specific information: the interrupt line it is connected
      to. This requires SPE to be described in a devicetree node.
      
      Since SPE support varies with the CPU cores found on an FPGA image, we
      should detect the presence of SPE at runtime, and remove a potentially
      existing SPE PMU node from the DT.
      
      This allows to always have the SPE node in a generic devicetree file,
      without risking exposing it on a CPU without this feature.
      
      Change-Id: I73d83ea8509b03fe7bba20b9cce8d1335035fa31
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      40a0de19
    • Andre Przywara's avatar
      arm_fpga: Adjust GICR size in DT to match number of cores · 283e5595
      Andre Przywara authored
      
      
      The size of a GICv3 redistributor region depends on the number of
      cores in the system. For the ARM FPGA port, we detect the topology at
      runtime, and adjust the CPU DT nodes accordingly.
      Now the size of the GICR region must also be adjusted, or Linux will
      fail to initialise the GICv3.
      
      Use the newly introduced function to overwrite the GICR size entry in
      the GICv3 reg property. We count the number of existing cores by
      iterating over the GICR frames until we find the LAST bit set in TYPER.
      
      Change-Id: Ib69565600859de9b1b15ceb8495172cd26d16fce
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      283e5595