[coreboot] Some qustion about riscv implement

[Jonathan Neuschäfer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170529/acf92148/attachment.asc>