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

Reply via email to