[PATCH 1/4] riscv: spl: Introduce SPL_OPENSBI_OS_BOOT

[Rick Chen]

> On 12/13/22 11:24, Tom Rini wrote:
> > On Tue, Dec 13, 2022 at 08:42:47AM +0800, Rick Chen wrote:
> >> Hi Sean,
> >>
> >>> On 12/12/22 10:03, Tom Rini wrote:
> >>>> On Mon, Dec 12, 2022 at 02:45:10PM +0800, Rick Chen wrote:
> >>>>> Hi Tom
> >>>>>
> >>>>>> On Fri, Dec 09, 2022 at 08:48:37AM -0500, Sean Anderson wrote:
> >>>>>>> On 12/7/22 01:23, Rick Chen wrote:
> >>>>>>>> In RISC-V, it only provide normal mode booting currently.
> >>>>>>>> To speed up the booting process, here provide SPL_OPENSBI_OS_BOOT
> >>>>>>>> to achieve this feature which will be call Fast-Boot mode. By
> >>>>>>>
> >>>>>>> Can you name this something different. We already have something called
> >>>>>>> fastboot in-tree (the Android-derived protocol) and there's a Microsoft
> >>>>>>> technology called fastboot (some kind of hibernation). "OS Boot" isn't
> >>>>>>> very specific either, since we (almost always) boot an OS. Maybe "Eagle
> >>>>>>> mode" by analogy to Falcon mode, which lets SPL directly boot an OS.
> >>>>>>>
> >>>>>>> (Is this substantially different from falcon mode anyway?)
> >>>>>>
> >>>>>> I was kind of wondering if this is different, really, from Falcon Mode.
> >>>>>> Falcon Mode didn't initially have to factor in other-firmware as that's
> >>>>>> not a hard requirement on arm32 like it is on arm64 or risc-v.  But my
> >>>>>> first read of this was that it seems like the RISC-V specific side of
> >>>>>> doing Falcon Mode and dealing with the prior stage needs correctly.
> >>>>>>
> >>>>>
> >>>>> Yes. It is a little bit different from the Falcon mode (SPL_OS_BOOT=y).
> >>>>> When I try to enable SPL_OS_BOOT, it will encounter that SYS_SPL_ARGS_ADDR and
> >>>>>    jump_to_image_linux() shall be defined but they are un-necessary for RISC-V.
> >>>>> Because the flow of OpenSBI and SPL_OS_BOOT are totally different code
> >>>>> flow in board_init_r() of common/spl/spl.c.
> >>>>> That is why I added a new symbol called SPL_OPENSBI_OS_BOOT for this
> >>>>> RISC-V fast boot implementation.
> >>>>
> >>>> Those sound like fairly minor challenges for the same fundamental
> >>>> concept. We have SYS_SPL_ARGS_ADDR for "where is the device tree to
> >>>> pass along". We might need to do a little code re-factoring here. But
> >>>> maybe also a little bit of explaining why we wouldn't be booting to the
> >>>> OS directly but instead passing back to openSBI to do this? That's not
> >>>> normally how RISC-V boots the OS, right? Or am I miss-understanding
> >>>> something here?
> >>>>
> >>>
> >>> The usual process is
> >>>
> >>> ROM -> SPL -> SBI -> U-Boot -> Linux
> >>
> >> In RISC-V, Linux runs in S-mode, it needs the OpenSBI which plays as
> >> M-mode to deal with SBI calls at run-time.
> >> So the fast boot idea, I just want to bypass U-Boot and jump to Linux
> >> directly and Linux still needs OpenSBI.
> >> Hence SPL_OPENSBI can't be disabled here.
> >
> > So is the flow here:
> > a) ROM -> SPL -> SBI -> SPL -> Linux
> > or
> > b) ROM -> SPL -> SBI -> Linux
>
> The latter. The regular boot is
>
> (M) Boot ROM loads SPL and executes it
> (M) SPL loads SBI and U-Boot proper and executes SBI
> (M) SBI performs initialization and executes U-Boot
> (S) U-Boot loads Linux and executes it
> (S) Linux boots
>
> And this would change that to
>
> (M) Boot ROM loads SPL and executes it
> (M) SPL loads SBI and Linux and executes SBI
> (M) SBI performs initialization and executes Linux
> (S) Linux boots
>
> So the idea here is to load Linux in SPL instead of U-Boot. But I think this is
> the only way to go for platforms which use OpenSBI. Regular falcon mode would
> require a Linux which runs in M-mode. So I don't think we need a separate config.

Hi Sean,

Thanks for your explanation. It is very clear.

Hi Tom, Sean,

Do you have any further suggestions that I can improve or refine this patch ?

Thanks,
Rick

>
> --Sean
>
> > It's not clear to me, and I think that'll help figure out what's best
> > here. Since I kinda think we're looking at a more generic issue that we
> > see with newer architectures and maybe we already had to solve this (but
> > didn't name things well enough) for aarch64.
> >
>
>
>