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

[Sean Anderson]

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.

--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.
>