mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sohaib Mohamed <sohaib.amhmd@gmail.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	BAREBOX <barebox@lists.infradead.org>
Subject: Re: [PATCH 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler
Date: Fri, 28 Nov 2025 10:39:58 +0100	[thread overview]
Message-ID: <dcb2c091-33a7-4c9c-822e-d62a3922d21e@pengutronix.de> (raw)
In-Reply-To: <20251128-avenger96-v1-2-009b13bd8df7@gmail.com>

On 11/28/25 1:51 AM, Sohaib Mohamed wrote:
> 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)

Above two paragraphs just repeat the same info.

> 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.

This doesn't reflect what the code is doing. It just passes it along to
bbu_flash. I would expect flashing a too big image would just fail with
-ENOSPC, because pwrite_full() couldn't write all bytes and not
truncation as the commit message claims.

> Signed-off-by: Sohaib Mohamed <sohaib.amhmd@gmail.com>

Acked-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

> ---
>  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_ */
> 

-- 
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 |




  reply	other threads:[~2025-11-28  9:40 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 ` [PATCH 2/3] ARM: stm32mp: bbu: add NOR flash FIP update handler Sohaib Mohamed
2025-11-28  9:39   ` Ahmad Fatoum [this message]
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=dcb2c091-33a7-4c9c-822e-d62a3922d21e@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox