On Thu, 2026-06-25 at 11:59 +0100, Simon Glass wrote: > Hi Nikita, > > On 2026-06-19T12:52:56, Nikita Shubin <[email protected]> > 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
