5 ms·
RISC-V SBI and the full boot process
- Taniwha 3y agoIt's worth understanding that the initial hard coded (pre OpenSBI) code on a real CPU (rather than an emulator like QEMU) is likely doing a bunch of things: - Initialising the DRAM controller and sizing memory - optionally doing some crypto auth of the OpenSBI/etc to make sure they're not bogus - Copying OpenSBI (and possibly a subsequent U-boot or kernel) into it from ROM
- deleted 3y ago[deleted]
- aappleby 3y agoYep, and if you're playing with your own homebrew OS or other non-linux OSes you don't really need all of OpenSBI - implementing the equivalent of putchar() and a few timer calls will get you up and running. (Source - did bring up for rv32 simulators running TockOS and seL4).
- Taniwha 3y agoyou may need the emulation of unaligned memory accesses - which is something else that OpenSBI does for you
- kaycebasques 3y agoAre there any highly regarded bringup docs out there? I.e. docs from an OS, emulator, etc. that do a great job of explaining how to get the OS running on new hardware. Or is it usually just done by studying previous code examples and asking experts for help?
- Taniwha 3y agoAlso the RISC-V ABI requires that the initial code passes a pointer to a minimal device tree to OpenSBI - this means it can tell it where the UART is, how many CPUs to expect, where the interrupt controllers are (and what type they are) etc etc - this can then be passed on to uboot/uefi/linux or overridden or edited as they like
- xxpor 3y agoDoes that mean RISC-V doesn't support ACPI at all, even in theory?
- snvzz 3y agoThere's a RISC-V ACPI spec[0]. Note anything to do with ACPI would run after, not before, OpenSBI. 0. https://github.com/riscv-non-isa/riscv-acpi/releases https://github.com/riscv-non-isa/riscv-acpi/releases
- xxpor 3y agoAh, I was thinking OpenSBI was more like the ME for RISC-V, I probably should have googled it.
- rwmj 3y agoYes there's ACPI & UEFI. Sunil V L from Ventana has been gradually pushing ECRs through the ACPI organization to add features and getting the corresponding stuff into the Linux kernel, eg: https://lore.kernel.org/lkml/20230216182043.1946553-4-sunilvl@ventanamicro.com/ https://lore.kernel.org/lkml/20230216182043.1946553-4-sunilv...
- codedokode 3y agoWhy cannot UART address be fixed by a standard? Is there any merit in having UART at different addresses on different machines?
- wazzaps 3y ago
- codedokode 3y agoyou forgot "adding a backdoor for remote access by manufacturer"
- phh 3y ago> - Initialising the DRAM controller and sizing memory Hum I don't really understand that one. Based on the article I understood that the code before SBI was directly bootrom, and usually bootrom doesn't init DRAM (at least that's not how rockchip/allwinner/amlogic SoCs behave). So what's the expectation on how SoC vendors implement DDR init code? It's expected that SoC vendor push this code to bootrom (thus costing more in maskrom)?
- dezgeg 3y agoNothing forces it to be in ROM. See for example https://github.com/carlosedp/riscv-bringup/blob/master/unleashed/Readme.md https://github.com/carlosedp/riscv-bringup/blob/master/unlea... where DRAM init seems to be in the FSBL part which is loaded from the SD card.
- Taniwha 3y agoDepends on what sort of boot rom you have - typically the code before SBI is hard baked into the CPU while SBI, uboot, linux etc are copied into DRAM and run there - this may not be true on embedded systems which may have SRAM for loading initial code into. These days though SDRAM controllers are complex, and need careful tuning when the power comes on (and the chip heats up), the code that runs cycles to initialise DRAM is often very complex and proprietary. If you're building a high performance chip you typically have very big wide L1 caches, and relatively wide paths to DRAM - you don't want to hamper them by having to attach them to a much slower 8-bit wide ROM (typically eMMC these days) - better to have boot code do the copy (eMMC looks like a fast SD card) - there are tricks you can do with L1 cache tag management that turns it into an SRAM until DRAM is initialised
- deleted 3y ago[deleted]
- IshKebab 3y agoGreat info, though very verbose!
- j16sdiz 3y agoIt is still not the "full" boot process. Modern hardware need lots of code to initialize from boot to usable.
- ruslan 3y agoI would like to read a brief review of OpenSBI functions, or a rather minimum required set to get Linux like OS to run. How much Linux kernel depends on supervisor ? Also, worth pointing that there's U-Boot which also does some hardware initialization on which kernel relies on.
- Taniwha 3y agoUBoot typically runs in supervisor mode while OpenSBI runs in machine mode (as would OPTEE) - OpenSBI's (and OPTEE's) memory is locked behind a PMAP block so it can't be hacked from supervisor mode If your riscv core has hypervisor support that sits between machine mode and supervisor modes
- synergy20 3y agoisn's OpenSBI's S means 'supervisor' mode? so OpenSBI is supposed to be in supervisor mode?
- Taniwha 3y agoNope, it runs in machine mode (I've ported it) - the S does stand for Supervisor, but I guess that's because it supervises the system
- brucehoult 3y agoSBI is the ABI for the Supervisor to call to get certain services that can't be done in S mode.
- snvzz 3y agoThe SBI spec[0] is not a long read. 0. https://github.com/riscv-non-isa/riscv-sbi-doc/releases https://github.com/riscv-non-isa/riscv-sbi-doc/releases