From: Sascha Hauer <s.hauer@pengutronix.de>
To: Sohaib Mohamed <sohaib.amhmd@gmail.com>
Cc: BAREBOX <barebox@lists.infradead.org>
Subject: Re: [PATCH 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler
Date: Mon, 1 Dec 2025 11:38:18 +0100 [thread overview]
Message-ID: <aS1wGqrhGhU6XfIR@pengutronix.de> (raw)
In-Reply-To: <20251128-avenger96-v1-2-009b13bd8df7@gmail.com>
On Fri, Nov 28, 2025 at 01:51:18AM +0100, Sohaib Mohamed wrote:
> Add support for updating STM32MP1 bootloader in NOR flash. The handler
> automatically detects FIP location (256K or 512K offset) and flashes
The "or 512K offset" part isn't implemented, right?
> 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.
I guess you mean that not the FIP image is truncated, but the input
image (/dev/mmcx.boot) is truncated to the actual FIP image size.
But like Ahmad I can't find this part implemented. Should we just drop
this sentence for now?
Sascha
>
> 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
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-12-01 10:38 UTC|newest]
Thread overview: 9+ 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 ` [PATCH 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler Sohaib Mohamed
2025-11-28 9:39 ` Ahmad Fatoum
2025-12-01 10:38 ` Sascha Hauer [this message]
2025-12-03 15:11 ` Sohaib Mohamed
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=aS1wGqrhGhU6XfIR@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=sohaib.amhmd@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.