[PATCH] ARM: i.MX: move handoff-data out of OCRAM
Sascha Hauer
s.hauer at pengutronix.de
Mon Nov 4 05:04:23 PST 2024
During 1st stage boot barebox is running in OCRAM. This OCRAM is
occupied by the TF-A once started, so move the handoff-data to SDRAM
before starting the TF-A.
Currently no board is using handoff-data from its early board code, so
this is not yet necessary, but done now so that board code is able to
use handoff-data in the future.
For i.MX93 let's move the copying of the PBL to SDRAM after setting up
OP-TEE. The OP-TEE code might use handoff-data later as well. When this
happens we must make sure that the handoff-data is complete before
moving it to SDRAM.
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
---
arch/arm/mach-imx/atf.c | 36 ++++++++++++++++++++----------------
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-imx/atf.c b/arch/arm/mach-imx/atf.c
index f4ba07bf06..a14a68f4fa 100644
--- a/arch/arm/mach-imx/atf.c
+++ b/arch/arm/mach-imx/atf.c
@@ -108,6 +108,8 @@ void imx8mm_load_bl33(void *bl33)
hang();
}
+ handoff_data_move(bl33 - ALIGN(handoff_data_size(), 0x1000));
+
/*
* On completion the TF-A will jump to MX8M_ATF_BL33_BASE_ADDR
* in EL2. Copy the image there, but replace the PBL part of
@@ -397,22 +399,6 @@ void __noreturn imx93_load_and_start_image_via_tfa(void)
imx93_romapi_load_image(bl33);
- /*
- * On completion the TF-A will jump to MX93_ATF_BL33_BASE_ADDR
- * in EL2. Copy the image there, but replace the PBL part of
- * that image with ourselves. On a high assurance boot only the
- * currently running code is validated and contains the checksum
- * for the piggy data, so we need to ensure that we are running
- * the same code in DRAM.
- *
- * The second purpose of this memcpy is for USB booting. When booting
- * from USB the image comes in as a stream, so the PBL is transferred
- * only once. As we jump into the PBL again in SDRAM we need to copy
- * it there. The USB protocol transfers data in chunks of 1024 bytes,
- * so align the copy size up to the next 1KiB boundary.
- */
- memcpy((void *)MX93_ATF_BL33_BASE_ADDR, __image_start, ALIGN(barebox_pbl_size, 1024));
-
if (IS_ENABLED(CONFIG_FIRMWARE_IMX93_OPTEE)) {
void *bl32 = (void *)arm_mem_optee(endmem);
size_t bl32_size;
@@ -433,6 +419,24 @@ void __noreturn imx93_load_and_start_image_via_tfa(void)
get_builtin_firmware(imx93_bl31_bin, &tfa, &tfa_size);
}
+ handoff_data_move(bl33 - ALIGN(handoff_data_size(), 0x1000));
+
+ /*
+ * On completion the TF-A will jump to MX93_ATF_BL33_BASE_ADDR
+ * in EL2. Copy the image there, but replace the PBL part of
+ * that image with ourselves. On a high assurance boot only the
+ * currently running code is validated and contains the checksum
+ * for the piggy data, so we need to ensure that we are running
+ * the same code in DRAM.
+ *
+ * The second purpose of this memcpy is for USB booting. When booting
+ * from USB the image comes in as a stream, so the PBL is transferred
+ * only once. As we jump into the PBL again in SDRAM we need to copy
+ * it there. The USB protocol transfers data in chunks of 1024 bytes,
+ * so align the copy size up to the next 1KiB boundary.
+ */
+ memcpy((void *)MX93_ATF_BL33_BASE_ADDR, __image_start, ALIGN(barebox_pbl_size, 1024));
+
memcpy(bl31, tfa, tfa_size);
asm volatile("msr sp_el2, %0" : :
--
2.39.5
More information about the barebox
mailing list