Open ghost opened 5 years ago
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 mee-spec.md
located in the Metal library: https://github.com/sifive/freedom-metal/blob/v201908-branch/doc/mee-spec.md#c-startup-interface
What's different from that, however, is that a2
appears to not be explicitly assigned to a "yes I've finished setting everything up" callback (at least on OpenSBI).
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.