aboutsummaryrefslogtreecommitdiff
path: root/bl2
diff options
context:
space:
mode:
authorSandrine Bailleux <sandrine.bailleux@arm.com>2015-11-26 16:31:34 +0000
committerAchin Gupta <achin.gupta@arm.com>2015-11-26 21:32:04 +0000
commit4c117f6c49330682cabdbf6d082e7c02dd32e84b (patch)
treeb7cc8fc019dda1562d0712a0e413e7518da69070 /bl2
parent862b5dc2d1f45b0195678dcb6556b0721444505f (diff)
downloadtrusted-firmware-a-4c117f6c49330682cabdbf6d082e7c02dd32e84b.tar.gz
CSS: Enable booting of EL3 payloads
This patch adds support for booting EL3 payloads on CSS platforms, for example Juno. In this scenario, the Trusted Firmware follows its normal boot flow up to the point where it would normally pass control to the BL31 image. At this point, it jumps to the EL3 payload entry point address instead. Before handing over to the EL3 payload, the data SCP writes for AP at the beginning of the Trusted SRAM is restored, i.e. we zero the first 128 bytes and restore the SCP Boot configuration. The latter is saved before transferring the BL30 image to SCP and is restored just after the transfer (in BL2). The goal is to make it appear that the EL3 payload is the first piece of software to run on the target. The BL31 entrypoint info structure is updated to make the primary CPU jump to the EL3 payload instead of the BL31 image. The mailbox is populated with the EL3 payload entrypoint address, which releases the secondary CPUs out of their holding pen (if the SCP has powered them on). The arm_program_trusted_mailbox() function has been exported for this purpose. The TZC-400 configuration in BL2 is simplified: it grants secure access only to the whole DRAM. Other security initialization is unchanged. This alternative boot flow is disabled by default. A new build option EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3 payload's entry point address. The build system has been modified such that BL31 and BL33 are not compiled and/or not put in the FIP in this case, as those images are not used in this boot flow. Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
Diffstat (limited to 'bl2')
-rw-r--r--bl2/bl2_main.c19
1 files changed, 19 insertions, 0 deletions
diff --git a/bl2/bl2_main.c b/bl2/bl2_main.c
index f8a2372fe5..a3f016f9c3 100644
--- a/bl2/bl2_main.c
+++ b/bl2/bl2_main.c
@@ -83,6 +83,7 @@ static int load_bl30(void)
return e;
}
+#ifndef EL3_PAYLOAD_BASE
/*******************************************************************************
* Load the BL3-1 image.
* The bl2_to_bl31_params and bl31_ep_info params will be updated with the
@@ -190,6 +191,7 @@ static int load_bl33(bl31_params_t *bl2_to_bl31_params)
return e;
}
+#endif /* EL3_PAYLOAD_BASE */
/*******************************************************************************
* The only thing to do in BL2 is to load further images and pass control to
@@ -232,6 +234,22 @@ void bl2_main(void)
bl2_to_bl31_params = bl2_plat_get_bl31_params();
bl31_ep_info = bl2_plat_get_bl31_ep_info();
+#ifdef EL3_PAYLOAD_BASE
+ /*
+ * In the case of an EL3 payload, we don't need to load any further
+ * images. Just update the BL31 entrypoint info structure to make BL1
+ * jump to the EL3 payload.
+ * The pointer to the memory the platform has set aside to pass
+ * information to BL3-1 in the normal boot flow is reused here, even
+ * though only a fraction of the information contained in the
+ * bl31_params_t structure makes sense in the context of EL3 payloads.
+ * This will be refined in the future.
+ */
+ VERBOSE("BL2: Populating the entrypoint info for the EL3 payload\n");
+ bl31_ep_info->pc = EL3_PAYLOAD_BASE;
+ bl31_ep_info->args.arg0 = (unsigned long) bl2_to_bl31_params;
+ bl2_plat_set_bl31_ep_info(NULL, bl31_ep_info);
+#else
e = load_bl31(bl2_to_bl31_params, bl31_ep_info);
if (e) {
ERROR("Failed to load BL3-1 (%i)\n", e);
@@ -253,6 +271,7 @@ void bl2_main(void)
ERROR("Failed to load BL3-3 (%i)\n", e);
plat_error_handler(e);
}
+#endif /* EL3_PAYLOAD_BASE */
/* Flush the params to be passed to memory */
bl2_plat_flush_bl31_params();