1. 22 May, 2019 1 commit
  2. 07 Mar, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Initialize secondary CPUs during cold boot · 4e85e4fd
      Antonio Nino Diaz authored
      The previous reset code in BL1 performed the following steps in
      order:
      
      1. Warm/Cold boot detection.
         If it's a warm boot, jump to warm boot entrypoint.
      
      2. Primary/Secondary CPU detection.
         If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(),
         which doesn't return.
      
      3. CPU initialisations (cache, TLB...).
      
      4. Memory and C runtime initialization.
      
      For a secondary CPU, steps 3 and 4 are never reached. This shouldn't
      be a problem in most cases, since current implementations of
      plat_secondary_cold_boot_setup() either panic or power down the
      secondary CPUs.
      
      The main concern is the lack of secondary CPU initialization when
      bare metal EL3 payloads are used in case they don't take care of this
      initialisation themselves.
      
      This patch moves the detection of primary/secondary CPU after step 3
      so that the CPU initialisations are performed per-CPU, while the
      memory and the C runtime initialisation are only performed on the
      primary CPU. The diagrams used in the ARM Trusted Firmware Reset
      Design documentation file have been updated to reflect the new boot
      flow.
      
      Platforms ports might be affected by this patch depending on the
      behaviour of plat_secondary_cold_boot_setup(), as the state of the
      platform when entering this function will be different.
      
      Fixes ARM-software/tf-issues#342
      
      Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
      4e85e4fd
  3. 15 Dec, 2015 1 commit
    • Sandrine Bailleux's avatar
      Introduce the ARM TF reset design document · c2f0260c
      Sandrine Bailleux authored
      This patch introduces a new document presenting the ARM Trusted
      Firmware Reset Design. It shows the reset code flow, lists the
      different build options that affect it, in which case to use them
      and what their exact effect is.
      
      The section about using BL31 entrypoint as the reset address has
      been moved from the general firmware design document to this one.
      It's also been improved to explain why the FVP port supports the
      RESET_TO_BL31 configuration, even though the reset vector address
      can't be programmed dynamically.
      
      This document includes some images, which have been generated using
      Dia version 0.97.2. This tool can be obtained from:
      https://wiki.gnome.org/Apps/Dia/Download
      This patch provides:
       - the image files describing the different reset flow diagrams;
       - the source '.dia' file;
       - a script automating the generation of the images from the '.dia'
         file.
      Note that the 2 latter files are not actually needed for the document
      and are provided for convenience only, in case the reset images need
      to be modified.
      
      Change-Id: Ib6302e8209d418a5b31c4e85e55fd9e83caf2ca2
      c2f0260c