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.