3 ms·
>SBI, which is RISCV's poor-man's implementation of x86 SMM, SMM is totally opaque and does whatever it wants, kidnapping the cpu and giving it back after a ra
by snvzz 3y ago
>SBI, which is RISCV's poor-man's implementation of x86 SMM,
SMM is totally opaque and does whatever it wants, kidnapping the cpu and giving it back after a random amount of time if at all. Fuck determinism or meeting any sort of hard realtime requirements. It hides bugs and architecture details from the OS, and it often can't even be disabled.
SBI serves a similar role, without the opacity. OS can make requests to it through APIs that are part of the spec, and even take over all its roles. It has been co-designed by hardware and software (operating systems and embedded) people across the industry, both companies and independent members. It's not even comparable.
Go read the SBI 1.0 spec, and the SBI 2.0 draft.
- pgeorgi 3y agoThis is a thread about Qualcomm looking into RISC-V. Seeing how "great" their ARM-based designs are, they will manage to make a real mess out of SBI soon enough and there will be weeping and gnashing of teeth. I'll stock up on my popcorn supplies, this will be fun to watch from a distance.
- snvzz 3y agoNevermind about making a non-compliant SBI implementation. Why make an implementation in the first place? There's no reason to use anything else than opensbi.
- pgeorgi 3y agoBecause Qualcomm _really_ dislikes letting others take a look at their (usually very boring) secret sauce. Even partners working on projects shoveling revenue counted with a sizable number of digits their way. That's also why QCSBI (or whatever they'll call it) won't be replaced by the kernel even though the architecture theoretically allows for it: That would be ceding control.