Hi Simon,

Everything noted and agreed for all patches and comments, will be
fixed.

Thank you for your professional and kind review.

On Sat, 2026-08-08 at 07:49 -0600, Simon Glass wrote:
> Hi Nikita,
> 
> On 2026-08-07T08:06:41, Nikita Shubin <[email protected]>
> wrote:
> 
> > This series improves CONFIG_SPL_LOAD_FIT_FULL support on RISC-V,
> > primarily to enable loading OpenSBI as firmware and recording
> > loadable images (e.g., U-Boot) into the FDT passed to the next boot
> > stage. This aligns spl_load_fit_image() with the behaviour already
> > present in spl_load_simple_fit().
> 
> Just to check, what is the motivation for using LOAD_FIT_FULL here
> rather than the simple path? spl_load_simple_fit() already loads
> OpenSBI as firmware and records loadables, and is what existing RISC-
> V
> boards use today. Please can you explain in the cover letter why the
> full path is needed for your use case (e.g. full FIT verification),
> to
> justify the extra code in each board's SPL?
> 
> > - This works only if FIT Image contains dtb blob,
> > spl_load_simple_fit() on the other hand relocates gd->fdt_blob to
> > the end of U-Boot;
> >   It's currently unclear to me if spl_load_fit_image() should do
> > the same.
> 
> I suspect it should, since boards ought not to see different
> behaviour
> depending on which path is enabled. That can be a follow-on series,
> but please can you mention the limitation in the commit message so it
> is not forgotten?
> 
> > - I am not sure if sandbox test is a right thing to do, still i
> > think it's better than relying on QEMU for testing in this case;
> 
> Yes, a sandbox test is the right approach - the spl_load tests exist
> for exactly this purpose and run in CI on every commit, so please
> keep
> it. Since the test constructs its own FIT at runtime, the grafted
> image you used for manual testing is not needed for CI, which seems
> fine to me.
> 
> Regards,
> Simon

Yours, Shubin.

Reply via email to