On Mon, May 29, 2017 at 02:14:25AM +0000, Peter Stuge wrote:
Jonathan Neuschäfer wrote:
I wonder if we should just import libfdt when we need to parse or modify devicetree blobs. A quick check on the libfdt.a on my system (x86_64) shows that the set of .o files takes about 15kB, so it's not huge.
If the license is compatible I think that's a good idea.
libfdt is GPLv2/BSD dual-licensed.
(https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/README.license#n17)
I think we should consider splitting the memory-resident part of coreboot on RISC-V into its own stage, similar to the SMM code on x86.
Is there any way a system can work completely without it?
The specs are still in flux / incomplete, so I don't know exactly which functions the interface will contain. My best guess is: If you control both coreboot and the OS, and the hardware doesn't require M-mode for necessary operations such as IPIs, you can run without runtime firmware. And if the hardware requires M-mode for certain operations, I can still imagine having an OS-provided shim that takes requests from the OS and performs those operations.
The official model seems to be that the hardware vendor provides firmware that abstracts over some hardware details through SBI calls, and the OS uses it.
Another thing that may require runtime firmware is the handling of misaligned data accesses. As far as I understand it, hardware implementations are allowed to raise an exception when data is stored/loaded at a misaligned address, but software (even in supervisor mode) may assume that it can perform misaligned accesses. This places the burden on the machine-mode firmware to handle these exceptions and emulate the load/store operation. For several reasons I'd like to simple forward those exceptions to the OS:
* Less runtime firmware needed (trap forwarding can be configured by setting a bit in a control register) * Better diagnosis and context-dependent handling: Linux can report misaligned memory accesses, so the overhead of trap-and-emulate can be avoided in the future (I've recently seen that on SPARC). It can also be instructed to send userspace a SIGBUS on misaligned accesses, for trouble shooting purposes.
Jonathan