1. 30 Apr, 2020 2 commits
    • Andre Przywara's avatar
      arm: fconf: Fix GICv3 dynamic configuration · 364ad245
      Andre Przywara authored
      
      
      At the moment the fconf_populate_gicv3_config() implementation is
      somewhat incomplete: First it actually fails to store the retrieved
      information (the local addr[] array is going nowhere), but also it makes
      quite some assumptions about the device tree passed to it: it needs to
      use two address-cells and two size-cells, and also requires all five
      register regions to be specified, where actually only the first two
      are mandatory according to the binding (and needed by our code).
      
      Fix this by introducing a proper generic function to retrieve "reg"
      property information from a DT node:
      We retrieve the #address-cells and #size-cells properties from the
      parent node, then use those to extract the right values from the "reg"
      property. The function takes an index to select one region of a reg
      property.
      
      This is loosely based on the STM32 implementation using "reg-names",
      which we will subsume in a follow-up patch.
      
      Change-Id: Ia59bfdf80aea4e36876c7b6ed4d153e303f482e8
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      364ad245
    • Louis Mayencourt's avatar
      fconf: Update dyn_config compatible string · 592c396d
      Louis Mayencourt authored
      
      
      Dynamic configuration properties are fconf properties. Modify the
      compatible string from "arm,.." to "fconf,.." to reflect this.
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      Change-Id: I85eb75cf877c5f4d3feea3936d4c348ca843bc6c
      592c396d
  2. 29 Apr, 2020 1 commit
    • Andre Przywara's avatar
      fdt/wrappers: Replace fdtw_read_cells() implementation · ff4e6c35
      Andre Przywara authored
      Our fdtw_read_cells() implementation goes to great lengths to
      sanity-check every parameter and result, but leaves a big hole open:
      The size of the storage the value pointer points at needs to match the
      number of cells given. This can't be easily checked at compile time,
      since we lose the size information by using a void pointer.
      Regardless the current usage of this function is somewhat wrong anyways,
      since we use it on single-element, fixed-length properties only, for
      which the DT binding specifies the size.
      Typically we use those functions dealing with a number of cells in DT
      context to deal with *dynamically* sized properties, which depend on
      other properties (#size-cells, #clock-cells, ...), to specify the number
      of cells needed.
      
      Another problem with the current implementation is the use of
      ambiguously sized types (uintptr_t, size_t) together with a certain
      expectation about their size. In general there is no relation between
      the length of a DT property and the bitness of the code that parses the
      DTB: AArch64 code could encounter 32-bit addresses (where the physical
      address space is limited to 4GB [1]), while AArch32 code could read
      64-bit sized properties (/memory nodes on LPAE systems, [2]).
      
      To make this more clear, fix the potential issues and also align more
      with other DT users (Linux and U-Boot), introduce functions to explicitly
      read uint32 and uint64 properties. As the other DT consumers, we do this
      based on the generic "read array" function.
      Convert all users to use either of those two new functions, and make
      sure we never use a pointer to anything other than uint32_t or uint64_t
      variables directly.
      
      This reveals (and fixes) a bug in plat_spmd_manifest.c, where we write
      4 bytes into a uint16_t variable (passed via a void pointer).
      
      Also we change the implementation of the function to better align with
      other libfdt users, by using the right types (fdt32_t) and common
      variable names (*prop, prop_names).
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#n874
      [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/ecx-2000.dts
      
      
      
      Change-Id: I718de960515117ac7a3331a1b177d2ec224a3890
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      ff4e6c35
  3. 28 Apr, 2020 1 commit
    • Andre Przywara's avatar
      fdt/wrappers: Generalise fdtw_read_array() · 6e3a89f4
      Andre Przywara authored
      
      
      Currently our fdtw_read_array() implementation requires the length of
      the property to exactly match the requested size, which makes it less
      flexible for parsing generic device trees.
      Also the name is slightly misleading, since we treat the cells of the
      array as 32 bit unsigned integers, performing the endianess conversion.
      
      To fix those issues and align the code more with other DT users (Linux
      kernel or U-Boot), rename the function to "fdt_read_uint32_array", and
      relax the length check to only check if the property covers at least the
      number of cells we request.
      This also changes the variable names to be more in-line with other DT
      users, and switches to the proper data types.
      
      This makes this function more useful in later patches.
      
      Change-Id: Id86f4f588ffcb5106d4476763ecdfe35a735fa6c
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      6e3a89f4
  4. 23 Apr, 2020 2 commits
  5. 17 Apr, 2020 1 commit
  6. 15 Apr, 2020 1 commit
  7. 14 Apr, 2020 1 commit
    • Aditya Angadi's avatar
      plat/arm/sgi: update mmap and xlat count · def3b54b
      Aditya Angadi authored
      
      
      A single chip platform requires five mmap entries and a corresponding
      number of translation tables. For every additional chip in the system,
      three additional mmap entries are required to map the shared SRAM and
      the IO regions. A corresponding number of additional translation
      tables are required as well.
      
      Change-Id: I1332a1305f2af62181387cf36954f6fb0e6f11ed
      Signed-off-by: default avatarAditya Angadi <aditya.angadi@arm.com>
      def3b54b
  8. 09 Apr, 2020 1 commit
    • Andre Przywara's avatar
      arm_fpga: Remove bogus timer initialisation · a82ea1db
      Andre Przywara authored
      
      
      The arm_fpga platform code contains an dubious line to initialise some
      timer. On closer inspection this turn out to be bogus, as this was only
      needed on some special (older) FPGA board, and is actually not needed on
      the current model. Also the base address was wrong anyways.
      
      Remove the code entirely.
      
      Change-Id: I02e71aea645051b5addb42d972d7a79f04b81106
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      a82ea1db
  9. 07 Apr, 2020 3 commits
  10. 03 Apr, 2020 1 commit
  11. 02 Apr, 2020 3 commits
  12. 31 Mar, 2020 1 commit
  13. 30 Mar, 2020 3 commits
  14. 27 Mar, 2020 1 commit
  15. 26 Mar, 2020 8 commits
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Compile with additional CPU libraries · 4b5793c9
      Oliver Swede authored
      
      
      This change is part of the goal of enabling the port to be compatible
      with multiple FPGA images.
      
      BL31 behaves differently depending on whether or not the CPUs in the
      system use cache coherency, and as a result any CPU libraries that are
      compiled together must serve processors that are consistent in this
      regard.
      
      This compiles a different set of CPU libraries depending on whether or
      not the HW_ASSISTED_COHERENCY is enabled at build-time to indicate the
      CPUs support hardware-level support for cache coherency. This build
      flag is used in the makefile in the same way as the Arm FVP port.
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: I18300b4443176b89767015e3688c0f315a91c27e
      4b5793c9
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Enable position-independent execution · 62056e4e
      Oliver Swede authored
      
      
      This allows the BL31 port to run with position-independent execution
      enabled so that it can be ran from any address in the system.
      This increases the flexibility of the image, allowing it to be ran from
      other locations rather than only its hardcoded absolute address
      (currently set to the typical DRAM base of 2GB). This may be useful for
      future images that describe system configurations with other memory
      layouts (e.g. where SRAM is included).
      
      It does this by setting ENABLE_PIE=1 and changing the absolute
      address to 0. The load address of bl31.bin can then be specified by
      the -l [load address] argument in the fpga-run command (additionally,
      this address is required by any preceding payloads that specify the
      start address. For ELF payloads this is usually extracted automatically
      by reading the entrypoint address in the header, however bl31.bin is a
      different file format so has this additional dependency).
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: Idd74787796ab0cf605fe2701163d9c4b3223a143
      62056e4e
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Enable port for alternative cluster configurations · e726c758
      Oliver Swede authored
      
      
      This change is part of the goal of enabling the port to be compatible
      with multiple FPGA images.
      
      The BL31 port that is uploaded as a payload to the FPGA with an image
      should cater for a wide variety of system configurations. This patch
      makes the necessary changes to enable it to function with images whose
      cluster configurations may be larger (either by utilizing more
      clusters, more CPUs per cluster, more threads in each CPU, or a
      combination) than the initial image being used for testing.
      
      As part of this, the hard-coded values that configure the size of the
      array describing the topology of the power domain tree are increased
      to max. 8 clusters, max. 8 cores per cluster & max 4 threads per core.
      This ensures the port works with cluster configurations up to these
      sizes. When there are too many entries for the number of available PEs,
      e.g. if there is a variable number of CPUs between clusters, then there
      will be empty entries in the array. This is permitted and the PSCI
      library will still function as expected. While this increases its size,
      this shouldn't be an issue in the context of the size of BL31, and is
      worth the trade-off for the extra compatibility.
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: I7d4ae1e20b2e99fdbac428d122a2cf9445394363
      e726c758
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Initialize the Generic Interrupt Controller · 87762bce
      Oliver Swede authored
      
      
      This initializes the GIC using the Arm GIC drivers in TF-A.
      The initial FPGA image uses a GIC600 implementation, and so that its
      power controller is enabled, this platform port calls the corresponding
      implementation-specific routines.
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: I88d5a073eead4b653b1ca73273182cd98a95e4c5
      87762bce
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Initialize the System Counter · 2d696d18
      Oliver Swede authored
      
      
      This sets the frequency of the system counter so that the Delay Timer
      driver programs the correct value to CNTCRL. This value depends on
      the FPGA image being used, and is 10MHz for the initial test image.
      Once configured, the BL31 platform setup sequence then enables the
      system counter.
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: Ieb036a36fd990f350b5953357424a255b8ac5d5a
      2d696d18
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Add PSCI implementation for FPGA images · 7ee4db6e
      Oliver Swede authored
      
      
      This adds a basic PSCI implementation allow secondary CPUs to be
      released from an initial state and continue through to the warm boot
      entrypoint.
      
      Each secondary CPU is kept in a holding pen, whereby it polls the value
      representing its hold state, by reading this from an array that acts as
      a table for all the PEs. The hold states are initially set to 0 for all
      cores to indicate that the executing core should continue polling.
      To prevent the secondary CPUs from interfering with the platform's
      initialization, they are only updated by the primary CPU once the cold
      boot sequence has completed and fpga_pwr_domain_on(mpidr) is called.
      The polling target CPU will then read 1 (which indicates that it should
      branch to the warm reset entrypoint) and then jump to that address
      rather than continue polling.
      
      In addition to the initial polling behaviour of the secondary CPUs
      before their warm boot reset sequence, they are also placed in a
      low-power wfe() state at the end of each poll; accordingly, the PSCI
      fpga_pwr_domain_on(mpidr) function also signals an event to all cores
      (after updating the target CPU's hold entry) to wake them from this
      state, allowing any secondary CPUs that are still polling to check
      their hold state again.
      This method is in accordance with both the PSCI and Linux kernel
      recommendations, as the lessened overhead reduces the energy
      consumption associated with the busy-loop.
      
      The table of hold entries is implemented by a global array as shared SRAM
      (which is used by other platforms in similar implementations) is not
      available on the FPGA images.
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: I65cfd1892f8be1dfcb285f0e1e94e7a9870cdf5a
      7ee4db6e
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Use preloaded BL33 alternative boot flow · 5cfe699f
      Oliver Swede authored
      This makes use of the PRELOADED_BL33_BASE flag to indicate to BL31 that
      the BL33 payload (kernel) has already been loaded and resides in memory;
      BL31 will then jump to the non-secure address.
      
      For this port the BL33 payload is the Linux kernel, and in accordance
      with the pre-kernel setup requirements (as specified in the `Booting
      AArch64 Linux' documentation:
      https://www.kernel.org/doc/Documentation/arm64/booting.txt
      
      ),
      this change also sets up the primary CPU's registers x0-x3 so they are
      the expected values, which includes the address of the DTB at x0.
      
      An external linker script is currently required to combine BL31, the
      BL33 payload, and any other software images to create an ELF file that
      can be uploaded to the FPGA board along with the bit file. It therefore
      has dependencies on the value of PRELOADED_BL33_BASE (kernel base) and
      the DTB base (plus any other relevant base addresses used to
      distinguish the different ELF sections), both of which are set in this
      patch.
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: If7ae8ee82d1e09fb05f553f6077ae13680dbf66b
      5cfe699f
    • Oliver Swede's avatar
      plat/arm/board/arm_fpga: Enable basic BL31 port for an FPGA image · 536d906a
      Oliver Swede authored
      
      
      This adds the minimal functions and definitions to create a basic
      BL31 port for an initial FPGA image, in order for the port to be
      uploaded to one the FPGA boards operated by an internal group within
      Arm, such that BL31 runs as a payload for an image.
      
      Future changes will enable the port for a wide range of system
      configurations running on the FPGA boards to ensure compatibility with
      multiple FPGA images.
      
      It is expected that this will replace the FPGA fork of the Linux kernel
      bootwrapper by performing similar secure-world initialization and setup
      through the use of drivers and other well-established methods, before
      passing control to the kernel, which will act as the BL33 payload and
      run in EL2NS.
      
      This change introduces a basic, loadable port with the console
      initialized by setting the baud rate and base address of the UART as
      configured by the Zeus image.
      
      It is a BL31-only port, and RESET_TO_BL31 is enabled to reflect this.
      Signed-off-by: default avatarOliver Swede <oli.swede@arm.com>
      Change-Id: I1817ad81be00afddcdbbda1ab70eb697203178e2
      536d906a
  16. 25 Mar, 2020 1 commit
  17. 23 Mar, 2020 1 commit
  18. 19 Mar, 2020 2 commits
    • Manish Pandey's avatar
      fvp: use two instances of Cactus at S-EL1 · 161dbc43
      Manish Pandey authored
      
      
      To demonstrate communication between SP's two instances of Cactus at
      S-EL1 has been used.
      This patch replaces Ivy SP with cactus-secondary SP which aligns with
      changes in tf-a-tests repository.
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      Change-Id: Iee84f1f7f023b7c4f23fbc13682a42614a7f3707
      161dbc43
    • Olivier Deprez's avatar
      spmc: manifest changes to support two sample cactus secure partitions · 3d5ed6de
      Olivier Deprez authored
      
      
      When using the SPM Dispatcher, the SPMC sits as a BL32 component
      (BL32_IMAGE_ID). The SPMC manifest is passed as the TOS fw config
      component (TOS_FW_CONFIG_ID). It defines platform specific attributes
      (memory range and physical CPU layout) as well as the attributes for
      each secure partition (mostly load address). This manifest is passed
      to the SPMC on boot up. An SP package contains the SP dtb in the SPCI
      defined partition manifest format. As the SPMC manifest was enriched
      it needs an increase of tos_fw-config max-size in fvp_fw_config dts.
      Signed-off-by: default avatarOlivier Deprez <olivier.deprez@arm.com>
      Change-Id: Ia1dce00c6c4cbaa118fa56617980d32e2956a94e
      3d5ed6de
  19. 17 Mar, 2020 2 commits
  20. 16 Mar, 2020 1 commit
    • Louis Mayencourt's avatar
      fconf: Clean Arm IO · a6de824f
      Louis Mayencourt authored
      
      
      Merge the previously introduced arm_fconf_io_storage into arm_io_storage. This
      removes the duplicate io_policies and functions definition.
      
      This patch:
      - replace arm_io_storage.c with the content of arm_fconf_io_storage.c
      - rename the USE_FCONF_BASED_IO option into ARM_IO_IN_DTB.
      - use the ARM_IO_IN_DTB option to compile out io_policies moved in dtb.
      - propagate DEFINES when parsing dts.
      - use ARM_IO_IN_DTB to include or not uuid nodes in fw_config dtb.
      - set the ARM_IO_IN_DTB to 0 by default for fvp. This ensure that the behavior
        of fvp stays the same as it was before the introduction of fconf.
      
      Change-Id: Ia774a96d1d3a2bccad29f7ce2e2b4c21b26c080e
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      a6de824f
  21. 13 Mar, 2020 1 commit
  22. 12 Mar, 2020 2 commits