From: Sascha Hauer <s.hauer@pengutronix.de>
To: Barebox List <barebox@lists.infradead.org>
Subject: [PATCH] ARM: i.MX: move handoff-data out of OCRAM
Date: Mon, 4 Nov 2024 14:04:23 +0100 [thread overview]
Message-ID: <20241104130423.587874-1-s.hauer@pengutronix.de> (raw)
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@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
next reply other threads:[~2024-11-04 13:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 13:04 Sascha Hauer [this message]
2024-11-08 10:57 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241104130423.587874-1-s.hauer@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox