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
