From 5025546c08c51257f49d5fec7e291c03324ee165 Mon Sep 17 00:00:00 2001 From: Manish V Badarkhe Date: Tue, 21 Feb 2023 12:30:13 +0000 Subject: [PATCH] Revert "docs(bl31): aarch64: RESET_TO_BL31_WITH_PARAMS" Adopted RESET_TO_BL31_WITH_PARAMS functionality in RESET_TO_BL31 in the subsequent patches hence reverted this patch. This reverts commit ac4ac38c5443afdef38e38e9247c96359de3a2ea. Change-Id: I5fb8eaea47d0fd6d0171260c6d834ec8de588fad Signed-off-by: Manish V Badarkhe --- docs/design/reset-design.rst | 17 +++++------------ docs/getting_started/build-options.rst | 5 ----- 2 files changed, 5 insertions(+), 17 deletions(-) diff --git a/docs/design/reset-design.rst b/docs/design/reset-design.rst index 666ee4f0d..7b10c956c 100644 --- a/docs/design/reset-design.rst +++ b/docs/design/reset-design.rst @@ -141,26 +141,19 @@ CPU executes a modified BL31 initialization, as described below. Platform initialization ~~~~~~~~~~~~~~~~~~~~~~~ -In this configuration, when the CPU resets to BL31 there should be no parameters -that can be passed in registers by previous boot stages. Instead, the platform -code in BL31 needs to know, or be able to determine, the location of the BL32 -(if required) and BL33 images and provide this information in response to the +In this configuration, when the CPU resets to BL31 there are no parameters that +can be passed in registers by previous boot stages. Instead, the platform code +in BL31 needs to know, or be able to determine, the location of the BL32 (if +required) and BL33 images and provide this information in response to the ``bl31_plat_get_next_image_ep_info()`` function. -.. note:: - Some platforms that configure ``RESET_TO_BL31`` might still be able to - receive parameters in registers depending on their actual boot sequence. On - those occasions, and in addition to ``RESET_TO_BL31``, these platforms should - set ``RESET_TO_BL31_WITH_PARAMS`` to avoid the input registers from being - zeroed before entering BL31. - Additionally, platform software is responsible for carrying out any security initialisation, for example programming a TrustZone address space controller. This might be done by the Trusted Boot Firmware or by platform code in BL31. -------------- -*Copyright (c) 2015-2022, Arm Limited and Contributors. All rights reserved.* +*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.* .. |Default reset code flow| image:: ../resources/diagrams/default_reset_code.png .. |Reset code flow with programmable reset address| image:: ../resources/diagrams/reset_code_no_boot_type_check.png diff --git a/docs/getting_started/build-options.rst b/docs/getting_started/build-options.rst index a285d31c3..490b0b356 100644 --- a/docs/getting_started/build-options.rst +++ b/docs/getting_started/build-options.rst @@ -742,11 +742,6 @@ Common build options entrypoint) or 1 (CPU reset to BL31 entrypoint). The default value is 0. -- ``RESET_TO_BL31_WITH_PARAMS``: If ``RESET_TO_BL31`` has been enabled, setting - this additional option guarantees that the input registers are not cleared - therefore allowing parameters to be passed to the BL31 entrypoint. - The default value is 0. - - ``RESET_TO_SP_MIN``: SP_MIN is the minimal AArch32 Secure Payload provided in TF-A. This flag configures SP_MIN entrypoint as the CPU reset vector instead of the BL1 entrypoint. It can take the value 0 (CPU reset to BL1 -- 2.39.5