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

Arnd Bergmann arnd at arndb.de
Wed Jul 13 14:38:06 BST 2016

On Wednesday, July 13, 2016 1:48:51 PM CEST Alex Bradbury wrote:
> One issue that's come up while chatting to people here at the RISC-V
> workshop in Boston is avoiding needless arbitrary differences between
> platforms. Having different memory maps is an example of this (e.g.
> having the PLIC instantiated with a different base offset). However,
> there also seems to be the view that some RISC-V implementers will be
> unable or unwilling to conform to a shared standard memory layout.
> Given this is the case, do we risk actually increasing fragmentation
> in the community by exposing memory map details to OS porters and
> low-level system programmers as they may come to rely on them? Are
> there any other advantages in retaining full flexibility for hardware
> implementers to modify their memory map at will?
> Should if be RISC-V best practice that any OS porting work doesn't
> rely on a fixed memory map, and instead finds it at boot time through
> a device tree or device tree-like description? In cases where this
> doesn't make case an appropriate C header could be generated from that
> description, but the principle that the map isn't hardcoded in the OS
> codebase remains. I'm of course thinking beyond Linux here - it would
> seem a shame if it ended up that the seL4, FreeRTOS, ... ports did not
> work out of the box with any RISC-V implementation.

The main problem for operating systems is to have the kernel run at
a nonconstant physical address. On ARM Linux, we work around this by
patching every call to phys_to_virt() and virt_to_phys() at early
boot time as soon as we have detected the start of RAM.

This works fine for the most part, but there are a couple of downsides:

- It's hard to debug that early code since a lot of features (including
  the system console) may not be around.

- It prevents running a kernel from readonly memory such as a NOR
  flash or a virtual machine sharing its kernel image with other VMs.

- On machines without an MMU, the kernel actually ends up running
  from an unknown physical address, so it either has to be fully
  relocatable (which Linux currently doesn't do), or you have to
  link the kernel to the actual RAM address, meaning you cannot have
  the same kernel run across different machines that don't start from
  the same address.

On 64-bit ARM, there is another problem arising from how some people
decided to make their RAM addressing extremely sparse, meaning we
cannot use a linear mapping of physical to virtual addresses with
three-level page tables (the kernel can use either three-level or
four-level tables otherwise).


More information about the lowrisc-dev mailing list