[lowrisc-dev] Re: [sw-dev] Is a de facto standard memory map helpful or harmful?

Arnd Bergmann arnd at arndb.de
Wed Jul 13 20:50:35 BST 2016

On Wednesday, July 13, 2016 2:16:24 PM CEST Alex Bradbury wrote:
> On 13 July 2016 at 13:59, Krste Asanovic <krste at berkeley.edu> wrote:
> > Config string is supposed to provide this information.  We have code
> > to parse and package this for Linux.  OS ports should all use this
> > and the SBI to avoid binding to absolute physical addressees.
> Great, I suspected we are thinking along similar lines. What actually
> triggered this email is I saw the SiFive "U5 Coreplex Series Manual"
> explicitly details the memory map. I've thought previously about doing
> this with our current lowRISC implementation (and indeed working with
> other groups to try to agree on this), but then wondered whether in a
> world of device tree and similar systems such as the proposed RISC-V
> configuration string this is necessary or beneficial. Perhaps the
> SiFive document could contain a note indicating that best practice for
> software developers is to not rely on hardcoded values indicated in
> this map?

In my earlier reply I was commenting purely on the issue of finding
the location of RAM, not MMIO devices, and these are two very different

For finding RAM, almost all platforms rely on hardcoding the start of
RAM and the fact that all RAM is contigous (with perhaps a small
hole for 32-bit PCI MMIO), and ARM is an exception to that which
requires a bit of a hack as I explained.

For MMIO areas such as PCI memory space, any operating system
should be prepared to use arbitrary addresses. In the best case you
can simply query the hardware through an architected method (special
CPU instructions or special purpose registers), and when that is
not available, a flattened DT is the normal way to pass that

In previous information that I have seen about RISC-V, the idea
was always to completely avoid MMIO and have discoverable hardware,
which would nicely sidestep the problem entirely, but the information
in the U5 Coreplex Series Manual gives up on that and just uses
MMIO, presumably because otherwise you cannot easily reuse existing
IP blocks. This means at least the Linux port will have to use
a software device tree to describe what is actually there.

Unfortunately, the memory map described on page 12 of that document
makes the same mistake as some ARM64 chips and makes the RAM
location extremely sparse, with the first 14GB starting close to
zero, but all RAM beyond that starting at 0x1_0000_0000_0000
(256TB), which I guess requires using an extra level of page tables
for the kind of linear mapping that Linux has. It's probably too
late to change that, but I'd suggest that future implementations
do it differently.


More information about the lowrisc-dev mailing list