Add NVMEM support #96379

pdgendt · 2025-09-22T14:56:57Z

Introduce the NVMEM subsystem. Inspired from linux this subsystem allows to read and write data to Non-Volatile memory, for example to store a MAC address or SoC/Device specific data.

It comes with support for EEPROM devices. The device API backend is determined at runtime using DEVICE_API_IS.

See #96598 for an example use case.

Derived from #74835

Laczen · 2025-09-23T08:58:02Z

@pdgendt this is a nice addition.

Can it be extended to other backends (e.g. fuses, bbram) ?

IMHO it should be straightforward to add a settings backend for this (e.g. store/retrieve items under "nvmem/xxx").

pdgendt · 2025-09-23T10:03:54Z

Can it be extended to other backends (e.g. fuses, bbram) ?

That's the idea, in nvmem.c it checks the device API at runtime, logic can be added there.

IMHO it should be straightforward to add a settings backend for this (e.g. store/retrieve items under "nvmem/xxx").

Sure, maybe. Outside of the scope of this PR though.

pdgendt · 2025-09-23T12:05:32Z

Removed the draft state to get some early feedback before adding more documentation bits.

decsny

please review linux binding https://www.kernel.org/doc/Documentation/devicetree/bindings/nvmem/ , note also the layouts folder

henrikbrixandersen

I like it! Simple, yet extensible and a good level of abstraction. A few comments below:

dts/bindings/nvmem/fixed-layout.yaml

include/zephyr/nvmem.h

subsys/nvmem/Kconfig

include/zephyr/nvmem.h

tests/subsys/nvmem/devicetree/src/main.c

GseoC · 2025-10-03T12:48:37Z

dts/bindings/nvmem/fixed-layout.yaml

+
+      cell_nodelabel: cell@START_OFFSET {
+              reg = <0xSTART_OFFSET 0xSIZE>;
+              #nvmem-cell-cells = <0>;


Hello Pieter, what are you planning to do with #nvmem-cell-cells? Isn't it enough to work with reg and #address-cells + #size-cells. It's not documented for now so might as well remove it if not necessary?

This is required to work with phandle-array binding types (see the docs). I didn't want to introduce special treatment in some of the python code for this.

I don't have plans for this, but it can be used for future types of NVMEM providers. I can't give an example from the top of my head though.

GseoC · 2025-10-03T12:49:14Z

include/zephyr/nvmem.h

+ *			#size-cells = <1>;
+ *			mac_address: mac_address@fa {
+ *				reg = <0xfa 0x06>;
+ *				#nvmem-cell-cells = <0>;


If not necessary (previous comment), can remove occurences in this file.

GseoC · 2025-10-03T12:50:27Z

subsys/nvmem/nvmem.c

+
+int nvmem_cell_read(const struct nvmem_cell *cell, void *buf, off_t off, size_t len)
+{
+	if (off < 0 || cell->size < off + len) {


is it necessary to check if cell isn't NULL? ditto in other exposed APIs if so.

IMO it's up to the caller to check for non-NULL cells, same for buf, the contract of the API to the pass a pointer to a struct nvmem_cell.

I've updated the PR with asserts for non-NULL cell pointers.

include/zephyr/nvmem.h

nordicjm · 2025-10-06T07:24:39Z

include/zephyr/nvmem.h

+ *
+ * @kconfig_dep{CONFIG_NVMEM}
+ *
+ * @return 0 on success, negative errno code on failure.


some of these use @return some use @retval, I vaugley remember that @retval needs multiple lines one per value, unsure on @return or if one should be used over the other

Had one (wrong) use of @retval, updated, thanks!

include/zephyr/devicetree/nvmem.h

Adds property nvmem-cells for referencing a node that stores some configuration information. A typical use case is the reading of MAC address from an EEPROM device. Signed-off-by: Andriy Gelman <[email protected]> Signed-off-by: Pieter De Gendt <[email protected]>

Add a devicetree binding to represent a fixed layout in an NVMEM provider. Signed-off-by: Pieter De Gendt <[email protected]>

This commit adds the NVMEM subsystem with a basic implementation for use with EEPROM devices. Signed-off-by: Pieter De Gendt <[email protected]>

Add basic testing to validate the API of the NVMEM subsystem. Add testing with an EEPROM backend. Signed-off-by: Pieter De Gendt <[email protected]>

Add test cases tot the devicetree API testsuite for NVMEM macros. Signed-off-by: Pieter De Gendt <[email protected]>

Introduce a page for the Non-Volatile Memory subsystem with a reference to the doxygen API. Signed-off-by: Pieter De Gendt <[email protected]>

Add an entry to the API and options section for the Non-Volatile Memory subsystem. Signed-off-by: Pieter De Gendt <[email protected]>

Create a section for the newly maintained NVMEM area. Signed-off-by: Pieter De Gendt <[email protected]>

JarmouniA · 2025-10-06T17:54:41Z

Can this be used with SoC Flash, external NOR Flash?

sonarqubecloud · 2025-10-06T17:55:55Z

Quality Gate passed

Issues
29 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

henrikbrixandersen · 2025-10-06T17:57:15Z

Can this be used with SoC Flash, external NOR Flash?

Current implementation in this PR only supports EEPROMs as NVMEM providers, but this can very easily be extended in the future.

pdgendt · 2025-10-06T17:58:51Z

Can this be used with SoC Flash, external NOR Flash?

I guess it can, especially for read-only cells. The tricky bit would probably be writing, as it could require additional erase logic.
Not in scope of this PR though. I want to do the follow-up PR where the network drivers can use NVMEM cells for MAC address logic.

nashif · 2025-10-06T17:59:24Z

@pdgendt @henrikbrixandersen

nice stuff, i have seen this on arch wg agenda last week, are there some minutes somewhere with the outcome?

mbolivar

Binding looks like a good start, no need to boil the ocean and support everything out of the box IMO.

pdgendt · 2025-10-06T18:22:56Z

@pdgendt @henrikbrixandersen

nice stuff, i have seen this on arch wg agenda last week, are there some minutes somewhere with the outcome?

Not sure if notes were taken, I presented the idea and what it is trying to solve (the MAC address logic in network drivers for me), feedback was very positive overall, as far as I can remember.

henrikbrixandersen · 2025-10-06T18:30:00Z

Architecture WG meeting, 2025-09-30:

@pdgendt presented the motivation for adding the NVMEM subsystem, providing an abstraction for referencing/obtaining data from specific locations in non-volatile memory devices in both devicetree/C code (one example being to read an Ethernet MAC address from a given offset in an EEPROM).
PoC for using the for retrieving MAC addresses is available in [PoC] drivers: ethernet/wifi: Use NVMEM cell to get MAC address #96598
The bindings are inspired by the same fixed-layout as used in the Linux kernel devicetree.
Currently, this only supports EEPROM backends, but other backends (fuses, flash, etc.) can be added in the future as needed, as long as the backend supports read and optionally write operations.
Consensus is that this is a welcome addition, attempt to target Zephyr v4.3

henrikbrixandersen · 2025-10-06T18:30:49Z

My apologies, just realised I never got around to cleanup my notes from the meeting and actually post them.

pdgendt requested review from henrikbrixandersen and Laczen September 22, 2025 14:56

pdgendt force-pushed the nvmem branch 2 times, most recently from 3950927 to 4536d4e Compare September 23, 2025 05:55

pdgendt force-pushed the nvmem branch from 4536d4e to eaa042e Compare September 23, 2025 10:01

pdgendt force-pushed the nvmem branch 2 times, most recently from 91b7c21 to 1ae57e1 Compare September 23, 2025 12:00

pdgendt marked this pull request as ready for review September 23, 2025 12:04

zephyrbot added area: EEPROM area: Devicetree labels Sep 23, 2025

zephyrbot requested review from decsny, mbolivar and rruuaanng September 23, 2025 12:06

zephyrbot assigned mbolivar Sep 23, 2025

decsny previously requested changes Sep 23, 2025

View reviewed changes

pdgendt force-pushed the nvmem branch 2 times, most recently from aeee230 to c1a5bc6 Compare September 23, 2025 13:26

zephyrbot added the area: MAINTAINER File label Sep 23, 2025

zephyrbot requested review from MaureenHelm, nashif and stephanosio September 23, 2025 13:28

pdgendt force-pushed the nvmem branch from c1a5bc6 to 9e43473 Compare September 23, 2025 13:33

henrikbrixandersen requested changes Sep 23, 2025

View reviewed changes

pdgendt force-pushed the nvmem branch from 9e43473 to 9cae4c8 Compare September 24, 2025 07:05

pdgendt unassigned mbolivar Sep 24, 2025

zephyrbot assigned mbolivar Sep 24, 2025

henrikbrixandersen unassigned mbolivar Sep 24, 2025

GseoC reviewed Oct 3, 2025

View reviewed changes

pdgendt force-pushed the nvmem branch from b4ff7e7 to 473804d Compare October 3, 2025 14:14

zephyrbot requested a review from mbolivar October 3, 2025 14:16

henrikbrixandersen previously approved these changes Oct 5, 2025

View reviewed changes

henrikbrixandersen moved this from Todo to Done in Architecture Review Oct 6, 2025

nordicjm requested a review from de-nordic October 6, 2025 07:15

nordicjm reviewed Oct 6, 2025

View reviewed changes

pdgendt dismissed henrikbrixandersen’s stale review via fd0cb18 October 6, 2025 07:39

pdgendt force-pushed the nvmem branch from 473804d to fd0cb18 Compare October 6, 2025 07:39

talih0 and others added 8 commits October 6, 2025 19:37

dts: bindings: nvmem: Add fixed-layout

428891c

Add a devicetree binding to represent a fixed layout in an NVMEM provider. Signed-off-by: Pieter De Gendt <[email protected]>

nvmem: Introduce new subsystem for Non-Volatile Memory layer

0864f65

This commit adds the NVMEM subsystem with a basic implementation for use with EEPROM devices. Signed-off-by: Pieter De Gendt <[email protected]>

tests: nvmem: api: Add test suite for NVMEM API

042049e

Add basic testing to validate the API of the NVMEM subsystem. Add testing with an EEPROM backend. Signed-off-by: Pieter De Gendt <[email protected]>

tests: lib: devicetree: api: Add NVMEM test cases

df57757

Add test cases tot the devicetree API testsuite for NVMEM macros. Signed-off-by: Pieter De Gendt <[email protected]>

doc: services: Add NVMEM subsystem

e48d950

Introduce a page for the Non-Volatile Memory subsystem with a reference to the doxygen API. Signed-off-by: Pieter De Gendt <[email protected]>

doc: releases: 4.3: Add NVMEM entry

a9db680

Add an entry to the API and options section for the Non-Volatile Memory subsystem. Signed-off-by: Pieter De Gendt <[email protected]>

MAINTAINERS: Add area for NVMEM

ad94e5d

Create a section for the newly maintained NVMEM area. Signed-off-by: Pieter De Gendt <[email protected]>

pdgendt force-pushed the nvmem branch from fd0cb18 to ad94e5d Compare October 6, 2025 17:39

henrikbrixandersen approved these changes Oct 6, 2025

View reviewed changes

mbolivar approved these changes Oct 6, 2025

View reviewed changes

cfriedt merged commit 58b2153 into zephyrproject-rtos:main Oct 6, 2025
27 checks passed

pdgendt deleted the nvmem branch October 6, 2025 19:10

Add NVMEM support #96379

Add NVMEM support #96379

Conversation

pdgendt commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Laczen commented Sep 23, 2025

Uh oh!

pdgendt commented Sep 23, 2025

Uh oh!

pdgendt commented Sep 23, 2025

Uh oh!

decsny left a comment

Choose a reason for hiding this comment

Uh oh!

henrikbrixandersen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JarmouniA commented Oct 6, 2025

Uh oh!

sonarqubecloud bot commented Oct 6, 2025

Quality Gate passed

Uh oh!

henrikbrixandersen commented Oct 6, 2025

Uh oh!

pdgendt commented Oct 6, 2025

Uh oh!

nashif commented Oct 6, 2025

Uh oh!

mbolivar left a comment

Choose a reason for hiding this comment

Uh oh!

pdgendt commented Oct 6, 2025

Uh oh!

henrikbrixandersen commented Oct 6, 2025

Uh oh!

henrikbrixandersen commented Oct 6, 2025

Uh oh!

Uh oh!

Uh oh!

pdgendt commented Sep 22, 2025 •

edited

Loading