Docs: Move design documents into a dedicated folder
Collect all the design documents under a dedicated design_docs folder.
Update the links in other documents.
Change-Id: I2da761a11317144185e960c539f2245d3d46fd2a
Signed-off-by: David Hu <david.hu@arm.com>
diff --git a/docs/integration_guide/os_migration_guide_armv8m.rst b/docs/integration_guide/os_migration_guide_armv8m.rst
index 1ca4e3d..a3b5806 100644
--- a/docs/integration_guide/os_migration_guide_armv8m.rst
+++ b/docs/integration_guide/os_migration_guide_armv8m.rst
@@ -24,7 +24,7 @@
then it also have to use the
``enum tfm_status_e tfm_register_client_id (int32_t ns_client_id)``
API function provided by TF-M, as described in
- :doc:`NS client identification documentation </docs/technical_references/tfm_ns_client_identification>`.
+ :doc:`NS client identification documentation </docs/technical_references/design_docs/tfm_ns_client_identification>`.
- if the OS doesn't support the API mentioned above, it should set
``TFM_NS_CLIENT_IDENTIFICATION`` to ``OFF`` in the cmake system.
- .. Note::
diff --git a/docs/integration_guide/services/tfm_ps_integration_guide.rst b/docs/integration_guide/services/tfm_ps_integration_guide.rst
index 2c6da7b..50c83a4 100644
--- a/docs/integration_guide/services/tfm_ps_integration_guide.rst
+++ b/docs/integration_guide/services/tfm_ps_integration_guide.rst
@@ -293,7 +293,7 @@
processing environment. It provides a dedicated API to retrieve the client ID
which performs the service request.
-:doc:`NS client identification documentation </docs/technical_references/tfm_ns_client_identification>`
+:doc:`NS client identification documentation </docs/technical_references/design_docs/tfm_ns_client_identification>`
provides further details on how client identification works.
PS service uses that TF-M core API to retrieve the client ID and associate it
diff --git a/docs/integration_guide/services/tfm_psa_proxy_integration_guide.rst b/docs/integration_guide/services/tfm_psa_proxy_integration_guide.rst
index 9b8ed3d..4fb467f 100644
--- a/docs/integration_guide/services/tfm_psa_proxy_integration_guide.rst
+++ b/docs/integration_guide/services/tfm_psa_proxy_integration_guide.rst
@@ -9,7 +9,7 @@
to a Secure Enclave, this way virtually providing all the PSA RoT services.
Proxy can only be used in IPC model, for context and design details please
check the
-:doc:`Secure Enclave design document </docs/technical_references/secure_enclave_solution>`.
+:doc:`Secure Enclave design document </docs/technical_references/design_docs/secure_enclave_solution>`.
Currently to forward the PSA Client call parameters Proxy must read them with
``psa_read`` into a memory area shared with the Secure Enclave. (Similarily
diff --git a/docs/integration_guide/tfm_integration_guide.rst b/docs/integration_guide/tfm_integration_guide.rst
index a543fd0..f0f2a1e 100644
--- a/docs/integration_guide/tfm_integration_guide.rst
+++ b/docs/integration_guide/tfm_integration_guide.rst
@@ -112,7 +112,7 @@
TF-M provides a reference implementation of NS mailbox on multi-core platforms,
under folder ``interface/src/multi_core``.
-See :doc:`Mailbox design </docs/technical_references/dual-cpu/mailbox_design_on_dual_core_system>`
+See :doc:`Mailbox design </docs/technical_references/design_docs/dual-cpu/mailbox_design_on_dual_core_system>`
for TF-M multi-core mailbox design.
Interface with non-secure world regression tests
@@ -135,7 +135,7 @@
NS client Identification
========================
See
-:doc:`ns client identification documentation </docs/technical_references/tfm_ns_client_identification>`.
+:doc:`ns client identification documentation </docs/technical_references/design_docs/tfm_ns_client_identification>`.
*********************
Non-secure interrupts