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

[Tom Rini]

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

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221213/8337bc95/attachment.sig>