[RFC,0/2] RISC-V SPL: fix OpenSBI FIT loading and OS entry point retrieval

[Nikita Shubin]

On Thu, 2026-06-25 at 11:59 +0100, Simon Glass wrote:
> Hi Nikita,
> 
> On 2026-06-19T12:52:56, Nikita Shubin <nikita.shubin at maquefel.me>
> wrote:
> 
> > Changes in v2:
> > - EDITME: describe what is new in this series revision.
> > - EDITME: use bulletpoints and terse descriptions.
> 
> Please fill in the b4 EDITME placeholders so reviewers can see what
> changed since v1.

Sorry - there is no v1. I had a b4 glitch and rolled back to v1, but
forgot to delete auto-placed "Changes in v2 ...".

> 
> > Question is - if Full FIT wasn't tested with RISC-V U-Boot SPL or i
> > am
> > doing something wrong ?
> 
> I suspect you are right - SPL_LOAD_FIT_FULL is rarely enabled and
> most
> RISC-V boards use the non-FULL FIT path. Thanks for looking into it.
> 
> The series is missing test coverage. See test/image/ and the SPL
> sandbox tests; OpenSBI loadable handling should grow a regression
> test, otherwise this will silently break again. Please can you add
> one, or say in the cover letter why it is not feasible.

Agree.

> 
> On the design - stashing uboot_addr and kernel_addr in spl_image_info
> as a side channel from spl_load_fit_image() to spl_invoke_opensbi()
> works, but feels indirect. The real bug is that spl_invoke_opensbi()
> looks in the wrong FDT (the OS DTB rather than the FIT). Would it be
> cleaner to keep a pointer to the FIT itself around for this lookup,
> rather than caching addresses by OS type? What do you think?

I need to study the proposals in detail to reach a solution that
actually solves the problem. The current one was more of a prompt for
an RFC and a way of identifying the existing problem.

Thank you for the detailed and thoughtful reply.

Yours,
Nikita.
> 
> Regards,
> Simon