Introduce PROGRAMMABLE_RESET_ADDRESS build option

This patch introduces a new platform build option, called
PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
a programmable or fixed reset vector address.

If the reset vector address is fixed then the code relies on the
platform_get_entrypoint() mailbox mechanism to figure out where
it is supposed to jump. On the other hand, if it is programmable
then it is assumed that the platform code will program directly
the right address into the RVBAR register (instead of using the
mailbox redirection) so the mailbox is ignored in this case.

Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
This commit is contained in:
Sandrine Bailleux 2015-06-02 17:19:43 +01:00
parent 52010cc779
commit bf031bba2b
5 changed files with 31 additions and 3 deletions

View File

@ -76,6 +76,9 @@ CREATE_KEYS := 1
# Flags to build TF with Trusted Boot support
TRUSTED_BOARD_BOOT := 0
AUTH_MOD := none
# By default, consider that the platform's reset address is not programmable.
# The platform Makefile is free to override this value.
PROGRAMMABLE_RESET_ADDRESS := 0
# Checkpatch ignores
CHECK_IGNORE = --ignore COMPLEX_MACRO \
@ -271,6 +274,10 @@ $(eval $(call assert_boolean,CREATE_KEYS))
$(eval $(call assert_boolean,TRUSTED_BOARD_BOOT))
$(eval $(call add_define,TRUSTED_BOARD_BOOT))
# Process PROGRAMMABLE_RESET_ADDRESS flag
$(eval $(call assert_boolean,PROGRAMMABLE_RESET_ADDRESS))
$(eval $(call add_define,PROGRAMMABLE_RESET_ADDRESS))
ASFLAGS += -nostdinc -ffreestanding -Wa,--fatal-warnings \
-Werror -Wmissing-include-dirs \
-mgeneral-regs-only -D__ASSEMBLY__ \

View File

@ -42,9 +42,15 @@
*/
func bl1_entrypoint
/* ---------------------------------------------------------------------
* If the reset address is programmable then bl1_entrypoint() is
* executed only on the cold boot path. Therefore, we can skip the warm
* boot mailbox mechanism.
* ---------------------------------------------------------------------
*/
el3_entrypoint_common \
_set_endian=1 \
_warm_boot_mailbox=1 \
_warm_boot_mailbox=!PROGRAMMABLE_RESET_ADDRESS \
_secondary_cold_boot=1 \
_init_memory=1 \
_init_c_runtime=1 \

View File

@ -76,9 +76,15 @@ func bl31_entrypoint
mov x0, x20
mov x1, x21
#else
/* ---------------------------------------------------------------------
* For RESET_TO_BL31 systems which have a programmable reset address,
* bl31_entrypoint() is executed only on the cold boot path so we can
* skip the warm boot mailbox mechanism.
* ---------------------------------------------------------------------
*/
el3_entrypoint_common \
_set_endian=1 \
_warm_boot_mailbox=1 \
_warm_boot_mailbox=!PROGRAMMABLE_RESET_ADDRESS \
_secondary_cold_boot=1 \
_init_memory=1 \
_init_c_runtime=1 \

View File

@ -320,6 +320,10 @@ performed.
* `BL33_KEY`: This option is used when `GENERATE_COT=1`. It specifies the
file that contains the BL3-3 private key in PEM format.
* `PROGRAMMABLE_RESET_ADDRESS`: This option indicates whether the reset
vector address can be programmed or is fixed on the platform. It can take
either 0 (fixed) or 1 (programmable). Default is 0.
#### ARM development platform specific build options
* `ARM_TSP_RAM_LOCATION_ID`: location of the TSP binary. Options:

View File

@ -57,6 +57,11 @@ psci_aff_common_finish_entry:
* On the warm boot path, most of the EL3 initialisations performed by
* 'el3_entrypoint_common' must be skipped:
*
* - Only when the platform bypasses the BL1/BL3-1 entrypoint by
* programming the reset address do we need to set the CPU endianness.
* In other cases, we assume this has been taken care by the
* entrypoint code.
*
* - No need to determine the type of boot, we know it is a warm boot.
*
* - Do not try to distinguish between primary and secondary CPUs, this
@ -66,7 +71,7 @@ psci_aff_common_finish_entry:
* it has been done once and for all on the cold boot path.
*/
el3_entrypoint_common \
_set_endian=0 \
_set_endian=PROGRAMMABLE_RESET_ADDRESS \
_warm_boot_mailbox=0 \
_secondary_cold_boot=0 \
_init_memory=0 \