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.
