1. 26 Mar, 2020 3 commits
    • 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
  2. 18 Mar, 2020 3 commits
  3. 17 Mar, 2020 9 commits
    • Manish Pandey's avatar
    • Madhukar Pappireddy's avatar
      FVP: In BL31/SP_MIN, map only the needed DRAM region statically · 493545b3
      Madhukar Pappireddy authored
      
      
      Rather than creating entry in plat_arm_mmap array to map the
      entire DRAM region in BL31/SP_MIN, only map a smaller region holding
      HW_CONFIG DTB. Consequently, an increase in number of sub-translation
      tables(level-2 and level-3) i.e., MAX_XLAT_TABLES is necessary to map
      the new region in memory.
      
      In order to accommodate the increased code size in BL31 i.e.,
      PROGBITS, the max size of BL31 image is increased by 0x1000(4K).
      
      Change-Id: I540b8ee550588e22a3a9fb218183d2ab8061c851
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      493545b3
    • Andre Przywara's avatar
      rpi: docs: Update maintainers file to new RPi directory scheme · 9aaae8e6
      Andre Przywara authored
      
      
      With the addition of the Raspberry Pi 4 port the directory structure
      changed a bit, also the new port didn't have a separate entry.
      
      Add a new entry for the RPi4 port and adjust the path names.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Change-Id: I04b60e729a19bb0cc3dd6ce6899ec6480356b1f1
      9aaae8e6
    • Andre Przywara's avatar
      rpi: console: Autodetect Mini-UART vs. PL011 configuration · 9cc3fa1b
      Andre Przywara authored
      
      
      The Raspberry Pi has two different UART devices pin-muxed to GPIO 14&15:
      One ARM PL011 one and the 8250 compatible "Mini-UART".
      A dtoverlay parameter in config.txt will tell the firmware to switch
      between the two: it will setup the right clocks and will configure the
      pinmuxes accordingly.
      
      To autodetect the user's choice, we read the pinmux register and check
      its setting: ALT5 (0x2) means the Mini-UART is used, ALT0 (0x4) points
      to the PL011.
      Based on that we select the UART driver to initialise.
      
      This will allow console output in any case.
      
      Change-Id: I620d3ce68de6c6576599f2a405636020e1fd1376
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      9cc3fa1b
    • Andre Przywara's avatar
      rpi3: build: Include GPIO driver in all BL stages · 29e8c460
      Andre Przywara authored
      
      
      So far the Raspberry Pi 3 build needs the GPIO driver just for BL2.
      Upcoming changes will require some GPIO code in BL1 and BL31 also, so
      move those driver files into the common source section.
      
      This does not affect BL31 code size at all, and bl1.bin just increases
      by 144 bytes, but doesn't affect the padded binary size at all.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Change-Id: I7639746dc241c1e69099d85d2671c65fa0108555
      29e8c460
    • Andre Przywara's avatar
      rpi: Allow using PL011 UART for RPi3/RPi4 · 5e6d821c
      Andre Przywara authored
      
      
      The Broadcom 283x SoCs feature multiple UARTs: the mostly used
      "Mini-UART", which is an 8250 compatible IP, and at least one PL011.
      While the 8250 is usually used for serial console purposes, it suffers
      from a design flaw, where its clock depends on the VPU clock, which can
      change at runtime. This will reliably mess up the baud rate.
      To avoid this problem, people might choose to use the PL011 UART for
      the serial console, which is pin-mux'ed to the very same GPIO pins.
      This can be done by adding "miniuart-bt" to the "dtoverlay=" line in
      config.txt.
      
      To prepare for this situation, use the newly gained freedom of sharing
      one console_t pointer across different UART drivers, to introduce the
      option of choosing the PL011 for the console.
      
      This is for now hard-coded to choose the Mini-UART by default.
      A follow-up patch will introduce automatic detection.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Change-Id: I8cf2522151e09ff4ff94a6d396aec6fc4b091a05
      5e6d821c
    • Andre Przywara's avatar
      rpi3: console: Use same "clock-less" setup scheme as RPi4 · 795aefe5
      Andre Przywara authored
      
      
      In the wake of the upcoming unification of the console setup code
      between RPi3 and RPi4, extend the "clock-less" setup scheme to the
      RPi3. This avoid programming any clocks or baud rate registers,
      which makes the port more robust against GPU firmware changes.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Change-Id: Ida83a963bb18a878997e9cbd55f8ceac6a2e1c1f
      795aefe5
    • Andre Przywara's avatar
      rpi3: gpio: Simplify GPIO setup · 0d92745e
      Andre Przywara authored
      
      
      There is really no reason to use and pass around a struct when its only
      member is the (fixed) base address.
      
      Remove the struct and just use the base address on its own inside the
      GPIO driver. Then set the base address automatically.
      
      This simplifies GPIO setup for users, which now don't need to deal with
      zeroing a struct and setting the base address anymore.
      
      Change-Id: I3060f7859e3f8ef9a24cc8fb38307b5da943f127
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      0d92745e
    • Manish V Badarkhe's avatar
      Implement SMCCC_ARCH_SOC_ID SMC call · 0e753437
      Manish V Badarkhe authored
      Implemented SMCCC_ARCH_SOC_ID call in order to get below
      SOC information:
      
      1. SOC revision
      2. SOC version
      
      Implementation done using below SMCCC specification document:
      https://developer.arm.com/docs/den0028/c
      
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      Change-Id: Ie0595f1c345a6429a6fb4a7f05534a0ca9c9a48b
      0e753437
  4. 16 Mar, 2020 1 commit
  5. 13 Mar, 2020 3 commits
  6. 12 Mar, 2020 14 commits
  7. 11 Mar, 2020 7 commits