Hi Nikita, On 2026-08-07T08:06:41, Nikita Shubin <[email protected]> wrote: > common: spl: ram: Add LOAD_FIT_FULL support > > Allow booting with spl_load_fit_image() if LOAD_FIT_FULL enabled.
Please can you expand the commit message to mention the motivation from your cover letter: spl_load_simple_fit() lacks the firmware/loadables handling needed for the RISC-V OpenSBI flow, so RAM boot should use the full parser when it is available. > > Signed-off-by: Nikita Shubin <[email protected]> > > common/spl/spl_ram.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c > @@ -81,11 +81,15 @@ static int spl_ram_load_image(struct spl_image_info > *spl_image, > debug("Found FIT\n"); > + if (CONFIG_IS_ENABLED(LOAD_FIT_FULL)) { > + ret = spl_load_fit_image(spl_image, header); > + } else { Since SPL_LOAD_FIT_FULL depends on SPL_LOAD_FIT, a board with both enabled currently uses spl_load_simple_fit() here and this patch silently switches it to the full path with no fallback. Note that spl_parse_image_header() tries spl_load_fit_image() first and falls back to other parsers if it fails. I suspect you should do the same here, so a FIT which the full parser cannot handle still boots. None of the six boards enabling SPL_LOAD_FIT_FULL today uses RAM/DFU boot, so nothing regresses immediately, but the fallback would make the precedence consistent across the two call sites. What do you think? Either way, please mention the precedence decision in the commit message. Regards, Simon
