From: Sohaib Mohamed <sohaib.amhmd@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>,
Ahmad Fatoum <a.fatoum@pengutronix.de>,
BAREBOX <barebox@lists.infradead.org>
Cc: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Subject: [PATCH v2 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler
Date: Wed, 03 Dec 2025 18:13:17 +0100 [thread overview]
Message-ID: <20251203-avenger96-v2-2-95f0cfa50aaa@gmail.com> (raw)
In-Reply-To: <20251203-avenger96-v2-0-95f0cfa50aaa@gmail.com>
Add a barebox update handler for STM32MP NOR flash to support firmware
updates in different scenarios. The STM32MP NOR flash layout uses offset 0
for FSBL and offset 512K for FIP, while eMMC boot partitions have FSBL at
offset 0 and FIP at offset 256K. The handler detects the image type and
flashes accordingly: standalone FIP images go to 512K, standalone FSBL
images to offset 0, and combined eMMC boot partition images (detected by
finding FIP at 256K offset) get split with FSBL flashed to offset 0 and
FIP to 512K. Images that exceed available space will fail with -ENOSPC
when pwrite_full() cannot write all bytes.
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-12-03 17:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-03 17:13 [PATCH v2 0/3] ARM: stm32mp: Add Avenger96 board support Sohaib Mohamed
2025-12-03 17:13 ` [PATCH v2 1/3] common: bbu: refactor flash operations into separate function Sohaib Mohamed
2025-12-03 17:13 ` Sohaib Mohamed [this message]
2025-12-03 17:13 ` [PATCH v2 3/3] ARM: stm32mp: add support for STM32MP157A Avenger96 board Sohaib Mohamed
2025-12-04 7:15 ` [PATCH v2 0/3] ARM: stm32mp: Add Avenger96 board support Maud Spierings
2025-12-04 9:23 ` Ahmad Fatoum
2025-12-04 20:47 ` Sohaib Mohamed
2025-12-08 7:42 ` 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=20251203-avenger96-v2-2-95f0cfa50aaa@gmail.com \
--to=sohaib.amhmd@gmail.com \
--cc=a.fatoum@pengutronix.de \
--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