From: Sohaib Mohamed <sohaib.amhmd@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler
Date: Wed, 3 Dec 2025 16:11:32 +0100 [thread overview]
Message-ID: <uhhhpqmdhnuycj4harqiycdbczxaeu6qxn7jlsuxn33guklohd@2sfe4g66i5tn> (raw)
In-Reply-To: <aS1wGqrhGhU6XfIR@pengutronix.de>
On Mon, Dec 01, 2025 at 11:38:18AM +0100, Sascha Hauer wrote:
> 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?
You're correct. Offset 512K is actually the default location for FIP
images in NOR flash layout. I will clarify this in the commit message.
>
> > 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-03 15:12 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
2025-12-03 15:11 ` Sohaib Mohamed [this message]
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=uhhhpqmdhnuycj4harqiycdbczxaeu6qxn7jlsuxn33guklohd@2sfe4g66i5tn \
--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