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

[Sean Anderson]

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

Where SPL loads SBI and U-Boot and tells SBI "please run U-Boot after you are
done booting". But the idea here is to load Linux instead of U-Boot. I think
this is pretty similar to Falcon mode. Actually, when CONFIG_SPL_OPENSBI is
enabled, I think it's reasonable for falcon mode to do exactly that. People
who want the SPL -> Linux path can disable SPL_OPENSBI.

--Sean