Re: Question regarding non-volatile memory mapped memory in embedded systems

Rob Herring <[email protected]> Mon, 2 Mar 2026 11:50:31 -0600
Newsgroups org.kernel.vger.devicetree-spec
Message-ID <CAL_JsqKJZuMzFKuS1-MagAdP9ETv8apms=q21LKF6G+wU+M6eA@mail.gmail.com>
On Tue, Feb 24, 2026 at 8:24=E2=80=AFAM Andreasen, Bjarki
<[email protected]> wrote:
>
> Hello from a zephyr-rtos dev,
>
> In embedded systems, it is typical to execute directly from non volatile =
memory mapped storage.

So eXecute In Place or XIP.

> Looking through the devicetree spec, there is a node for defining memory =
mapped system memory, and reserved memory, the /memory and /reserved-memory=
 nodes.
>
> Are the /memory and /reserved-memory nodes intended to be used with volat=
ile memory mapped storage in embedded systems?

Yes. And what's defined in /reserved-memory should be bounded by what
/memory node(s) define though given there is no enforcement of that,
that's probably not always true. /memory should not be defining RO
storage.

> A client program (which in an embedded system may be the entire program b=
ooted by the soc itself) is to a large extent agnostic to the exact type of=
 memory its executing from since the memory is memory mapped.
> As long as the program was compiled with the appropriate memory access pe=
rmissions, non volatile memory like flash being read/execute only, RAM bein=
g read/write/execute of course.

XIP isn't really defined for DT. I'm not sure it has to be as that's
more the protocol/interface between the prior stage and the
client(OS). You could still want/need a generic way to define the
non-volatile ranges. There are various MTD and partition bindings, but
those live under specific h/w devices rather than some generic node
like 'memory'.

Rob