Currently, there is no mechanism through which the SBI firmware can
communicate the details of its reserved memory region(s) to a supervisor
payload. There has been some discussion recently on how this can be
achieved [1], and it seems that it will happen via the device-tree, a
new set of SBI calls, or some combination of both.
This hasn't caused any issues for us yet, since we exclude all physical
memory below the kernel's load address from being allocated, and on all
currently supported platforms this covers the SBI firmware region.
OpenSBI has begun specifying its section of memory under the
"reserved-memory" device-tree property [2], which we can parse easily.
If this property is present, we know exactly which region of physical
memory the kernel should ignore.
In the case that no "reserved-memory" property is found, exclude the
lowest 2MB of memory from allocation. This isn't a perfect solution, but
it is consistent with how the currently supported platforms are set up,
allowing us to handle this case with BBL or the current release of
OpenSBI.
[1] https://github.com/riscv/riscv-sbi-doc/pull/37
[2] https://lists.infradead.org/pipermail/opensbi/2020-March/001544.html