arm-trusted-firmware

13073 Commits

5 Branches

114 Tags

55 MiB

Tree: 231305ec0f

Commit Graph

Author	SHA1	Message	Date
Paul Beesley	a2c320a83e	doc: Reorganise images and update links Change-Id: I679d1499376a524bef1cfc33df995b0a719b5ac8 Signed-off-by: Paul Beesley <paul.beesley@arm.com>	6 years ago
Antonio Nino Diaz	4e85e4fd11	Initialize secondary CPUs during cold boot 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	9 years ago
Sandrine Bailleux	c2f0260c12	Introduce the ARM TF reset design document 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	9 years ago

Author

SHA1

Message

Date

Paul Beesley

a2c320a83e

doc: Reorganise images and update links

Change-Id: I679d1499376a524bef1cfc33df995b0a719b5ac8
Signed-off-by: Paul Beesley <paul.beesley@arm.com>

6 years ago

Antonio Nino Diaz

4e85e4fd11

Initialize secondary CPUs during cold boot

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

9 years ago

Sandrine Bailleux

c2f0260c12

Introduce the ARM TF reset design document

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

9 years ago

1 Commits (231305ec0fd0bcf9b0439fcd442de037b3b94565)