1. 30 Dec, 2019 1 commit
    • Andre Przywara's avatar
      plat: rpi4: Skip UART initialisation · 0eda713b
      Andre Przywara authored
      
      
      So far we have seen two different clock setups for the Raspberry Pi 4
      board, with the VPU clock divider being different. This was handled by
      reading the divider register and adjusting the base clock rate
      accordingly.
      Recently a new GPU firmware version appeared that changed the clock rate
      *again*, though this time at a higher level, so the VPU rate (and the
      apparent PLLC parent clock) did not seem to change, judging by reading
      the clock registers.
      So rather than playing cat and mouse with the GPU firmware or going
      further down the rabbit hole of exploring the whole clock tree, let's
      just skip the baud rate programming altogether. This works because the
      GPU firmware actually sets up and programs the debug UART already, so
      we can just use it.
      
      Pass 0 as the base clock rate to let the console driver skip the setup,
      also remove the no longer needed clock code.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Change-Id: Ica88a3f3c9c11059357c1e6dd8f7a4d9b1f98fd7
      0eda713b
  2. 25 Sep, 2019 1 commit
    • Andre Przywara's avatar
      Add basic support for Raspberry Pi 4 · f5cb15b0
      Andre Przywara authored
      
      
      The Raspberry Pi 4 is a single board computer with four Cortex-A72
      cores. From a TF-A perspective it is quite similar to the Raspberry Pi
      3, although it comes with more memory (up to 4GB) and has a GIC.
      
      This initial port though differs quite a lot from the existing rpi3
      platform port, mainly due to taking a much simpler and more robust
      approach to loading the non-secure payload:
      The GPU firmware of the SoC, which is responsible for initial platform
      setup (including DRAM initialisation), already loads the kernel, device
      tree and the "armstub" into DRAM. We take advantage of this, by placing
      just a BL31 component into the armstub8.bin component, which will be
      executed first, in AArch64 EL3.
      The non-secure payload can be a kernel or a boot loader (U-Boot or
      EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.
      
      So this is just a BL31-only port, which directly drops into EL2
      and executes whatever has been loaded as the "kernel" image, handing
      over the DTB address in x0.
      
      Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      f5cb15b0
  3. 13 Sep, 2019 1 commit