Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-23 04:48:14 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs(bl31): aarch64: RESET_TO_BL31_WITH_PARAMS

Browse source 
Document the RESET_TO_BL31 with parameters feature.

Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
Change-Id: I47014d724f2eb822b69a112c3acee546fbfe82d5
This commit is contained in:
Jorge Ramirez-Ortiz 2022-04-15 11:51:03 +02:00
parent 25844ff728
commit ac4ac38c54
No known key found for this signature in database
GPG key ID: 64F6B61756EB755D
2 changed files with 17 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
docs/design/reset-design.rst
View file

@ -141,19 +141,26 @@ CPU executes a modified BL31 initialization, as described below.
Platform initialization Platform initialization
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
In this configuration, when the CPU resets to BL31 there are no parameters that In this configuration, when the CPU resets to BL31 there should be no parameters
can be passed in registers by previous boot stages. Instead, the platform code that can be passed in registers by previous boot stages. Instead, the platform
in BL31 needs to know, or be able to determine, the location of the BL32 (if code in BL31 needs to know, or be able to determine, the location of the BL32
required) and BL33 images and provide this information in response to the (if required) and BL33 images and provide this information in response to the
``bl31_plat_get_next_image_ep_info()`` function. ``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 Additionally, platform software is responsible for carrying out any security
initialisation, for example programming a TrustZone address space controller. initialisation, for example programming a TrustZone address space controller.
This might be done by the Trusted Boot Firmware or by platform code in BL31. This might be done by the Trusted Boot Firmware or by platform code in BL31.
-------------- --------------
*Copyright (c) 2015-2019, Arm Limited and Contributors. All rights reserved.* *Copyright (c) 2015-2022, Arm Limited and Contributors. All rights reserved.*
.. |Default reset code flow| image:: ../resources/diagrams/default_reset_code.png .. |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 .. |Reset code flow with programmable reset address| image:: ../resources/diagrams/reset_code_no_boot_type_check.png

5
docs/getting_started/build-options.rst
View file

@ -709,6 +709,11 @@ Common build options
entrypoint) or 1 (CPU reset to BL31 entrypoint). entrypoint) or 1 (CPU reset to BL31 entrypoint).
The default value is 0. 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 - ``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 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 instead of the BL1 entrypoint. It can take the value 0 (CPU reset to BL1