1. 27 Sep, 2019 2 commits
    • Soby Mathew's avatar
      Merge changes from topic "raspberry-pi-4-support" into integration · 17b0bb6c
      Soby Mathew authored
      * changes:
        rpi4: Add initial documentation file
        rpi4: Add stdout-path to device tree
        rpi4: Add GIC maintenance interrupt to GIC DT node
        rpi4: Cleanup memory regions, move pens to first page
        rpi4: Reserve resident BL31 region from non-secure world
        rpi4: Amend DTB to advertise PSCI
        rpi4: Determine BL33 entry point at runtime
        rpi4: Accommodate "armstub8.bin" header at the beginning of BL31 image
        Add basic support for Raspberry Pi 4
        rpi3: Allow runtime determination of UART base clock rate
        FDT helper functions: Respect architecture in PSCI function IDs
        FDT helper functions: Add function documentation
      17b0bb6c
    • Soby Mathew's avatar
      Merge changes from topic "mp/giv3-discovery" into integration · 41bda863
      Soby Mathew authored
      * changes:
        Migrate ARM platforms to use the new GICv3 API
        Adding new optional PSCI hook pwr_domain_on_finish_late
        GICv3: Enable multi socket GIC redistributor frame discovery
      41bda863
  2. 26 Sep, 2019 4 commits
    • Paul Beesley's avatar
      Merge changes I0283fc2e,Ib476d024,Iada05f7c into integration · 69ef7b7f
      Paul Beesley authored
      * changes:
        hikey: fix to load FIP by partition table.
        hikey960: fix to load FIP by partition table
        drivers: partition: support different block size
      69ef7b7f
    • Madhukar Pappireddy's avatar
      Migrate ARM platforms to use the new GICv3 API · 6806cd23
      Madhukar Pappireddy authored
      
      
      This patch invokes the new function gicv3_rdistif_probe() in the
      ARM platform specific gicv3 driver. Since this API modifies the
      shared GIC related data structure, it must be invoked coherently
      by using the platform specific pwr_domain_on_finish_late hook.
      
      Change-Id: I6efb17d5da61545a1c5a6641b8f58472b31e62a8
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      6806cd23
    • Madhukar Pappireddy's avatar
      Adding new optional PSCI hook pwr_domain_on_finish_late · 10107707
      Madhukar Pappireddy authored
      
      
      This PSCI hook is similar to pwr_domain_on_finish but is
      guaranteed to be invoked with the respective core and cluster are
      participating in coherency. This will be necessary to safely invoke
      the new GICv3 API which modifies shared GIC data structures concurrently.
      
      Change-Id: I8e54f05c9d4ef5712184c9c18ba45ac97a29eb7a
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      10107707
    • Madhukar Pappireddy's avatar
      GICv3: Enable multi socket GIC redistributor frame discovery · ec834925
      Madhukar Pappireddy authored
      
      
      This patch provides declaration and definition of new GICv3 driver
      API: gicv3_rdistif_probe().This function delegates the responsibility
      of discovering the corresponding Redistributor base frame to each CPU
      itself. It is a modified version of gicv3_rdistif_base_addrs_probe()
      and is executed by each CPU in the platform unlike the previous
      approach in which only the Primary CPU did the discovery of all the
      Redistributor frames for every CPU.
      
      The flush operations as part of gicv3_driver_init() function are
      made necessary even for platforms with WARMBOOT_ENABLE_DCACHE_EARLY
      because the GICv3 driver data structure contents are accessed by CPU
      with D-Cache turned off during power down operations.
      
      Change-Id: I1833e81d3974b32a3e4a3df4766a33d070982268
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      ec834925
  3. 25 Sep, 2019 15 commits
    • Paul Beesley's avatar
    • Paul Beesley's avatar
    • Andre Przywara's avatar
      rpi4: Add initial documentation file · e0dea671
      Andre Przywara authored
      
      
      As the Raspberry Pi4 port is now in a usable state, add the build
      instructions together with some background information to the
      documentation directory.
      The port differs quite a bit from the Raspberry Pi 3, so we use a
      separate file for that.
      
      Change-Id: I7d9f5967fdf3ec3bfe97d78141f59cbcf03388d4
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      e0dea671
    • Andre Przywara's avatar
      rpi4: Add stdout-path to device tree · 1a7422eb
      Andre Przywara authored
      
      
      Some device tree users like to find a pointer to the standard serial
      console in the device tree, in the "stdout-path" property of the /chosen
      node.
      
      Add the location of the Mini UART in that property, so that DT users are
      happy, for instance Linux' earlycon detection.
      
      Change-Id: I178e55016e5640de5ab0bc6e061944bd3583ea96
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      1a7422eb
    • Andre Przywara's avatar
      rpi4: Add GIC maintenance interrupt to GIC DT node · 3903a8cd
      Andre Przywara authored
      
      
      For being able to use the virtualisation support the GIC offers, we need
      to know the interrupt number of the maintenance interrupt. This
      information is missing from the official RPi4 device tree.
      
      Use libfdt to add the "interrupts" property to the GIC node, which
      allows hypervisors like KVM or Xen to be able to use the GIC's help on
      virtualising interrupts.
      
      Change-Id: Iab84f0885a5bf29fb84ca8f385e8a39d27700c75
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      3903a8cd
    • Andre Przywara's avatar
      rpi4: Cleanup memory regions, move pens to first page · 882c0ff6
      Andre Przywara authored
      
      
      Now that we have the SMP pens in the first page of DRAM, we can get rid
      of all the fancy RPi3 memory regions that our RPi4 port does not really
      need. This avoids using up memory all over the place, restricting ATF
      to just run in the first 512KB of DRAM.
      
      Remove the now unused regions. This also moves the SMP pens into our
      first memory page (holding the firmware magic), where the original
      firmware put them, but where there is also enough space for them.
      
      Since the pens will require code execution privileges, we amend the
      memory attributes used for that page to include write and execution
      rights.
      
      Change-Id: I131633abeb4a4d7b9057e737b9b0d163b73e47c6
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      882c0ff6
    • Andre Przywara's avatar
      rpi4: Reserve resident BL31 region from non-secure world · 2b19e2f3
      Andre Przywara authored
      
      
      The GPU firmware loads the armstub8.bin (BL31) image at address 0, the
      beginning of DRAM. As this holds the resident PSCI code and the SMP
      pens, the non-secure world should better know about this, to avoid
      accessing memory owned by TF-A. This is particularly criticial as the
      Raspberry Pi 4 does not feature a secure memory controller, so
      overwriting code is a very real danger.
      
      Use the newly introduced function to add a node into reserved-memory
      node, where non-secure world can check for regions to be excluded from
      its mappings.
      
      Reserve the first 512KB of memory for now. We can refine this later if
      need be.
      
      Change-Id: I00e55e70c5c02615320d79ff35bc32b805d30770
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      2b19e2f3
    • Andre Przywara's avatar
      rpi4: Amend DTB to advertise PSCI · f67fa69c
      Andre Przywara authored
      
      
      The device tree provided by the official Raspberry Pi firmware uses
      spin tables for SMP bringup.
      
      One of the benefit of having TF-A is that it provides PSCI services, so
      let's rewrite the DTB to advertise PSCI instead of spin tables.
      This uses the (newly exported) routine from the QEMU platform port.
      
      Change-Id: Ifddcb14041ca253a333f8c2d5e97a42db152470c
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      f67fa69c
    • Andre Przywara's avatar
      rpi4: Determine BL33 entry point at runtime · 448fb352
      Andre Przywara authored
      
      
      Now that we have the armstub magic value in place, the GPU firmware will
      write the kernel load address (and DTB address) into our special page,
      so we can always easily access the actual location without hardcoding
      any addresses into the BL31 image.
      
      Make the compile-time defined PRELOADED_BL33_BASE macro optional, and
      read the BL33 entry point from the magic location, if the macro was not
      defined. We do the same for the DTB address.
      
      This also splits the currently "common" definition of
      plat_get_ns_image_entrypoint() to be separate between RPi3 and RPi4.
      
      Change-Id: I6f26c0adc6fce2df47786b271c490928b4529abb
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      448fb352
    • Andre Przywara's avatar
      rpi4: Accommodate "armstub8.bin" header at the beginning of BL31 image · c4597e13
      Andre Przywara authored
      
      
      The Raspberry Pi GPU firmware checks for a magic value at offset 240
      (0xf0) of the armstub8.bin image it loads. If that value matches,
      it writes the kernel load address and the DTB address into subsequent
      memory locations.
      We can use these addresses to avoid hardcoding these values into the BL31
      image, to make it more flexible and a drop-in replacement for the
      official armstub8.bin.
      
      Reserving just 16 bytes at offset 240 of the final image file is not easily
      possible, though, as this location is in the middle of the generic BL31
      entry point code.
      However we can prepend an extra section before the actual BL31 image, to
      contain the magic and addresses. This needs to be 4KB, because the
      actual BL31 entry point needs to be page aligned.
      
      Use the platform linker script hook that the generic code provides, to
      add an almost empty 4KB code block before the entry point code. The very
      first word contains a branch instruction to jump over this page, into
      the actual entry code.
      This also gives us plenty of room for the SMP pens later.
      
      Change-Id: I38caa5e7195fa39cbef8600933a03d86f09263d6
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      c4597e13
    • 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
    • Andre Przywara's avatar
      rpi3: Allow runtime determination of UART base clock rate · 7c0a1877
      Andre Przywara authored
      
      
      At the moment the UART input clock rate is hard coded at compile time.
      This works as long as the GPU firmware always sets up the same rate,
      which does not seem to be true for the Raspberry Pi 4.
      
      In preparation for being able to change this at runtime, add a base
      clock parameter to the console setup function. This is still hardcoded
      for the Raspberry Pi 3.
      
      Change-Id: I398bc2f1e9b46f7af9a84cb0b33cbe8e78f2d900
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      7c0a1877
    • Andre Przywara's avatar
      FDT helper functions: Respect architecture in PSCI function IDs · 66799507
      Andre Przywara authored
      
      
      PSCI uses different function IDs for CPU_SUSPEND and CPU_ON, depending on
      the architecture used (AArch64 or AArch32).
      For recent PSCI versions the client will determine the right version,
      but for PSCI v0.1 we need to put some ID in the DT node. At the moment
      we always add the 64-bit IDs, which is not correct if TF-A is built for
      AArch32.
      
      Use the function IDs matching the TF-A build architecture, for the two
      IDs where this differs. This only affects legacy OSes using PSCI v0.1.
      
      On the way remove the sys_poweroff and sys_reset properties, which were
      never described in the official PSCI DT binding.
      
      Change-Id: If77bc6daec215faeb2dc67112e765aacafd17f33
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      66799507
    • Andre Przywara's avatar
      FDT helper functions: Add function documentation · 6eaf928d
      Andre Przywara authored
      
      
      Since we moved some functions that amend a DT blob in memory to common
      code, let's add proper function documentation.
      This covers the three exported functions in common/fdt_fixup.c.
      
      Change-Id: I67d7d27344e62172c789d308662f78d54903cf57
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      6eaf928d
    • Sandrine Bailleux's avatar
      FVP: Fix plat_set_nv_ctr() function · bd363d35
      Sandrine Bailleux authored
      The Fast Models provide a non-volatile counter component, which is used
      in the Trusted Board Boot implementation to protect against rollback
      attacks.
      
      This component comes in 2 versions (see [1]).
      
      - Version 0 is the default and models a locked non-volatile counter,
        whose value is fixed.
      
      - Version 1 of the counter may be incremented in a monotonic fashion.
      
      plat_set_nv_ctr() must cope with both versions. This is achieved by:
      1) Attempting to write the new value in the counter.
      2) Reading the value back.
      3) If there is a mismatch, we know the counter upgrade failed.
      
      When using version 0 of the counter, no upgrade is possible so the
      function is expected to fail all the time. However, the code is
      missing a compiler barrier between the write operation and the next
      read. Thus, the compiler may optimize and remove the read operation on
      the basis that the counter value has not changed. With the default
      optimization level used in TF-A (-Os), this is what's happening.
      
      The fix introduced in this patch marks the write and subsequent read
      accesses to the counter as volatile, such that the compiler makes no
      assumption about the value of the counter.
      
      Note that the comment above plat_set_nv_ctr() was clearly stating
      that when using the read-only version of the non-volatile counter,
      "we expect the values in the certificates to always match the RO
      values so that this function is never called". However, the fact that
      the counter value was read back seems to contradict this comment, as
      it is implementing a counter-measure against misuse of the
      function. The comment has been reworded to avoid any confusion.
      
      Without this patch, this bug may be demonstrated on the Base AEM FVP:
      - Using version 0 of the non-volatile counter (default version).
      - With certificates embedding a revision number value of 32
        (compiling TF-A with TFW_NVCTR_VAL=32).
      
      In this configuration, the non-volatile counter is tied to value 31 by
      default. When BL1 loads the Trusted Boot Firmware certificate, it
      notices that the two values do not match and tries to upgrade the
      non-volatile counter. This write operation is expected to fail
      (because the counter is locked) and the function is expected to return
      an error but it succeeds instead.
      
      As a result, the trusted boot does not abort as soon as it should and
      incorrectly boots BL2. The boot is finally aborted when BL2 verifies
      the BL31 image and figures out that the version of the SoC Firmware
      Key Certificate does not match. On Arm platforms, only certificates
      signed with the Root-of-Trust Key may trigger an upgrade of the
      non-volatile Trusted counter.
      
      [1] https://developer.arm.com/docs/100964/1160/fast-models-components/peripheral-components/nonvolatilecounter
      
      
      
      Change-Id: I9979f29c23b47b338b9b484013d1fb86c59db92f
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      bd363d35
  4. 23 Sep, 2019 1 commit
  5. 20 Sep, 2019 3 commits
    • Paul Beesley's avatar
      doc: Render Marvell platform documents · 2966defa
      Paul Beesley authored
      
      
      The documentation for Marvell platforms was not included in the
      rendered document output until now because, while it was mostly
      valid RST format, the files were saved with a .txt extension.
      
      This patch corrects some RST formatting errors, creates a document
      tree (index page) for the Marvell documents, and adds the Marvell
      subtree to the main index.
      
      Change-Id: Id7d4ac37eded636f8f62322a153e1e5f652ff51a
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      2966defa
    • Kever Yang's avatar
      rockchip: Update BL31_BASE to 0x40000 · 0aad563c
      Kever Yang authored
      
      
      Rockchip platform is using the first 1MB of DRAM as secure ram space,
      and there is a vendor loader who loads and runs the BL31/BL32/BL33,
      this loader is usually load by SoC BootRom to the start addres of DRAM,
      we need to reserve enough space for this loader so that it doesn't need
      to do the relocate when loading the BL31. eg.
      We use U-Boot SPL to load ATF BL31 and U-Boot proper as BL33, the SPL
      TEXT BASE is offset 0 of DRAM which is decide by Bootrom; if we update
      the BL31_BASE to offset 0x40000(256KB), then the 0~0x40000 should be
      enough for SPL and no need to do the relocate while the space size
      0x10000(64KB) may not enough for SPL.
      After this update, the BL31 can use the rest 768KB of the first 1MB,
      which is also enough, and the loader who is using BL31 elf file can
      support this update without any change.
      
      Change-Id: I66dc685594d77f10f9a49c3be015fd6729250ece
      Signed-off-by: default avatarKever Yang <kever.yang@rock-chips.com>
      0aad563c
    • Kever Yang's avatar
      rockchip: Fix typo for TF content text · 382ddb3d
      Kever Yang authored
      
      
      The 'txet' should be 'text'.
      
      Change-Id: I2217a1adf50c3b86f3087b83c77d9291b280627c
      Signed-off-by: default avatarKever Yang <kever.yang@rock-chips.com>
      382ddb3d
  6. 18 Sep, 2019 9 commits
  7. 17 Sep, 2019 1 commit
  8. 16 Sep, 2019 5 commits