public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Beleswar Padhi <b-padhi@ti.com>
Cc: afd@ti.com, bb@ti.com, anshuld@ti.com, hnagalla@ti.com,
	jm@ti.com, nm@ti.com, n-francis@ti.com, u-kumar1@ti.com,
	u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent
Date: Fri, 2 Jan 2026 08:55:12 -0600	[thread overview]
Message-ID: <20260102145512.GC6124@bill-the-cat> (raw)
In-Reply-To: <20260102144710.GB6124@bill-the-cat>

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

On Fri, Jan 02, 2026 at 08:47:10AM -0600, Tom Rini wrote:
> On Wed, Dec 31, 2025 at 11:06:11PM +0530, Beleswar Padhi wrote:
> 
> > In cases where the 'load' property is not defined in a FIT image node,
> > fallback to using the data address returned by `fit_image_get_data()`.
> > This enables FIT images to omit the 'load' property during FIT creation.
> > 
> > Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> > ---
> > Cc: Simon Glass <sjg@chromium.org>
> > 
> > v3: Changelog:
> > 1. None
> > 
> > Link to v2:
> > https://lore.kernel.org/all/20250506104202.16741-3-b-padhi@ti.com/
> > 
> > v2: Changelog:
> > 1. New patch. Add support to load images without 'load' property.
> > 
> >  common/spl/spl_fit.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index a588d13eb40..c18c98b2959 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -803,6 +803,8 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
> >  {
> >  	struct spl_image_info image_info;
> >  	struct spl_fit_info ctx;
> > +	const void *fit_image_loadaddr;
> > +	size_t fit_image_size;
> >  	int node = -1;
> >  	int ret;
> >  	int index = 0;
> > @@ -893,7 +895,19 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
> >  		if (firmware_node == node)
> >  			continue;
> >  
> > -		image_info.load_addr = 0;
> > +		/*
> > +		 * If the 'load' property is not present in the image node,
> > +		 * use the FIT image's data address as the fallback load
> > +		 * address. This allows flexibility in omitting the load address
> > +		 * during FIT creation time.
> > +		 */
> > +		ret = fit_image_get_data(ctx.fit, node,
> > +					 &fit_image_loadaddr, &fit_image_size);
> > +		if (ret < 0)
> > +			panic("Error accessing node = %d in FIT (%d)\n", node,
> > +			      ret);
> > +
> > +		image_info.load_addr = (ulong)fit_image_loadaddr;
> >  		ret = load_simple_fit(info, offset, &ctx, node, &image_info);
> >  		if (ret < 0 && ret != -EBADSLT) {
> >  			printf("%s: can't load image loadables index %d (ret = %d)\n",
> 
> What's the IH_TYPE here? Saying to use something in-place is not always
> safe.

Looking at the rest of the series, and then going back to v1 and:
https://lore.kernel.org/all/b6bc14fc-c823-4376-939f-2c0e6b120a2c@ti.com/
we're IH_TYPE_STANDALONE which *does* require a load address (see
boot/image-fit.c). You might need to look in to a new type or see if
another type is reasonable, that doesn't already expect a load address
set.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2026-01-02 14:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-31 17:36 [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 01/11] spl: Use FIT data address as fallback when 'load' property is absent Beleswar Padhi
2026-01-02 14:47   ` Tom Rini
2026-01-02 14:55     ` Tom Rini [this message]
2026-01-05  7:17       ` Padhi, Beleswar
2025-12-31 17:36 ` [PATCH v3 02/11] arm: mach-k3: Use FIT image data addr as fallback if 'load' prop is missing Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 03/11] arm: mach-k3: Explicitly identify TIFSSTUB images when discarding buffers Beleswar Padhi
2026-01-05 16:53   ` Andrew Davis
2025-12-31 17:36 ` [PATCH v3 04/11] arm: mach-k3: Add config option for packaging HSM firmware Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 05/11] arm: dts: k3-binman: Add template for packing " Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 06/11] arm: dts: k3-{j721s2/j722s/j784s4}-binman: Pack HSM firmware inside tispl.bin Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 07/11] binman: openssl: Add boot and load extensions to x509 cert Beleswar Padhi
2026-01-05 23:30   ` Simon Glass
2026-01-06 10:52     ` Beleswar Prasad Padhi
2025-12-31 17:36 ` [PATCH v3 08/11] arm: dts: k3-{j721s2/j722s/j784s4}-r5.dtsi: Enable HSM core Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 09/11] remoteproc: k3-hsm: Introduce a remoteproc driver for K3 " Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 10/11] arm: mach-k3: r5: common: Invoke boot of HSM M4 core Beleswar Padhi
2025-12-31 17:36 ` [PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot Beleswar Padhi
2026-01-05 14:11   ` Bryan Brattlof
2026-01-05 17:19     ` Andrew Davis
2026-01-06 10:37       ` Beleswar Prasad Padhi
2026-01-06 13:59         ` Tom Rini
2026-01-02 14:43 ` [PATCH v3 00/11] Add support to boot TI K3 HSM M4 core Tom Rini

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=20260102145512.GC6124@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=afd@ti.com \
    --cc=anshuld@ti.com \
    --cc=b-padhi@ti.com \
    --cc=bb@ti.com \
    --cc=hnagalla@ti.com \
    --cc=jm@ti.com \
    --cc=n-francis@ti.com \
    --cc=nm@ti.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=u-kumar1@ti.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