[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