-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Entry state unspecified #13
Comments
Yeah, this document certainly should state what can be assumed about the initial state. As you can see, it is rather incomplete. |
I've hit this point myself and it's kinda documented in a weird place, namely a file called What's different from that, however, is that Would that be a suitable starting point for filling in the gaps here? |
Is there any desire to have some description of entry state specified now that version 1.0.0 has been ratified? While most projects seem like they'll be using OpenSBI or a custom in-house SBI, having some wording (or at least mention that the spec deliberately doesn't specify it) would be useful. |
Is there any update here? Does this basically fall down do the documents in https://github.com/riscv-software-src/opensbi/tree/master/docs/firmware that describe the supported payloads for the initial start and then it's up to what is passed to the SBI call "HART start" to start other cores. |
SBI specification is just an interface specification between supervisor mode(S/VS) and its execution environment (M/HS mode). It should specify any entry state when entering or transitioning between those two only. The HSM/SUSP extension addresses the entry state requirement for that reason. The entry state of the system should be platform/firmware specific. Any firmware or platform specification probably is the right place to provide those information. The OpenSBI doc is guidance for OpenSBI implementation specific. Other implementations may or may not follow that. |
I'd expect this specification to describe the initial state of the system. That is, when whatever is supposed to use the SBI starts executing the first time. It should specify the current privilege level (supervisor mode?), the register state (opensbi and bbl pass important parameters like hart ID and FDT address in registers), and the state of other harts (opensbi and bbl start all harts that jump to the payload at the same time, which I find... surprising).
Maybe this is intentional and this is supposed to be the concern of boot loader implementations. Even then, it might be a good idea to define basic defaults.
The text was updated successfully, but these errors were encountered: