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