refactor(spmd): boot interface and pass core id

This change refactors the SPMD to setup SPMC CPU contexts once and early
from spmd_spmc_init (single call to cm_setup_context rather than on each
and every warm boot).
Pass the core linear ID through a GP register as an implementation
defined behavior helping FF-A adoption to legacy TOSes (essentially
when secure virtualization is not used).

A first version of this change was originally submitted by Lukas [1].
Pasting below the original justification:

Our TEE, Kinibi, is used to receive the core linear ID in the x3
register of booting secondary cores.
This patch is necessary to bring up secondary cores with Kinibi as an
SPMC in SEL1.

In Kinibi, the TEE is mostly platform-independent and all platform-
specifics like topology is concentrated in TF-A of our customers.
That is why we don't have the MPIDR - linear ID mapping in Kinibi.
We need the correct linear ID to program the GICv2 target register,
for example in power management case.
It is not needed on GICv3/v4, because of using a fixed mapping from
MPIDR to ICDIPTR/GICD_ITARGETSRn register.

For debug and power management purpose, we also want a unified view to
linear id between Linux and the TEE.
E.g. to disable a core, to see what cores are printing a trace /
an event.

In the past, Kinibi had several other designs, but the complexity was
getting out of control:
* Platform-specific assembler macros in the kernel.
* A per-core SMC from Linux to tell the linear ID after the boot.
* With DynamiQ, it seems SIPs were playing with MPIDR register values,
  reusing them between cores and changing them during boot.

[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10235

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Signed-off-by: Lukas Hanel <lukas.hanel@trustonic.com>
Change-Id: Ifa8fa208e9b8eb1642c80b5f7b54152dadafa75e
diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst
index a5e7e8e..0b80083 100644
--- a/docs/components/secure-partition-manager.rst
+++ b/docs/components/secure-partition-manager.rst
@@ -414,13 +414,17 @@
 
 The SPMC is loaded by BL2 as the BL32 image.
 
-The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image.
+The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image `[9]`_.
 
 BL2 passes the SPMC manifest address to BL31 through a register.
 
 At boot time, the SPMD in BL31 runs from the primary core, initializes the core
-contexts and launches the SPMC (BL32) passing the SPMC manifest address through
-a register.
+contexts and launches the SPMC (BL32) passing the following information through
+registers:
+
+- X0 holds the ``TOS_FW_CONFIG`` physical address (or SPMC manifest blob).
+- X1 holds the ``HW_CONFIG`` physical address.
+- X4 holds the currently running core linear id.
 
 Loading of SPs
 ~~~~~~~~~~~~~~
@@ -951,6 +955,10 @@
 
 [8] https://lists.trustedfirmware.org/pipermail/tf-a/2020-February/000296.html
 
+.. _[9]:
+
+[9] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#dynamic-configuration-during-cold-boot
+
 --------------
 
 *Copyright (c) 2020-2021, Arm Limited and Contributors. All rights reserved.*