4 ms·

ARM: "This document defines the Boot and Runtime Services expected by an enterprise platform Operating System or hypervisor, for an SBSA-compliant Arm AArch64 s

ARM: "This document defines the Boot and Runtime Services expected by an enterprise platform Operating System or hypervisor, for an SBSA-compliant Arm AArch64 server which follows the UEFI and ACPI specifications." (https://documentation-service.arm.com/static/5fb7e415d77dd807b9a80c80?token= https://documentation-service.arm.com/static/5fb7e415d77dd80...) Also "This document identifies the Arm and industry standard firmware interfaces applicable to the Arm 64-bit architecture. They include the PSCI, SMCCC, UEFI, ACPI, SMBIOS, and DT interfaces. Requirements that are based on these interfaces are specified. In addition, various recipes are created to accommodate the various operating systems and hypervisors." (https://documentation-service.arm.com/static/627a75d3148af93a314a2b36?token= https://documentation-service.arm.com/static/627a75d3148af93...) Two out of three "recipes" are UEFI-based. -- As for RISCV, they're embracing UEFI, too: https://riscv.org/announcements/2022/06/risc-v-announces-first-new-specifications-of-2022-adding-to-16-ratified-in-2021-risc-v-international/ https://riscv.org/announcements/2022/06/risc-v-announces-fir... Note that the announcement also refers to SBI, which is RISCV's poor-man's implementation of x86 SMM, quickly becoming a required component on the platform because OSes call into that.

rwmj 3y ago
OpenSBI is open source so hardly comparable to SMM. https://github.com/riscv-software-src/opensbi https://github.com/riscv-software-src/opensbi
- pgeorgi 3y ago
  There's Open Source SMM as well (e.g. https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/src/cpu/x86/smm/smm_module_handler.c https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/...) and it's still a pain. "There's services outside the kernel's control that may or may not do what the kernel/userland/user expect because they can be independently updated, and, oh by the way, they're really powerful" is simply a pain to deal with.
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 ago
  This 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 ago
    Nevermind 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 ago
      Because 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.

rwmj 3y ago

OpenSBI is open source so hardly comparable to SMM. https://github.com/riscv-software-src/opensbi https://github.com/riscv-software-src/opensbi

pgeorgi 3y ago
There's Open Source SMM as well (e.g. https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/src/cpu/x86/smm/smm_module_handler.c https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/...) and it's still a pain. "There's services outside the kernel's control that may or may not do what the kernel/userland/user expect because they can be independently updated, and, oh by the way, they're really powerful" is simply a pain to deal with.

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 ago
This 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 ago
  Nevermind 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 ago
    Because 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.