From: Sohaib Mohamed <sohaib.amhmd@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>,
BAREBOX <barebox@lists.infradead.org>
Cc: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Subject: [PATCH 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler
Date: Fri, 28 Nov 2025 01:51:18 +0100 [thread overview]
Message-ID: <20251128-avenger96-v1-2-009b13bd8df7@gmail.com> (raw)
In-Reply-To: <20251128-avenger96-v1-0-009b13bd8df7@gmail.com>
Add support for updating STM32MP1 bootloader in NOR flash. The handler
automatically detects FIP location (256K or 512K offset) and flashes
FSBL at offset 0 and FIP at offset 512K. FIP is truncated if it exceeds
available space.
The handler detects the FIP location within the image (at either 256K
or 512K offset) and flashes components to their appropriate locations:
- FSBL at offset 0 (first 256K)
- FIP at offset 512K (remainder of flash)
When flashing from eMMC boot partitions to NOR, the FIP is truncated if
needed since eMMC boot partitions are typically larger than available
NOR flash space.
Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>
---
arch/arm/mach-stm32mp/bbu.c | 77 +++++++++++++++++++++++++++++++++++++++++++++
include/mach/stm32mp/bbu.h | 10 ++++++
2 files changed, 87 insertions(+)
diff --git a/arch/arm/mach-stm32mp/bbu.c b/arch/arm/mach-stm32mp/bbu.c
index 07b5111341..e8d0138cc7 100644
--- a/arch/arm/mach-stm32mp/bbu.c
+++ b/arch/arm/mach-stm32mp/bbu.c
@@ -193,3 +193,80 @@ int stm32mp_bbu_mmc_fip_register(const char *name,
return ret;
}
+
+static int stm32mp_bbu_nor_fip_handler(struct bbu_handler *handler,
+ struct bbu_data *data)
+{
+ struct bbu_data *fsbl_data, *fip_data;
+ enum filetype filetype;
+ int ret;
+
+ filetype = file_detect_type(data->image, data->len);
+ if (filetype == filetype_fip) {
+ pr_debug("Flashing FIP at offset 512K\n");
+ return bbu_flash(data, SZ_512K);
+ }
+
+ if (filetype != filetype_stm32_image_fsbl_v1) {
+ if (!bbu_force(data, "incorrect image type. Expected: %s, got %s",
+ file_type_to_string(filetype_stm32_image_fsbl_v1),
+ file_type_to_string(filetype)))
+ return -EINVAL;
+
+ /* Force: Let's assume it's an FSBL and flash anyway */
+ }
+
+ if (data->len > SZ_256K)
+ filetype = file_detect_type(data->image + SZ_256K,
+ data->len - SZ_256K);
+ else
+ filetype = filetype_unknown;
+
+ /* Not an eMMC image, just flash 1:1 */
+ if (filetype != filetype_fip) {
+ pr_debug("Flashing FSBL at offset 0\n");
+ return bbu_flash(data, 0);
+ }
+
+ /* On SPI-NOR, offset 256K is FSBL2. If we get a FIP image there
+ * instead, let's assume that's an eMMC boot partition image
+ * and flash the FSBL to offset 0 and the remainder to offset 512K
+ */
+
+ pr_debug("Flashing FSBL at offset 0\n");
+ fsbl_data = data;
+ fsbl_data->image = data->image;
+ fsbl_data->len = SZ_256K;
+
+ ret = bbu_flash(fsbl_data, 0);
+ if (ret < 0)
+ return ret;
+
+ pr_debug("Flashing FIP from file offset 256K at offset 512K\n");
+ fip_data = data;
+ fip_data->image = data->image + SZ_256K;
+ fip_data->len = data->len - SZ_256K;
+
+ return bbu_flash(fip_data, SZ_512K);
+}
+
+int stm32mp_bbu_nor_fip_register(const char *name,
+ const char *devicefile,
+ unsigned long flags)
+{
+ struct stm32mp_bbu_handler *priv;
+ int ret;
+
+ priv = xzalloc(sizeof(*priv));
+
+ priv->handler.flags = flags;
+ priv->handler.devicefile = devicefile;
+ priv->handler.name = name;
+ priv->handler.handler = stm32mp_bbu_nor_fip_handler;
+
+ ret = bbu_register_handler(&priv->handler);
+ if (ret)
+ free(priv);
+
+ return ret;
+}
diff --git a/include/mach/stm32mp/bbu.h b/include/mach/stm32mp/bbu.h
index 233bcf6478..87b29f1527 100644
--- a/include/mach/stm32mp/bbu.h
+++ b/include/mach/stm32mp/bbu.h
@@ -10,6 +10,9 @@
int stm32mp_bbu_mmc_fip_register(const char *name, const char *devicefile,
unsigned long flags);
+int stm32mp_bbu_nor_fip_register(const char *name, const char *devicefile,
+ unsigned long flags);
+
#else
static inline int stm32mp_bbu_mmc_fip_register(const char *name,
@@ -19,6 +22,13 @@ static inline int stm32mp_bbu_mmc_fip_register(const char *name,
return -ENOSYS;
}
+static inline int stm32mp_bbu_nor_fip_register(const char *name,
+ const char *devicefile,
+ unsigned long flags)
+{
+ return -ENOSYS;
+}
+
#endif
#endif /* MACH_STM32MP_BBU_H_ */
--
2.43.0
next prev parent reply other threads:[~2025-11-28 0:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-28 0:51 [PATCH 0/3] ARM: stm32mp: Add Avenger96 board support Sohaib Mohamed
2025-11-28 0:51 ` [PATCH 1/3] common: bbu: refactor flash operations into separate function Sohaib Mohamed
2025-11-28 9:35 ` Ahmad Fatoum
2025-11-28 0:51 ` Sohaib Mohamed [this message]
2025-11-28 9:39 ` [PATCH 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler Ahmad Fatoum
2025-12-01 10:38 ` Sascha Hauer
2025-11-28 0:51 ` [PATCH 3/3] ARM: stm32mp: add support for STM32MP157A Avenger96 board Sohaib Mohamed
2025-11-28 9:40 ` Ahmad Fatoum
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=20251128-avenger96-v1-2-009b13bd8df7@gmail.com \
--to=sohaib.amhmd@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/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