[PATCH v3 0/4] state: generic devicetree-overlay based state node injection

[PATCH v3 0/4] state: generic devicetree-overlay based state node injection

[chalianis1]

From: Chali Anis <chalianis1@gmail.com>

Boards that want a "barebox,state" node today have exactly one option:
carry it in their own, statically compiled-in devicetree source. That's
fine as long as barebox is built per-board with a maintained dts, but it
is a harder fit for targets that don't have one to begin with: the EFI
payload, deliberately meant to run unmodified across arbitrary
x86/arm64 EFI platforms barebox itself knows nothing about at build
time, and the generic BOARD_ARM_GENERIC_DT ("barebox-dt-2nd") image,
which picks up whatever devicetree a first-stage bootloader or QEMU
hands it in r2 at runtime the same way a Kernel would, rather than
being built against a particular board's dts. Either way there is no
single "board dts" being compiled for a state node to live in.

CONFIG_EXTERNAL_DTS_FRAGMENTS already covers a related need rather well:
an external build system can append dts fragment files to a board's dts
source at build time, scoped to specific boards via a per-dts
preprocessor macro. That remains the more direct choice whenever a
board's own dts is actually part of the build, and this series doesn't
propose changing that. It runs into the same limit as static dts
inclusion for the EFI payload and barebox-dt-2nd cases specifically,
though, since it operates at dts-source/build time on a particular
"main dts" - which neither target, by design, has one of.

This series instead proposes a devicetree *overlay* (.dtso, applied at
runtime via CONFIG_STATE_OVERLAY) for that gap. Applied to whichever
devicetree barebox already ends up live with by boot time - statically
compiled in, EFI-firmware-derived, passed in from a first-stage
bootloader, or the EFI payload's own minimal stub root - it only ever
adds one small node, so it doesn't need a "main dts" to attach to at
build time, and it doesn't need to know a board's memory map or other
devicetree content beyond one stable label (or, for EFI, just a
partition UUID, patch 1) to hook its backend into. In turn, that also
means it never competes with an existing devicetree for ownership,
which the one realistic alternative we considered - loading a full,
standalone state.dtb at runtime - does run into: barebox_register_of()
only accepts a new root if none is registered yet or the incoming tree
is empty, so a real state.dtb collides with whatever root the EFI
payload already registered at boot and is rejected with -EBUSY, and a
rejected tree's /aliases entries never reach the global alias cache
of_alias_get() relies on either.

Happy to discuss trade-offs here, in particular whether it's worth
teaching CONFIG_EXTERNAL_DTS_FRAGMENTS (or a variant of it) to handle
the no-base-dts case instead of adding a separate mechanism - this
series is meant as a concrete starting point for that conversation, not
a claim that overlays are the only reasonable answer.

Patch 1 makes of_state_fixup() able to resolve a partuuid-referenced,
non-hardware-backed backend node, and exports it so it can be called
directly. Patch 2 adds CONFIG_STATE_OVERLAY itself, compiling an
external .dtso into the barebox binary and applying it to the live
devicetree at postcore_initcall time - guarding against there being no
live devicetree yet, and refreshing the alias cache once applied. Patch
3 builds on both to publish the resolved state description as a UEFI
variable once such a node exists. Patch 4 makes both of those actually
reachable on x86: no code path there ever registered a live devicetree
root pre-boot to begin with, since that registration only existed for
the EFI_STUB entry point barebox uses on other architectures, not the
EFI_PAYLOAD one x86 uses.

Changes since v1:
- patch 1: fixed the compatible string on the synthesized fixed-partitions
  node ("fixed-partitions", not the barebox-internal
  "barebox,fixed-partitions" alias, which external consumers don't
  recognize), fixed a phandle collision where the synthesized node kept
  the phandle it had in barebox's own live devicetree instead of one
  scoped to the target tree, and resolved non-partuuid backends via the
  reproducible name cached at probe time again instead of recomputing it
  against whatever tree is being fixed up.
- patch 2: state_overlay_apply() now guards against there being no live
  devicetree yet and skips cleanly instead of calling into the overlay
  code with a NULL root, and calls of_alias_scan() afterward so the
  overlay's /aliases entry becomes visible the same way a live overlay
  applied via the interactive of_overlay command already does. Also
  selects CONFIG_OFDEVICE, needed for a live devicetree root to exist
  at all on some targets.
- patch 3: publish "BareboxState" under efi_barebox_vendor_guid instead
  of efi_systemd_vendor_guid - it's a barebox-defined variable, not part
  of the systemd-boot loader protocol. state_to_efivars_export() and
  efi_late_init() are both late_efi_initcall, and within one initcall
  level execution follows definition order in the object file, so
  state_to_efivars_export() is now defined after efi_late_init():
  on boards with no state node in their own static devicetree,
  efi_late_init() is what loads and registers the standalone state.dtb,
  and only once that has had a chance to run does state_by_alias() (used
  here instead of open-coding the equivalent of_find_node_by_alias() +
  state_by_node()) have anything to find.
- patch 4 is new: without it, CONFIG_STATE_OVERLAY silently never had a
  devicetree to apply to on x86, and this series' EFI-payload rationale
  didn't hold up for that architecture in practice.
- cover letter: called out BOARD_ARM_GENERIC_DT ("barebox-dt-2nd") as a
  second target that benefits from this alongside the EFI payload, since
  it's in the same "no main dts at build time" situation.

Tested on a Raspberry Pi CM4 natively, and as the EFI payload on a
Jetson Orin NX and under QEMU (x86, with a partuuid-referenced backend).

Chali Anis (4):
  state: make of_state_fixup() usable outside common/state/
  state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree
    overlay
  efi: payload: export resolved state as a BareboxState UEFI variable
  efi: payload: make CONFIG_STATE_OVERLAY (and BareboxState export) work
    on x86

 .../bindings/barebox/barebox,state.rst        |  9 +++
 Documentation/user/state.rst                  | 32 +++++++++
 common/Kconfig                                | 41 +++++++++++
 common/state/Makefile                         | 20 ++++++
 common/state/state.c                          | 72 +++++++++++++++----
 common/state/state_overlay.c                  | 29 ++++++++
 efi/payload/Makefile                          |  1 +
 efi/payload/init.c                            | 69 +++++++++++++++++-
 include/state.h                               |  5 ++
 9 files changed, 263 insertions(+), 15 deletions(-)
 create mode 100644 common/state/state_overlay.c

[PATCH v3 1/4] state: make of_state_fixup() usable outside common/state/

[chalianis1]

From: Chali Anis <chalianis1@gmail.com>

of_state_fixup() was static, callable only via of_register_fixup().
Export it so other subsystems can invoke it directly to render a
state instance's devicetree representation on demand, without going
through the global fixup-registration/of_fix_tree() machinery.

While exporting it, teach it to resolve backend nodes that are
top-level "barebox,fixed-partitions" subnodes carrying a partuuid
property instead of being tied to a real, already-probed storage
device node in the tree - the same globally-resolvable-by-UUID
binding drivers/of/of_path.c's of_cdev_find() already supports for
EFI, where devices aren't instantiated from devicetree. Without this,
of_state_fixup() could only find a backend reachable by walking real
hardware nodes already present in root, which such a partuuid-only
declaration never is.

Assisted-by: Claude Sonnet 5
Signed-off-by: Chali Anis <chalianis1@gmail.com>
---
 common/state/state.c | 72 ++++++++++++++++++++++++++++++++++++--------
 include/state.h      |  5 +++
 2 files changed, 64 insertions(+), 13 deletions(-)

diff --git a/common/state/state.c b/common/state/state.c
index b421b43da539..5de806b954e9 100644
--- a/common/state/state.c
+++ b/common/state/state.c
@@ -433,14 +433,69 @@ int state_from_node(struct state *state, struct device_node *node, bool create)
 	return ret;
 }
 
-static int of_state_fixup(struct device_node *root, void *ctx)
+static int state_get_backend(struct state *state, struct device_node *root, struct device_node *n)
+{
+	struct device_node *backend_node, *part, *state_root, *np;
+	const char *compatible = "fixed-partitions";
+	struct property *prop;
+	phandle phandle;
+	int ret;
+
+	state_root = of_find_node_by_path(state->of_path);
+	if (!state_root)
+		return -ENODEV;
+
+	backend_node = of_parse_phandle(state_root, "backend", 0);
+	if (!backend_node)
+		return -ENODEV;
+
+	if (of_node_is_fixed_partitions(of_get_parent(backend_node)) &&
+	    of_property_present(backend_node, "partuuid")) {
+		part = of_create_node(root, "/partitions");
+		if (!part)
+			return -ENOMEM;
+
+		prop = of_new_property(part, "compatible", compatible,
+					strlen(compatible) + 1);
+		if (!prop)
+			return -ENOMEM;
+
+		np = of_copy_node(part, backend_node);
+		if (!np)
+			return -ENOMEM;
+
+		/*
+		 * of_copy_node() carries over backend_node's phandle as-is,
+		 * but that phandle was allocated in barebox's own live
+		 * devicetree, a namespace independent of @root's. Assign a
+		 * fresh one scoped to @root instead, so it can't collide
+		 * with an unrelated node already using that value there.
+		 */
+		phandle = of_get_tree_max_phandle(root) + 1;
+		np->phandle = phandle;
+		ret = of_property_write_u32(np, "phandle", phandle);
+		if (ret)
+			return ret;
+
+		return of_property_write_u32(n, "backend", phandle);
+	}
+
+	backend_node = of_find_node_by_reproducible_name(root, state->backend_reproducible_name);
+	if (!backend_node)
+		return -ENODEV;
+
+	phandle = of_node_create_phandle(backend_node);
+
+	return of_property_write_u32(n, "backend", phandle);
+}
+
+int of_state_fixup(struct device_node *root, void *ctx)
 {
 	struct state *state = ctx;
 	const char *compatible = "barebox,state";
-	struct device_node *new_node, *node, *parent, *backend_node, *aliases;
+	struct device_node *new_node, *node, *parent, *aliases;
 	struct property *p;
 	int ret;
-	phandle phandle;
 
 	node = of_find_node_by_path_from(root, state->of_path);
 	if (node) {
@@ -498,16 +553,7 @@ static int of_state_fixup(struct device_node *root, void *ctx)
 		goto out;
 	}
 
-	/* backend phandle */
-	backend_node = of_find_node_by_reproducible_name(root,
-						state->backend_reproducible_name);
-	if (!backend_node) {
-		ret = -ENODEV;
-		goto out;
-	}
-
-	phandle = of_node_create_phandle(backend_node);
-	ret = of_property_write_u32(new_node, "backend", phandle);
+	ret = state_get_backend(state, root, new_node);
 	if (ret)
 		goto out;
 
diff --git a/include/state.h b/include/state.h
index 3daf82c0735f..d0034506f6e3 100644
--- a/include/state.h
+++ b/include/state.h
@@ -22,6 +22,7 @@ void state_info(void);
 
 int state_read_mac(struct state *state, const char *name, u8 *buf);
 
+int of_state_fixup(struct device_node *root, void *ctx);
 #else /* #if IS_ENABLED(CONFIG_STATE) */
 
 static inline struct state *state_new_from_node(struct device_node *node,
@@ -60,6 +61,10 @@ static inline int state_read_mac(struct state *state, const char *name, u8 *buf)
 	return -ENOSYS;
 }
 
+static inline int of_state_fixup(struct device_node *root, void *ctx)
+{
+	return -ENOSYS;
+}
 #endif /* #if IS_ENABLED(CONFIG_STATE) / #else */
 
 #define BAREBOX_STATE_PARTITION_GUID \

[PATCH v3 2/4] state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree overlay

[chalianis1]

From: Chali Anis <chalianis1@gmail.com>

Until now, a "barebox,state" node had to be part of a board's own,
statically compiled-in devicetree source. That's a hard requirement
for external build systems (Yocto, buildroot, ...) that want to add a
state layout without carrying a board-specific dts patch.

Add CONFIG_STATE_OVERLAY, which compiles an externally supplied
devicetree overlay (.dtso, pointed to by CONFIG_STATE_OVERLAY_DTS)
into the barebox binary and applies it to barebox's own live
devicetree at postcore_initcall time, mirroring how
CONFIG_EXTERNAL_DTS_FRAGMENTS already lets an external build system
inject plain dts fragments. Once applied, the resulting node is
picked up by the regular state probing like any statically defined
one. This selects CONFIG_OF_OVERLAY_LIVE, required so &label
references in the overlay (e.g. to an existing backend partition)
resolve against the base devicetree's __symbols__ node.

Not every target has a live devicetree by postcore_initcall time,
though, so guard against that explicitly and skip cleanly rather than
calling into the overlay code with a NULL root. Once applied, call
of_alias_scan() so the overlay's /aliases entry becomes visible the
same way a live overlay applied via the interactive of_overlay command
already does. Also select CONFIG_OFDEVICE: registering a live
devicetree root at all, on targets with no firmware-supplied one of
their own, depends on it.

Assisted-by: Claude Sonnet 5
Signed-off-by: Chali Anis <chalianis1@gmail.com>
---
 .../bindings/barebox/barebox,state.rst        |  9 ++++
 Documentation/user/state.rst                  | 32 +++++++++++++++
 common/Kconfig                                | 41 +++++++++++++++++++
 common/state/Makefile                         | 20 +++++++++
 common/state/state_overlay.c                  | 29 +++++++++++++
 5 files changed, 131 insertions(+)
 create mode 100644 common/state/state_overlay.c

diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst b/Documentation/devicetree/bindings/barebox/barebox,state.rst
index 390e148a2879..36b1d9acb038 100644
--- a/Documentation/devicetree/bindings/barebox/barebox,state.rst
+++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst
@@ -23,6 +23,15 @@ Required Properties
 * additionally a *state* node must have an alias in the ``/aliases`` node pointing
   to it.
 
+.. note:: A *state* node does not have to be part of the board's static
+   devicetree source. It can instead be added at runtime via a devicetree
+   overlay, see :ref:`CONFIG_STATE_OVERLAY <state_overlay>`. In that case,
+   the node referenced by ``backend`` must still exist in the board's own
+   devicetree source under a stable, well-known *label* (not merely an
+   ``/aliases`` entry), because overlay phandle resolution works by
+   resolving ``&label`` references against the base devicetree's
+   ``__symbols__`` node, which requires ``CONFIG_OF_OVERLAY_LIVE``.
+
 .. _barebox,state_magic:
 
 The ``magic`` property is a unique number which identifies the *state* variable
diff --git a/Documentation/user/state.rst b/Documentation/user/state.rst
index d97ba4e9f157..a03670dfa68e 100644
--- a/Documentation/user/state.rst
+++ b/Documentation/user/state.rst
@@ -759,6 +759,38 @@ content, its backend-type and *state* variable layout.
 		};
 	};
 
+.. _state_overlay:
+
+Devicetree Overlay based State Node
+------------------------------------
+
+Normally the *state* node is part of the board's own, statically compiled-in
+devicetree source. ``CONFIG_STATE_OVERLAY`` allows a *state* node to instead
+be added at runtime, via a devicetree overlay that is compiled into the
+barebox binary and applied to barebox's own live devicetree during boot.
+Once applied, the resulting node is picked up by the regular *state* probing
+just like a statically defined one, and is fixed up into whatever devicetree
+barebox eventually boots (internal or external), without requiring any
+board-specific code.
+
+This is primarily meant for use by an external build system (Yocto,
+buildroot, ...) that wants to inject a state layout without patching the
+board's dts: set ``CONFIG_STATE_OVERLAY=y`` and point
+``CONFIG_STATE_OVERLAY_DTS`` at the ``.dtso`` overlay file's path, similar to
+how ``CONFIG_EXTERNAL_DTS_FRAGMENTS`` works for regular dts fragments. As
+with that option, it's not intended to be set in barebox's own defconfig
+files.
+
+Because the overlay is applied to barebox's *live* devicetree, its
+``backend`` phandle can only resolve references to nodes that already exist
+in the board's own devicetree source, and only if that devicetree carries a
+``__symbols__`` node - i.e. ``CONFIG_OF_OVERLAY_LIVE`` must be enabled
+(``CONFIG_STATE_OVERLAY`` selects it automatically). This means the
+referenced backend node needs a stable, well-known *label* defined in the
+board's own devicetree source, not merely an ``/aliases`` entry - the
+overlay itself then only needs to add the *state* node and its alias,
+referencing that existing label.
+
 Frontend
 --------
 
diff --git a/common/Kconfig b/common/Kconfig
index 85df7f7daec6..abe7d100150c 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -1351,6 +1351,47 @@ config STATE_BACKWARD_COMPATIBLE
 	  compatibility with the state framework of barebox <= v2016.08.0. Newer
 	  revisions expect an additional 'meta header' and fail otherwise.
 
+config STATE_OVERLAY
+	bool "apply an external devicetree overlay to add a state node"
+	depends on STATE
+	select OF_OVERLAY
+	select OF_OVERLAY_LIVE
+	select OFDEVICE
+	help
+	  Compile an externally supplied devicetree overlay (.dtso) into the
+	  barebox binary and apply it to barebox's own live devicetree at
+	  boot, in order to add a "barebox,state" node (and its /aliases
+	  entry) that isn't part of the board's own compiled-in devicetree.
+
+	  This selects CONFIG_OF_OVERLAY_LIVE, required so the board's own
+	  built-in devicetree carries a __symbols__ node, needed to resolve
+	  &label references from the overlay back into the base devicetree
+	  (e.g. a reference to a backend partition already defined in the
+	  board's static dts).
+
+	  This also selects CONFIG_OFDEVICE: registering a live devicetree
+	  root at all, on targets with no firmware-supplied one of their
+	  own, depends on it.
+
+	  See CONFIG_STATE_OVERLAY_DTS to specify the overlay source file.
+
+config STATE_OVERLAY_DTS
+	string "external state overlay .dtso file"
+	depends on STATE_OVERLAY
+	help
+	  Path to a devicetree overlay source file (.dtso) that will be
+	  compiled and linked into the barebox image and applied to the
+	  live devicetree at boot to add a "barebox,state" node.
+
+	  As with CONFIG_EXTERNAL_DTS_FRAGMENTS, this is not intended to be
+	  put into Barebox's defconfig files. It's an external build
+	  system's job, like Yocto or buildroot, to inject a state overlay
+	  file from outside the Barebox source tree.
+
+	  Any backend node referenced from the overlay via &label must
+	  already exist in the board's own devicetree source, under a
+	  stable, well-known label (not merely an /aliases entry).
+
 config BOOTCHOOSER
 	bool "bootchooser infrastructure"
 	select BOOT
diff --git a/common/state/Makefile b/common/state/Makefile
index 93215dd06921..a906c66a0747 100644
--- a/common/state/Makefile
+++ b/common/state/Makefile
@@ -7,3 +7,23 @@ obj-y += backend_format_raw.o
 obj-y += backend_storage.o
 obj-y += backend_bucket_direct.o
 obj-$(CONFIG_MTD) += backend_bucket_circular.o
+
+# External state devicetree overlay
+# ---------------------------------------------------------------------------
+state-overlay-dts := $(call remove_quotes,$(CONFIG_STATE_OVERLAY_DTS))
+
+ifdef CONFIG_STATE_OVERLAY
+ifeq ($(state-overlay-dts),)
+$(error CONFIG_STATE_OVERLAY is enabled but CONFIG_STATE_OVERLAY_DTS is empty)
+endif
+ifeq ($(wildcard $(state-overlay-dts)),)
+$(error CONFIG_STATE_OVERLAY_DTS="$(state-overlay-dts)" does not exist)
+endif
+
+obj-y += state_overlay.o state-overlay.dtbo.o
+
+$(obj)/state-overlay.dtbo: $(state-overlay-dts) $(DTC) FORCE
+	$(call if_changed_dep,dtc)
+endif
+
+clean-files += *.dtbo *.dtbo.S .*.dtso
diff --git a/common/state/state_overlay.c b/common/state/state_overlay.c
new file mode 100644
index 000000000000..b3f68eaea4b2
--- /dev/null
+++ b/common/state/state_overlay.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <common.h>
+#include <init.h>
+#include <of.h>
+#include <linux/err.h>
+
+extern char __dtbo_state_overlay_start[];
+
+static int state_overlay_apply(void)
+{
+	struct device_node *root = of_get_root_node();
+	int ret;
+
+	if (!root) {
+		pr_err("no live devicetree yet, skipping state overlay\n");
+		return 0;
+	}
+
+	ret = of_overlay_apply_dtbo(root, __dtbo_state_overlay_start);
+	if (ret) {
+		pr_err("failed to apply state overlay: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+
+	of_alias_scan();
+
+	return 0;
+}
+postcore_initcall(state_overlay_apply);

[PATCH v3 3/4] efi: payload: export resolved state as a BareboxState UEFI variable

[chalianis1]

From: Chali Anis <chalianis1@gmail.com>

When a "barebox,state" node is already reachable via barebox's live
devicetree (statically compiled in, or injected by
CONFIG_STATE_OVERLAY), render its fully resolved description - backend
phandle included - with of_state_fixup() and publish it as a
"BareboxState" UEFI variable, so an OS-side consumer can locate the
state layout without needing a separate state.dtb file on the ESP.

state_to_efivars_export() and efi_late_init() are both late_efi_initcall,
and within one initcall level, execution follows definition order in the
object file, so state_to_efivars_export() must be defined after
efi_late_init(): on boards with no state node in their own static
devicetree, efi_late_init() is what loads and registers
/boot/EFI/barebox/state.dtb, and only once that has had a chance to run
does state_by_alias() have anything to find. Defined the other way
around, state_to_efivars_export() would always run first and never see
a state.dtb efi_late_init() had not loaded yet - it would only have
happened to work when CONFIG_STATE_OVERLAY had already registered the
node much earlier, at postcore_initcall, a narrower case than the
state.dtb fallback efi_late_init() exists to support.

Look the state instance up via the state_by_alias() helper
(common/state/state.c) rather than open-coding the equivalent
of_find_node_by_alias() + state_by_node(). This also means state not
being set up yet is just a clean no-op, rather than the -ENODEV that
open-coded version returned, which would've been logged as an initcall
failure for what is an entirely ordinary condition.

Assisted-by: Claude Sonnet 5
Signed-off-by: Chali Anis <chalianis1@gmail.com>
---
 efi/payload/init.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/efi/payload/init.c b/efi/payload/init.c
index f0ce2a82cefc..cdb73afffa2c 100644
--- a/efi/payload/init.c
+++ b/efi/payload/init.c
@@ -287,7 +287,6 @@ core_efi_initcall(efi_register_firmware_nodes_fixup);
 #define EFI_LOADER_FEATURE_SECUREBOOT_ENROLL       (1LL << 11)
 #define EFI_LOADER_FEATURE_RETAIN_SHIM             (1LL << 12)
 
-
 static int efi_postcore_init(void)
 {
 	const struct efi_device_path *parent_image_dp, *loaded_image_dp;
@@ -404,6 +403,56 @@ static int efi_late_init(void)
 }
 late_efi_initcall(efi_late_init);
 
+/*
+ * Must run after efi_late_init(): on boards with no state node compiled
+ * into their own devicetree, efi_late_init() is what loads and registers
+ * /boot/EFI/barebox/state.dtb (or, on CONFIG_STATE_OVERLAY targets, that
+ * already happened much earlier). Only once that has had a chance to run
+ * does state_by_alias() have anything to find here.
+ */
+static int state_to_efivars_export(void)
+{
+	struct device_node *np;
+	struct state *state;
+	void *fdt;
+	size_t size;
+	int ret;
+
+	if (!IS_ENABLED(CONFIG_STATE))
+		return 0;
+
+	state = state_by_alias("state");
+	if (!state)
+		return 0;
+
+	np = of_new_node(NULL, NULL);
+	if (!np)
+		return -ENOMEM;
+
+	ret = of_state_fixup(np, state);
+	if (ret)
+		goto out;
+
+	fdt = of_flatten_dtb(np);
+	if (!fdt) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	size = fdt_totalsize(fdt);
+
+	efi_set_variable("BareboxState", &efi_barebox_vendor_guid,
+			  EFI_VARIABLE_BOOTSERVICE_ACCESS |
+			  EFI_VARIABLE_RUNTIME_ACCESS,
+			  fdt, size);
+
+	free(fdt);
+	ret = 0;
+out:
+	of_delete_node(np);
+	return ret;
+}
+late_efi_initcall(state_to_efivars_export);
 static int do_efiexit(int argc, char *argv[])
 {
 	if (!BS)

[PATCH v3 4/4] efi: payload: make CONFIG_STATE_OVERLAY (and BareboxState export) work on x86

[chalianis1]

From: Chali Anis <chalianis1@gmail.com>

barebox_register_of() - the only thing that ever registers a live
devicetree root pre-boot on x86 EFI - lived in boarddata.c, which was
compiled solely for CONFIG_EFI_STUB (the chain-loaded/ARM handoff-data
entry point). x86 uses CONFIG_EFI_PAYLOAD (entry-single.c's standalone
efi_main()), so no code ever called it there: of_get_root_node() stayed
NULL for the entire pre-boot sequence. That's what state_overlay_apply()
(CONFIG_STATE_OVERLAY's postcore_initcall) and state_to_efivars_export()
(the BareboxState UEFI variable export) both rely on, so neither ever
had anything to work with on x86. Compile boarddata.o for
CONFIG_EFI_PAYLOAD too - efi_register_of() only needs BS, which
entry-single.c's efi_main() already sets before any initcall runs, and
handle_efi_boarddata() already no-ops cleanly when there is no PBL
handoff data, the normal case for this entry point.

On x86, actually binding a struct state to the node CONFIG_STATE_OVERLAY
adds still needs a fresh of_probe() pass: barebox_register_of() already
ran one, before the overlay added anything, and the next one needs to
happen later still than state_overlay_apply()'s own postcore_initcall,
too - PCI/SATA enumeration (and thus the disk cdevs a partuuid-based
state backend resolves against) only completes well after that point.
Add efi_devices_probe() at device_efi_initcall to cover it.

Finally, now that a state node reachable via CONFIG_STATE_OVERLAY is
something x86 can actually end up with pre-boot, add efi_late_init()'s
"skip loading the standalone state.dtb whenever a 'state' alias is
already present" check - it's only meaningful once that can happen.

Tested on QEMU as the EFI payload with a partuuid-referenced backend.

Assisted-by: Claude Sonnet 5
Signed-off-by: Chali Anis <chalianis1@gmail.com>
---
 efi/payload/Makefile |  1 +
 efi/payload/init.c   | 18 +++++++++++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/efi/payload/Makefile b/efi/payload/Makefile
index 6306540ab595..f8b19428a99c 100644
--- a/efi/payload/Makefile
+++ b/efi/payload/Makefile
@@ -11,3 +11,4 @@ obj-pbl-$(CONFIG_EFI_PAYLOAD) += early-mem.o
 obj-$(CONFIG_EFI_PAYLOAD) += entry-single.o
 pbl-$(CONFIG_EFI_STUB) += entry-multi.o
 obj-$(CONFIG_EFI_STUB) += boarddata.o
+obj-$(CONFIG_EFI_PAYLOAD) += boarddata.o
diff --git a/efi/payload/init.c b/efi/payload/init.c
index cdb73afffa2c..e644ec60bb87 100644
--- a/efi/payload/init.c
+++ b/efi/payload/init.c
@@ -355,7 +355,7 @@ static int efi_late_init(void)
 	void *fdt;
 	int ret;
 
-	if (!IS_ENABLED(CONFIG_STATE))
+	if (!IS_ENABLED(CONFIG_STATE) || of_find_node_by_alias(NULL, "state"))
 		return 0;
 
 	if (!get_mounted_path("/boot")) {
@@ -453,6 +453,22 @@ static int state_to_efivars_export(void)
 	return ret;
 }
 late_efi_initcall(state_to_efivars_export);
+
+/*
+ * On x86, PCI/SATA enumeration (and thus the disk cdevs a partuuid-based
+ * state backend resolves against) only completes well after the one
+ * of_probe() pass barebox_register_of() already did, before the state
+ * overlay even added its node. Re-probe once devices have actually shown
+ * up, so such a backend can still bind.
+ */
+static int __maybe_unused efi_devices_probe(void)
+{
+	return of_probe();
+}
+#if IS_ENABLED(CONFIG_X86)
+device_efi_initcall(efi_devices_probe);
+#endif
+
 static int do_efiexit(int argc, char *argv[])
 {
 	if (!BS)

Re: [PATCH v3 0/4] state: generic devicetree-overlay based state node injection

[Ahmad Fatoum]

Hi,

On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> From: Chali Anis <chalianis1@gmail.com>
> 
> Boards that want a "barebox,state" node today have exactly one option:
> carry it in their own, statically compiled-in devicetree source. That's
> fine as long as barebox is built per-board with a maintained dts, but it
> is a harder fit for targets that don't have one to begin with: the EFI
> payload, deliberately meant to run unmodified across arbitrary
> x86/arm64 EFI platforms barebox itself knows nothing about at build
> time, and the generic BOARD_ARM_GENERIC_DT ("barebox-dt-2nd") image,
> which picks up whatever devicetree a first-stage bootloader or QEMU
> hands it in r2 at runtime the same way a Kernel would, rather than
> being built against a particular board's dts. Either way there is no
> single "board dts" being compiled for a state node to live in.

We indeed have nothing for the barebox-dt-2nd.img case, but this image
is meant to be used with a *barebox* device tree, not some random DT
that may use bindings barebox isn't compatible with.

This is intentionally narrower than what the kernel supports: The kernel
will keep supporting old bindings, but barebox will only support the
bindings it ships with.

With that background, barebox-dt-2nd.img should never be called with
some random DT that's not matched to what barebox expects and thus we
can expect that if someone wants a barebox state node they would add it.

As for QEMU, barebox already ships state overlays for it, but these are
built-in and applied early-on.

> 
> CONFIG_EXTERNAL_DTS_FRAGMENTS already covers a related need rather well:
> an external build system can append dts fragment files to a board's dts
> source at build time, scoped to specific boards via a per-dts
> preprocessor macro. That remains the more direct choice whenever a
> board's own dts is actually part of the build, and this series doesn't
> propose changing that. It runs into the same limit as static dts
> inclusion for the EFI payload

As mentioned on IRC, this is a limitation that can be fixed and not some
deliberate choice.

> and barebox-dt-2nd cases specifically,

As elaborated above, I have my reservations about starting barebox with
arbitrary DTs.

> though, since it operates at dts-source/build time on a particular
> "main dts" - which neither target, by design, has one of.

As the EFI payload needs the DT for nothing apart of state, we could
also ship an empty DT and make that extensible via fragments.

FYI, there was discussion when fragments were first added if they should
be overlays instead:

https://lore.barebox.org/barebox/CAMHeXxPZ9on3rZu92H1EeNQj79rUFBRbs5Qre=AS3U7_y=UueQ@mail.gmail.com/

> This series instead proposes a devicetree *overlay* (.dtso, applied at
> runtime via CONFIG_STATE_OVERLAY) for that gap. Applied to whichever
> devicetree barebox already ends up live with by boot time - statically
> compiled in, EFI-firmware-derived, passed in from a first-stage
> bootloader, or the EFI payload's own minimal stub root - it only ever
> adds one small node, so it doesn't need a "main dts" to attach to at
> build time, and it doesn't need to know a board's memory map or other
> devicetree content beyond one stable label (or, for EFI, just a
> partition UUID, patch 1) to hook its backend into.

If we were to allow supplying external overlays at build time that are
applied at runtime, why make it specific to only state?

Also to be a truly generic solution, we need some accounting for
multi-image (what if your build produces both a rpi3 and a rpi4 image
and you want different overlays for each?).

> In turn, that also
> means it never competes with an existing devicetree for ownership,
> which the one realistic alternative we considered - loading a full,
> standalone state.dtb at runtime - does run into: barebox_register_of()
> only accepts a new root if none is registered yet or the incoming tree
> is empty,

It only accepting empty state.dtbs is a bug! It's fixed on master now
though (and in the latest release).

> so a real state.dtb collides with whatever root the EFI
> payload already registered at boot and is rejected with -EBUSY, and a
> rejected tree's /aliases entries never reach the global alias cache
> of_alias_get() relies on either.

This argumentation follows from a bug, so it doesn't say anything to the
merit of this new feature.

> Happy to discuss trade-offs here, in particular whether it's worth
> teaching CONFIG_EXTERNAL_DTS_FRAGMENTS (or a variant of it) to handle
> the no-base-dts case instead of adding a separate mechanism - this
> series is meant as a concrete starting point for that conversation, not
> a claim that overlays are the only reasonable answer.

I appreciate you putting in the effort. As mentioned on IRC, I am in
favor of extending fragments as it meshes with what we already have, but
I agree overlays can cover use cases that fragments don't (while
overlays as implemented here can't cover all users that fragments provide).

> Patch 1 makes of_state_fixup() able to resolve a partuuid-referenced,
> non-hardware-backed backend node, and exports it so it can be called
> directly. Patch 2 adds CONFIG_STATE_OVERLAY itself, compiling an
> external .dtso into the barebox binary and applying it to the live
> devicetree at postcore_initcall time - guarding against there being no
> live devicetree yet, and refreshing the alias cache once applied. Patch
> 3 builds on both to publish the resolved state description as a UEFI
> variable once such a node exists. Patch 4 makes both of those actually
> reachable on x86: no code path there ever registered a live devicetree
> root pre-boot to begin with, since that registration only existed for
> the EFI_STUB entry point barebox uses on other architectures, not the
> EFI_PAYLOAD one x86 uses.


No need to recount the patch commit messages here. If at all, just
include a general description in the cover letter. This mail is already
very verbose, which makes following it a bit hard for me.
> 
> Changes since v1:
> - patch 1: fixed the compatible string on the synthesized fixed-partitions
>   node ("fixed-partitions", not the barebox-internal
>   "barebox,fixed-partitions" alias, which external consumers don't
>   recognize), fixed a phandle collision where the synthesized node kept
>   the phandle it had in barebox's own live devicetree instead of one
>   scoped to the target tree, and resolved non-partuuid backends via the
>   reproducible name cached at probe time again instead of recomputing it
>   against whatever tree is being fixed up.
> - patch 2: state_overlay_apply() now guards against there being no live
>   devicetree yet and skips cleanly instead of calling into the overlay
>   code with a NULL root, and calls of_alias_scan() afterward so the
>   overlay's /aliases entry becomes visible the same way a live overlay
>   applied via the interactive of_overlay command already does. Also
>   selects CONFIG_OFDEVICE, needed for a live devicetree root to exist
>   at all on some targets.
> - patch 3: publish "BareboxState" under efi_barebox_vendor_guid instead
>   of efi_systemd_vendor_guid - it's a barebox-defined variable, not part
>   of the systemd-boot loader protocol. state_to_efivars_export() and
>   efi_late_init() are both late_efi_initcall, and within one initcall
>   level execution follows definition order in the object file, so
>   state_to_efivars_export() is now defined after efi_late_init():
>   on boards with no state node in their own static devicetree,
>   efi_late_init() is what loads and registers the standalone state.dtb,
>   and only once that has had a chance to run does state_by_alias() (used
>   here instead of open-coding the equivalent of_find_node_by_alias() +
>   state_by_node()) have anything to find.
> - patch 4 is new: without it, CONFIG_STATE_OVERLAY silently never had a
>   devicetree to apply to on x86, and this series' EFI-payload rationale
>   didn't hold up for that architecture in practice.
> - cover letter: called out BOARD_ARM_GENERIC_DT ("barebox-dt-2nd") as a
>   second target that benefits from this alongside the EFI payload, since
>   it's in the same "no main dts at build time" situation.

I haven't checked out the earlier versions, so I will just gloss over this.

> Tested on a Raspberry Pi CM4 natively, and as the EFI payload on a
> Jetson Orin NX and under QEMU (x86, with a partuuid-referenced backend).

Thanks. This is useful info.

> 
> Chali Anis (4):
>   state: make of_state_fixup() usable outside common/state/
>   state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree
>     overlay
>   efi: payload: export resolved state as a BareboxState UEFI variable
>   efi: payload: make CONFIG_STATE_OVERLAY (and BareboxState export) work
>     on x86
> 
>  .../bindings/barebox/barebox,state.rst        |  9 +++
>  Documentation/user/state.rst                  | 32 +++++++++
>  common/Kconfig                                | 41 +++++++++++
>  common/state/Makefile                         | 20 ++++++
>  common/state/state.c                          | 72 +++++++++++++++----
>  common/state/state_overlay.c                  | 29 ++++++++
>  efi/payload/Makefile                          |  1 +
>  efi/payload/init.c                            | 69 +++++++++++++++++-
>  include/state.h                               |  5 ++
>  9 files changed, 263 insertions(+), 15 deletions(-)
>  create mode 100644 common/state/state_overlay.c
> 
> 


Cheers,
Ahmad



-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 2/4] state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree overlay

[Ahmad Fatoum]

Hi,

On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> From: Chali Anis <chalianis1@gmail.com>
> 
> Until now, a "barebox,state" node had to be part of a board's own,
> statically compiled-in devicetree source. That's a hard requirement
> for external build systems (Yocto, buildroot, ...) that want to add a
> state layout without carrying a board-specific dts patch.

or externally in the ESP.

> Add CONFIG_STATE_OVERLAY, which compiles an externally supplied
> devicetree overlay (.dtso, pointed to by CONFIG_STATE_OVERLAY_DTS)

Why two options?

> into the barebox binary and applies it to barebox's own live
> devicetree at postcore_initcall time, mirroring how
> CONFIG_EXTERNAL_DTS_FRAGMENTS already lets an external build system
> inject plain dts fragments. Once applied, the resulting node is
> picked up by the regular state probing like any statically defined
> one. This selects CONFIG_OF_OVERLAY_LIVE, required so &label
> references in the overlay (e.g. to an existing backend partition)
> resolve against the base devicetree's __symbols__ node.

The cover letter mentions QEMU and board-dt-2nd as benefiting from this,
but OF_OVERLAY_LIVE helps neither of them as the DT comes from outside
barebox.

> Not every target has a live devicetree by postcore_initcall time,
> though, so guard against that explicitly and skip cleanly rather than
> calling into the overlay code with a NULL root. Once applied, call
> of_alias_scan() so the overlay's /aliases entry becomes visible the
> same way a live overlay applied via the interactive of_overlay command
> already does. Also select CONFIG_OFDEVICE: registering a live
> devicetree root at all, on targets with no firmware-supplied one of
> their own, depends on it.

OFDEVICE is not really meant to be selected by generic features, rather
generic features should depend on it if they need it. Architectures /
Platforms are wgi should select OFDEVICE if they want to probe OF devices.

> 
> Assisted-by: Claude Sonnet 5
> Signed-off-by: Chali Anis <chalianis1@gmail.com>
> ---
>  .../bindings/barebox/barebox,state.rst        |  9 ++++
>  Documentation/user/state.rst                  | 32 +++++++++++++++
>  common/Kconfig                                | 41 +++++++++++++++++++
>  common/state/Makefile                         | 20 +++++++++
>  common/state/state_overlay.c                  | 29 +++++++++++++
>  5 files changed, 131 insertions(+)
>  create mode 100644 common/state/state_overlay.c
> 
> diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst b/Documentation/devicetree/bindings/barebox/barebox,state.rst
> index 390e148a2879..36b1d9acb038 100644
> --- a/Documentation/devicetree/bindings/barebox/barebox,state.rst
> +++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst
> @@ -23,6 +23,15 @@ Required Properties
>  * additionally a *state* node must have an alias in the ``/aliases`` node pointing
>    to it.
>  
> +.. note:: A *state* node does not have to be part of the board's static
> +   devicetree source. It can instead be added at runtime via a devicetree
> +   overlay, see :ref:`CONFIG_STATE_OVERLAY <state_overlay>`. In that case,
> +   the node referenced by ``backend`` must still exist in the board's own
> +   devicetree source under a stable, well-known *label* (not merely an
> +   ``/aliases`` entry), because overlay phandle resolution works by
> +   resolving ``&label`` references against the base devicetree's
> +   ``__symbols__`` node, which requires ``CONFIG_OF_OVERLAY_LIVE``.

As mentioned above, this is not enough. If it's an external DT,
CONFIG_OF_OVERLAY_LIVE won't help.

> +
>  .. _barebox,state_magic:
>  
>  The ``magic`` property is a unique number which identifies the *state* variable
> diff --git a/Documentation/user/state.rst b/Documentation/user/state.rst
> index d97ba4e9f157..a03670dfa68e 100644
> --- a/Documentation/user/state.rst
> +++ b/Documentation/user/state.rst
> @@ -759,6 +759,38 @@ content, its backend-type and *state* variable layout.
>  		};
>  	};
>  
> +.. _state_overlay:
> +
> +Devicetree Overlay based State Node
> +------------------------------------
> +
> +Normally the *state* node is part of the board's own, statically compiled-in
> +devicetree source. ``CONFIG_STATE_OVERLAY`` allows a *state* node to instead
> +be added at runtime, via a devicetree overlay that is compiled into the
> +barebox binary and applied to barebox's own live devicetree during boot.
> +Once applied, the resulting node is picked up by the regular *state* probing
> +just like a statically defined one, and is fixed up into whatever devicetree
> +barebox eventually boots (internal or external), without requiring any
> +board-specific code.
> +
> +This is primarily meant for use by an external build system (Yocto,
> +buildroot, ...) that wants to inject a state layout without patching the
> +board's dts: set ``CONFIG_STATE_OVERLAY=y`` and point
> +``CONFIG_STATE_OVERLAY_DTS`` at the ``.dtso`` overlay file's path, similar to
> +how ``CONFIG_EXTERNAL_DTS_FRAGMENTS`` works for regular dts fragments. As
> +with that option, it's not intended to be set in barebox's own defconfig
> +files.
> +
> +Because the overlay is applied to barebox's *live* devicetree, its
> +``backend`` phandle can only resolve references to nodes that already exist
> +in the board's own devicetree source, and only if that devicetree carries a
> +``__symbols__`` node - i.e. ``CONFIG_OF_OVERLAY_LIVE`` must be enabled
> +(``CONFIG_STATE_OVERLAY`` selects it automatically). This means the
> +referenced backend node needs a stable, well-known *label* defined in the
> +board's own devicetree source, not merely an ``/aliases`` entry - the
> +overlay itself then only needs to add the *state* node and its alias,
> +referencing that existing label.

Thanks for including docs.

> +
>  Frontend
>  --------
>  
> diff --git a/common/Kconfig b/common/Kconfig
> index 85df7f7daec6..abe7d100150c 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -1351,6 +1351,47 @@ config STATE_BACKWARD_COMPATIBLE
>  	  compatibility with the state framework of barebox <= v2016.08.0. Newer
>  	  revisions expect an additional 'meta header' and fail otherwise.
>  
> +config STATE_OVERLAY
> +	bool "apply an external devicetree overlay to add a state node"
> +	depends on STATE
> +	select OF_OVERLAY
> +	select OF_OVERLAY_LIVE
> +	select OFDEVICE
> +	help
> +	  Compile an externally supplied devicetree overlay (.dtso) into the
> +	  barebox binary and apply it to barebox's own live devicetree at
> +	  boot, in order to add a "barebox,state" node (and its /aliases
> +	  entry) that isn't part of the board's own compiled-in devicetree.
> +
> +	  This selects CONFIG_OF_OVERLAY_LIVE, required so the board's own
> +	  built-in devicetree carries a __symbols__ node, needed to resolve
> +	  &label references from the overlay back into the base devicetree
> +	  (e.g. a reference to a backend partition already defined in the
> +	  board's static dts).
> +
> +	  This also selects CONFIG_OFDEVICE: registering a live devicetree
> +	  root at all, on targets with no firmware-supplied one of their
> +	  own, depends on it.
> +
> +	  See CONFIG_STATE_OVERLAY_DTS to specify the overlay source file.

As mentioned above, unclear to me why we need two options.

> +
> +config STATE_OVERLAY_DTS
> +	string "external state overlay .dtso file"
> +	depends on STATE_OVERLAY
> +	help
> +	  Path to a devicetree overlay source file (.dtso) that will be
> +	  compiled and linked into the barebox image and applied to the
> +	  live devicetree at boot to add a "barebox,state" node.
> +
> +	  As with CONFIG_EXTERNAL_DTS_FRAGMENTS, this is not intended to be
> +	  put into Barebox's defconfig files. It's an external build
> +	  system's job, like Yocto or buildroot, to inject a state overlay
> +	  file from outside the Barebox source tree.
> +
> +	  Any backend node referenced from the overlay via &label must
> +	  already exist in the board's own devicetree source, under a
> +	  stable, well-known label (not merely an /aliases entry).



> +
>  config BOOTCHOOSER
>  	bool "bootchooser infrastructure"
>  	select BOOT
> diff --git a/common/state/Makefile b/common/state/Makefile
> index 93215dd06921..a906c66a0747 100644
> --- a/common/state/Makefile
> +++ b/common/state/Makefile
> @@ -7,3 +7,23 @@ obj-y += backend_format_raw.o
>  obj-y += backend_storage.o
>  obj-y += backend_bucket_direct.o
>  obj-$(CONFIG_MTD) += backend_bucket_circular.o
> +
> +# External state devicetree overlay
> +# ---------------------------------------------------------------------------
> +state-overlay-dts := $(call remove_quotes,$(CONFIG_STATE_OVERLAY_DTS))
> +
> +ifdef CONFIG_STATE_OVERLAY
> +ifeq ($(state-overlay-dts),)
> +$(error CONFIG_STATE_OVERLAY is enabled but CONFIG_STATE_OVERLAY_DTS is empty)
> +endif
> +ifeq ($(wildcard $(state-overlay-dts)),)
> +$(error CONFIG_STATE_OVERLAY_DTS="$(state-overlay-dts)" does not exist)
> +endif
> +
> +obj-y += state_overlay.o state-overlay.dtbo.o
> +
> +$(obj)/state-overlay.dtbo: $(state-overlay-dts) $(DTC) FORCE
> +	$(call if_changed_dep,dtc)
> +endif
> +
> +clean-files += *.dtbo *.dtbo.S .*.dtso
> diff --git a/common/state/state_overlay.c b/common/state/state_overlay.c
> new file mode 100644
> index 000000000000..b3f68eaea4b2
> --- /dev/null
> +++ b/common/state/state_overlay.c
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <common.h>
> +#include <init.h>
> +#include <of.h>
> +#include <linux/err.h>
> +
> +extern char __dtbo_state_overlay_start[];
> +
> +static int state_overlay_apply(void)
> +{
> +	struct device_node *root = of_get_root_node();
> +	int ret;
> +
> +	if (!root) {
> +		pr_err("no live devicetree yet, skipping state overlay\n");
> +		return 0;
> +	}
> +
> +	ret = of_overlay_apply_dtbo(root, __dtbo_state_overlay_start);
> +	if (ret) {
> +		pr_err("failed to apply state overlay: %pe\n", ERR_PTR(ret));
> +		return ret;
> +	}
> +
> +	of_alias_scan();
> +
> +	return 0;
> +}
> +postcore_initcall(state_overlay_apply);

This can be used to apply arbitrary overlay content, so the option name
should probably not be state specific.

Cheers,
Ahmad

> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 1/4] state: make of_state_fixup() usable outside common/state/

[Ahmad Fatoum]

Hi,

On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> From: Chali Anis <chalianis1@gmail.com>
> 
> of_state_fixup() was static, callable only via of_register_fixup().
> Export it so other subsystems can invoke it directly to render a
> state instance's devicetree representation on demand, without going
> through the global fixup-registration/of_fix_tree() machinery.

I guess I will see later what this is needed for.

> 
> While exporting it, teach it to resolve backend nodes that are
> top-level "barebox,fixed-partitions" subnodes carrying a partuuid
> property instead of being tied to a real, already-probed storage
> device node in the tree - the same globally-resolvable-by-UUID
> binding drivers/of/of_path.c's of_cdev_find() already supports for
> EFI, where devices aren't instantiated from devicetree. Without this,
> of_state_fixup() could only find a backend reachable by walking real
> hardware nodes already present in root, which such a partuuid-only
> declaration never is.

of_fixup_partitions() already takes care of fixing up partitions into
the kernel DT. If it doesn't work for your use case here, it should
perhaps be adapted instead.

I haven't reviewed the code, because I am unsure why this is needed and
the commit message didn't really explain.

Cheers,
Ahmad

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 3/4] efi: payload: export resolved state as a BareboxState UEFI variable

[Ahmad Fatoum]

Hi,

On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> From: Chali Anis <chalianis1@gmail.com>
> 
> When a "barebox,state" node is already reachable via barebox's live
> devicetree (statically compiled in, or injected by
> CONFIG_STATE_OVERLAY), render its fully resolved description - backend
> phandle included - with of_state_fixup() and publish it as a
> "BareboxState" UEFI variable, so an OS-side consumer can locate the
> state layout without needing a separate state.dtb file on the ESP.

Why not pass along the whole barebox DT? For EFI payloads, that's
effectively the state and the backend already and in case we gain more
content in future, it will just be passed along as well.

> 
> state_to_efivars_export() and efi_late_init() are both late_efi_initcall,
> and within one initcall level, execution follows definition order in the
> object file, so state_to_efivars_export() must be defined after
> efi_late_init(): on boards with no state node in their own static
> devicetree, efi_late_init() is what loads and registers
> /boot/EFI/barebox/state.dtb, and only once that has had a chance to run
> does state_by_alias() have anything to find. Defined the other way
> around, state_to_efivars_export() would always run first and never see
> a state.dtb efi_late_init() had not loaded yet - it would only have
> happened to work when CONFIG_STATE_OVERLAY had already registered the
> node much earlier, at postcore_initcall, a narrower case than the
> state.dtb fallback efi_late_init() exists to support.
> 
> Look the state instance up via the state_by_alias() helper
> (common/state/state.c) rather than open-coding the equivalent
> of_find_node_by_alias() + state_by_node(). This also means state not
> being set up yet is just a clean no-op, rather than the -ENODEV that
> open-coded version returned, which would've been logged as an initcall
> failure for what is an entirely ordinary condition.
> 
> Assisted-by: Claude Sonnet 5
> Signed-off-by: Chali Anis <chalianis1@gmail.com>
> ---
>  efi/payload/init.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/efi/payload/init.c b/efi/payload/init.c
> index f0ce2a82cefc..cdb73afffa2c 100644
> --- a/efi/payload/init.c
> +++ b/efi/payload/init.c
> @@ -287,7 +287,6 @@ core_efi_initcall(efi_register_firmware_nodes_fixup);
>  #define EFI_LOADER_FEATURE_SECUREBOOT_ENROLL       (1LL << 11)
>  #define EFI_LOADER_FEATURE_RETAIN_SHIM             (1LL << 12)
>  
> -
>  static int efi_postcore_init(void)
>  {
>  	const struct efi_device_path *parent_image_dp, *loaded_image_dp;
> @@ -404,6 +403,56 @@ static int efi_late_init(void)
>  }
>  late_efi_initcall(efi_late_init);
>  
> +/*
> + * Must run after efi_late_init(): on boards with no state node compiled
> + * into their own devicetree, efi_late_init() is what loads and registers
> + * /boot/EFI/barebox/state.dtb (or, on CONFIG_STATE_OVERLAY targets, that
> + * already happened much earlier). Only once that has had a chance to run
> + * does state_by_alias() have anything to find here.
> + */
> +static int state_to_efivars_export(void)
> +{
> +	struct device_node *np;
> +	struct state *state;
> +	void *fdt;
> +	size_t size;
> +	int ret;
> +
> +	if (!IS_ENABLED(CONFIG_STATE))
> +		return 0;
> +
> +	state = state_by_alias("state");
> +	if (!state)
> +		return 0;
> +
> +	np = of_new_node(NULL, NULL);
> +	if (!np)
> +		return -ENOMEM;
> +
> +	ret = of_state_fixup(np, state);
> +	if (ret)
> +		goto out;
> +
> +	fdt = of_flatten_dtb(np);
> +	if (!fdt) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	size = fdt_totalsize(fdt);
> +
> +	efi_set_variable("BareboxState", &efi_barebox_vendor_guid,
> +			  EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +			  EFI_VARIABLE_RUNTIME_ACCESS,
> +			  fdt, size);
> +
> +	free(fdt);
> +	ret = 0;
> +out:
> +	of_delete_node(np);
> +	return ret;
> +}
> +late_efi_initcall(state_to_efivars_export);
>  static int do_efiexit(int argc, char *argv[])
>  {
>  	if (!BS)
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 4/4] efi: payload: make CONFIG_STATE_OVERLAY (and BareboxState export) work on x86

[Ahmad Fatoum]

On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> From: Chali Anis <chalianis1@gmail.com>
> 
> barebox_register_of() - the only thing that ever registers a live
> devicetree root pre-boot on x86 EFI - lived in boarddata.c, which was
> compiled solely for CONFIG_EFI_STUB (the chain-loaded/ARM handoff-data
> entry point). x86 uses CONFIG_EFI_PAYLOAD (entry-single.c's standalone
> efi_main()), so no code ever called it there: of_get_root_node() stayed
> NULL for the entire pre-boot sequence. That's what state_overlay_apply()
> (CONFIG_STATE_OVERLAY's postcore_initcall) and state_to_efivars_export()
> (the BareboxState UEFI variable export) both rely on, so neither ever
> had anything to work with on x86. Compile boarddata.o for
> CONFIG_EFI_PAYLOAD too - efi_register_of() only needs BS, which
> entry-single.c's efi_main() already sets before any initcall runs, and
> handle_efi_boarddata() already no-ops cleanly when there is no PBL
> handoff data, the normal case for this entry point.
> 
> On x86, actually binding a struct state to the node CONFIG_STATE_OVERLAY
> adds still needs a fresh of_probe() pass: barebox_register_of() already
> ran one, before the overlay added anything, and the next one needs to
> happen later still than state_overlay_apply()'s own postcore_initcall,
> too - PCI/SATA enumeration (and thus the disk cdevs a partuuid-based
> state backend resolves against) only completes well after that point.
> Add efi_devices_probe() at device_efi_initcall to cover it.
> 
> Finally, now that a state node reachable via CONFIG_STATE_OVERLAY is
> something x86 can actually end up with pre-boot, add efi_late_init()'s
> "skip loading the standalone state.dtb whenever a 'state' alias is
> already present" check - it's only meaningful once that can happen.
> 
> Tested on QEMU as the EFI payload with a partuuid-referenced backend.
> 
> Assisted-by: Claude Sonnet 5
> Signed-off-by: Chali Anis <chalianis1@gmail.com>
> ---
>  efi/payload/Makefile |  1 +
>  efi/payload/init.c   | 18 +++++++++++++++++-
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/efi/payload/Makefile b/efi/payload/Makefile
> index 6306540ab595..f8b19428a99c 100644
> --- a/efi/payload/Makefile
> +++ b/efi/payload/Makefile
> @@ -11,3 +11,4 @@ obj-pbl-$(CONFIG_EFI_PAYLOAD) += early-mem.o
>  obj-$(CONFIG_EFI_PAYLOAD) += entry-single.o
>  pbl-$(CONFIG_EFI_STUB) += entry-multi.o
>  obj-$(CONFIG_EFI_STUB) += boarddata.o
> +obj-$(CONFIG_EFI_PAYLOAD) += boarddata.o
> diff --git a/efi/payload/init.c b/efi/payload/init.c
> index cdb73afffa2c..e644ec60bb87 100644
> --- a/efi/payload/init.c
> +++ b/efi/payload/init.c
> @@ -355,7 +355,7 @@ static int efi_late_init(void)
>  	void *fdt;
>  	int ret;
>  
> -	if (!IS_ENABLED(CONFIG_STATE))
> +	if (!IS_ENABLED(CONFIG_STATE) || of_find_node_by_alias(NULL, "state"))
>  		return 0;
>  
>  	if (!get_mounted_path("/boot")) {
> @@ -453,6 +453,22 @@ static int state_to_efivars_export(void)
>  	return ret;
>  }
>  late_efi_initcall(state_to_efivars_export);
> +
> +/*
> + * On x86, PCI/SATA enumeration (and thus the disk cdevs a partuuid-based
> + * state backend resolves against) only completes well after the one
> + * of_probe() pass barebox_register_of() already did, before the state
> + * overlay even added its node. Re-probe once devices have actually shown
> + * up, so such a backend can still bind.
> + */

This comment makes no sense. Block devices we boot from under EFI are
usually EFI block devices. We don't have PCI/SATA drivers even in barebox.


> +static int __maybe_unused efi_devices_probe(void)
> +{
> +	return of_probe();
> +}
> +#if IS_ENABLED(CONFIG_X86)
> +device_efi_initcall(efi_devices_probe);
> +#endif
> +
>  static int do_efiexit(int argc, char *argv[])
>  {
>  	if (!BS)
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 0/4] state: generic devicetree-overlay based state node injection

[Ahmad Fatoum]

Hi,

On 8/25/26 5:02 PM, Ahmad Fatoum wrote:
> On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
>> so a real state.dtb collides with whatever root the EFI
>> payload already registered at boot and is rejected with -EBUSY, and a
>> rejected tree's /aliases entries never reach the global alias cache
>> of_alias_get() relies on either.
> 
> This argumentation follows from a bug, so it doesn't say anything to the
> merit of this new feature.

I have now read through the series and my thoughts are that applying
overlays to the barebox live tree from outside can be useful (I wouldn't
limit it to state), but:

- it needs better argumentation what it allows that is not feasible with
fragments
- it needs some way to account for multi-image

I am going to send out my EFI-payload-state-via-fragment series soon and
I am interested to hear your thoughts on it.

Thanks,
Ahmad

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 0/4] state: generic devicetree-overlay based state node injection

[anis chali]

On Tue, Aug 25, 2026 at 05:02:40PM +0200, Ahmad Fatoum wrote:
Hi,

> Hi,
>
> On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> > From: Chali Anis <chalianis1@gmail.com>
> >
> > Boards that want a "barebox,state" node today have exactly one option:
> > carry it in their own, statically compiled-in devicetree source. That's
> > fine as long as barebox is built per-board with a maintained dts, but it
> > is a harder fit for targets that don't have one to begin with: the EFI
> > payload, deliberately meant to run unmodified across arbitrary
> > x86/arm64 EFI platforms barebox itself knows nothing about at build
> > time, and the generic BOARD_ARM_GENERIC_DT ("barebox-dt-2nd") image,
> > which picks up whatever devicetree a first-stage bootloader or QEMU
> > hands it in r2 at runtime the same way a Kernel would, rather than
> > being built against a particular board's dts. Either way there is no
> > single "board dts" being compiled for a state node to live in.
>
> We indeed have nothing for the barebox-dt-2nd.img case, but this image
> is meant to be used with a *barebox* device tree, not some random DT
> that may use bindings barebox isn't compatible with.
>
> This is intentionally narrower than what the kernel supports: The kernel
> will keep supporting old bindings, but barebox will only support the
> bindings it ships with.
>
> With that background, barebox-dt-2nd.img should never be called with
> some random DT that's not matched to what barebox expects and thus we
> can expect that if someone wants a barebox state node they would add it.

The state overlay doesn't resolve against "a random DT" — it's applied via a
fixup that doesn't need to know which exact DT or platform actually booted,
works against whatever supported board's DT, just one that isn't available
at build time to compile against.

> As for QEMU, barebox already ships state overlays for it, but these are
> built-in and applied early-on.
>
> >
> > CONFIG_EXTERNAL_DTS_FRAGMENTS already covers a related need rather well:
> > an external build system can append dts fragment files to a board's dts
> > source at build time, scoped to specific boards via a per-dts
> > preprocessor macro. That remains the more direct choice whenever a
> > board's own dts is actually part of the build, and this series doesn't
> > propose changing that. It runs into the same limit as static dts
> > inclusion for the EFI payload
>
> As mentioned on IRC, this is a limitation that can be fixed and not some
> deliberate choice.
>
> > and barebox-dt-2nd cases specifically,
>
> As elaborated above, I have my reservations about starting barebox with
> arbitrary DTs.

Arbitrary DTs will not work anyway if the SOC at least not supported.

> > though, since it operates at dts-source/build time on a particular
> > "main dts" - which neither target, by design, has one of.
>
> As the EFI payload needs the DT for nothing apart of state, we could
> also ship an empty DT and make that extensible via fragments.

Yes in the case of EFI, both fragments and overlays has the same result
since we use a partuuid to declare the state partition

> FYI, there was discussion when fragments were first added if they should
> be overlays instead:
>
> https://lore.barebox.org/barebox/CAMHeXxPZ9on3rZu92H1EeNQj79rUFBRbs5Qre=AS3U7_y=UueQ@mail.gmail.com/
>
> > This series instead proposes a devicetree *overlay* (.dtso, applied at
> > runtime via CONFIG_STATE_OVERLAY) for that gap. Applied to whichever
> > devicetree barebox already ends up live with by boot time - statically
> > compiled in, EFI-firmware-derived, passed in from a first-stage
> > bootloader, or the EFI payload's own minimal stub root - it only ever
> > adds one small node, so it doesn't need a "main dts" to attach to at
> > build time, and it doesn't need to know a board's memory map or other
> > devicetree content beyond one stable label (or, for EFI, just a
> > partition UUID, patch 1) to hook its backend into.
>
> If we were to allow supplying external overlays at build time that are
> applied at runtime, why make it specific to only state?

making it specific to state overlay is cleaner in my opinion. we can support
other overlays, this patches does not prevent them

> Also to be a truly generic solution, we need some accounting for
> multi-image (what if your build produces both a rpi3 and a rpi4 image
> and you want different overlays for each?).

a multi image will apply the same overlay which seems to be a limitation
some people, for my case I run 5 products on the exact same stack which
reduces support for me once something is fixed in one platform automaticly
the others will benefet from it.

> > In turn, that also
> > means it never competes with an existing devicetree for ownership,
> > which the one realistic alternative we considered - loading a full,
> > standalone state.dtb at runtime - does run into: barebox_register_of()
> > only accepts a new root if none is registered yet or the incoming tree
> > is empty,
>
> It only accepting empty state.dtbs is a bug! It's fixed on master now
> though (and in the latest release).

okay.

> > so a real state.dtb collides with whatever root the EFI
> > payload already registered at boot and is rejected with -EBUSY, and a
> > rejected tree's /aliases entries never reach the global alias cache
> > of_alias_get() relies on either.
>
> This argumentation follows from a bug, so it doesn't say anything to the
> merit of this new feature.

The solutions or feature might come from bugs otherwise why changing things
if they are already perfect.

> > Happy to discuss trade-offs here, in particular whether it's worth
> > teaching CONFIG_EXTERNAL_DTS_FRAGMENTS (or a variant of it) to handle
> > the no-base-dts case instead of adding a separate mechanism - this
> > series is meant as a concrete starting point for that conversation, not
> > a claim that overlays are the only reasonable answer.
>
> I appreciate you putting in the effort. As mentioned on IRC, I am in
> favor of extending fragments as it meshes with what we already have, but
> I agree overlays can cover use cases that fragments don't (while
> overlays as implemented here can't cover all users that fragments provide).

as I said one feature not prevent the other, but anyway If fragments solve
most cases and permits to embbed  the state to barebox without having a separate
file or patching a given internal dts file or maintaining whole dts
separatly, in
side it will be fine.

> > Patch 1 makes of_state_fixup() able to resolve a partuuid-referenced,
> > non-hardware-backed backend node, and exports it so it can be called
> > directly. Patch 2 adds CONFIG_STATE_OVERLAY itself, compiling an
> > external .dtso into the barebox binary and applying it to the live
> > devicetree at postcore_initcall time - guarding against there being no
> > live devicetree yet, and refreshing the alias cache once applied. Patch
> > 3 builds on both to publish the resolved state description as a UEFI
> > variable once such a node exists. Patch 4 makes both of those actually
> > reachable on x86: no code path there ever registered a live devicetree
> > root pre-boot to begin with, since that registration only existed for
> > the EFI_STUB entry point barebox uses on other architectures, not the
> > EFI_PAYLOAD one x86 uses.
>
>
> No need to recount the patch commit messages here. If at all, just
> include a general description in the cover letter. This mail is already
> very verbose, which makes following it a bit hard for me.
Sorry claude authoring.

> >
> > Changes since v1:
> > - patch 1: fixed the compatible string on the synthesized fixed-partitions
> >   node ("fixed-partitions", not the barebox-internal
> >   "barebox,fixed-partitions" alias, which external consumers don't
> >   recognize), fixed a phandle collision where the synthesized node kept
> >   the phandle it had in barebox's own live devicetree instead of one
> >   scoped to the target tree, and resolved non-partuuid backends via the
> >   reproducible name cached at probe time again instead of recomputing it
> >   against whatever tree is being fixed up.
> > - patch 2: state_overlay_apply() now guards against there being no live
> >   devicetree yet and skips cleanly instead of calling into the overlay
> >   code with a NULL root, and calls of_alias_scan() afterward so the
> >   overlay's /aliases entry becomes visible the same way a live overlay
> >   applied via the interactive of_overlay command already does. Also
> >   selects CONFIG_OFDEVICE, needed for a live devicetree root to exist
> >   at all on some targets.
> > - patch 3: publish "BareboxState" under efi_barebox_vendor_guid instead
> >   of efi_systemd_vendor_guid - it's a barebox-defined variable, not part
> >   of the systemd-boot loader protocol. state_to_efivars_export() and
> >   efi_late_init() are both late_efi_initcall, and within one initcall
> >   level execution follows definition order in the object file, so
> >   state_to_efivars_export() is now defined after efi_late_init():
> >   on boards with no state node in their own static devicetree,
> >   efi_late_init() is what loads and registers the standalone state.dtb,
> >   and only once that has had a chance to run does state_by_alias() (used
> >   here instead of open-coding the equivalent of_find_node_by_alias() +
> >   state_by_node()) have anything to find.
> > - patch 4 is new: without it, CONFIG_STATE_OVERLAY silently never had a
> >   devicetree to apply to on x86, and this series' EFI-payload rationale
> >   didn't hold up for that architecture in practice.
> > - cover letter: called out BOARD_ARM_GENERIC_DT ("barebox-dt-2nd") as a
> >   second target that benefits from this alongside the EFI payload, since
> >   it's in the same "no main dts at build time" situation.
>
> I haven't checked out the earlier versions, so I will just gloss over this.
>
> > Tested on a Raspberry Pi CM4 natively, and as the EFI payload on a
> > Jetson Orin NX and under QEMU (x86, with a partuuid-referenced backend).
>
> Thanks. This is useful info.
>
> >
> > Chali Anis (4):
> >   state: make of_state_fixup() usable outside common/state/
> >   state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree
> >     overlay
> >   efi: payload: export resolved state as a BareboxState UEFI variable
> >   efi: payload: make CONFIG_STATE_OVERLAY (and BareboxState export) work
> >     on x86
> >
> >  .../bindings/barebox/barebox,state.rst        |  9 +++
> >  Documentation/user/state.rst                  | 32 +++++++++
> >  common/Kconfig                                | 41 +++++++++++
> >  common/state/Makefile                         | 20 ++++++
> >  common/state/state.c                          | 72 +++++++++++++++----
> >  common/state/state_overlay.c                  | 29 ++++++++
> >  efi/payload/Makefile                          |  1 +
> >  efi/payload/init.c                            | 69 +++++++++++++++++-
> >  include/state.h                               |  5 ++
> >  9 files changed, 263 insertions(+), 15 deletions(-)
> >  create mode 100644 common/state/state_overlay.c
> >
> >
>
>
> Cheers,
> Ahmad
>
>
>
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
>
>
>
Best regards.
Anis

Re: [PATCH v3 0/4] state: generic devicetree-overlay based state node injection

[anis chali]

Hi
Le mar. 25 août 2026 à 19:10, Ahmad Fatoum <a.fatoum@pengutronix.de> a écrit :
>
> Hi,
>
> On 8/25/26 5:02 PM, Ahmad Fatoum wrote:
> > On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> >> so a real state.dtb collides with whatever root the EFI
> >> payload already registered at boot and is rejected with -EBUSY, and a
> >> rejected tree's /aliases entries never reach the global alias cache
> >> of_alias_get() relies on either.
> >
> > This argumentation follows from a bug, so it doesn't say anything to the
> > merit of this new feature.
>
> I have now read through the series and my thoughts are that applying
> overlays to the barebox live tree from outside can be useful (I wouldn't
> limit it to state), but:
Ack, and if we have overlays we can apply whatever we want (state, other things)
it more useful than the state, because it permits to add more stuff
and permits to
address state and more.

> - it needs better argumentation what it allows that is not feasible with
> fragments
> - it needs some way to account for multi-image
Yes, agreed. One approach could be to use a global label, or
alternatively scan all
barebox state partitions and check for a tag that matches the
corresponding state
fragment or overlay. The matching backend partition would then be used.

> I am going to send out my EFI-payload-state-via-fragment series soon and
> I am interested to hear your thoughts on it.
>
> Thanks,
> Ahmad
>
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
>

Re: [PATCH v3 3/4] efi: payload: export resolved state as a BareboxState UEFI variable

[anis chali]

Hi,

Le mar. 25 août 2026 à 19:04, Ahmad Fatoum <a.fatoum@pengutronix.de> a écrit :
>
> Hi,
>
> On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> > From: Chali Anis <chalianis1@gmail.com>
> >
> > When a "barebox,state" node is already reachable via barebox's live
> > devicetree (statically compiled in, or injected by
> > CONFIG_STATE_OVERLAY), render its fully resolved description - backend
> > phandle included - with of_state_fixup() and publish it as a
> > "BareboxState" UEFI variable, so an OS-side consumer can locate the
> > state layout without needing a separate state.dtb file on the ESP.
>
> Why not pass along the whole barebox DT? For EFI payloads, that's
> effectively the state and the backend already and in case we gain more
> content in future, it will just be passed along as well.
I understand, so we should call the efivar BareboxDT-XXXXX ??
or If we keep the variable name BareboxState and pass the entire device tree,
going forward we would only support state definitions within the barebox DT
in efi payloads???

> >
> > state_to_efivars_export() and efi_late_init() are both late_efi_initcall,
> > and within one initcall level, execution follows definition order in the
> > object file, so state_to_efivars_export() must be defined after
> > efi_late_init(): on boards with no state node in their own static
> > devicetree, efi_late_init() is what loads and registers
> > /boot/EFI/barebox/state.dtb, and only once that has had a chance to run
> > does state_by_alias() have anything to find. Defined the other way
> > around, state_to_efivars_export() would always run first and never see
> > a state.dtb efi_late_init() had not loaded yet - it would only have
> > happened to work when CONFIG_STATE_OVERLAY had already registered the
> > node much earlier, at postcore_initcall, a narrower case than the
> > state.dtb fallback efi_late_init() exists to support.
> >
> > Look the state instance up via the state_by_alias() helper
> > (common/state/state.c) rather than open-coding the equivalent
> > of_find_node_by_alias() + state_by_node(). This also means state not
> > being set up yet is just a clean no-op, rather than the -ENODEV that
> > open-coded version returned, which would've been logged as an initcall
> > failure for what is an entirely ordinary condition.
> >
> > Assisted-by: Claude Sonnet 5
> > Signed-off-by: Chali Anis <chalianis1@gmail.com>
> > ---
> >  efi/payload/init.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-
> >  1 file changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/efi/payload/init.c b/efi/payload/init.c
> > index f0ce2a82cefc..cdb73afffa2c 100644
> > --- a/efi/payload/init.c
> > +++ b/efi/payload/init.c
> > @@ -287,7 +287,6 @@ core_efi_initcall(efi_register_firmware_nodes_fixup);
> >  #define EFI_LOADER_FEATURE_SECUREBOOT_ENROLL       (1LL << 11)
> >  #define EFI_LOADER_FEATURE_RETAIN_SHIM             (1LL << 12)
> >
> > -
> >  static int efi_postcore_init(void)
> >  {
> >       const struct efi_device_path *parent_image_dp, *loaded_image_dp;
> > @@ -404,6 +403,56 @@ static int efi_late_init(void)
> >  }
> >  late_efi_initcall(efi_late_init);
> >
> > +/*
> > + * Must run after efi_late_init(): on boards with no state node compiled
> > + * into their own devicetree, efi_late_init() is what loads and registers
> > + * /boot/EFI/barebox/state.dtb (or, on CONFIG_STATE_OVERLAY targets, that
> > + * already happened much earlier). Only once that has had a chance to run
> > + * does state_by_alias() have anything to find here.
> > + */
> > +static int state_to_efivars_export(void)
> > +{
> > +     struct device_node *np;
> > +     struct state *state;
> > +     void *fdt;
> > +     size_t size;
> > +     int ret;
> > +
> > +     if (!IS_ENABLED(CONFIG_STATE))
> > +             return 0;
> > +
> > +     state = state_by_alias("state");
> > +     if (!state)
> > +             return 0;
> > +
> > +     np = of_new_node(NULL, NULL);
> > +     if (!np)
> > +             return -ENOMEM;
> > +
> > +     ret = of_state_fixup(np, state);
> > +     if (ret)
> > +             goto out;
> > +
> > +     fdt = of_flatten_dtb(np);
> > +     if (!fdt) {
> > +             ret = -ENOMEM;
> > +             goto out;
> > +     }
> > +
> > +     size = fdt_totalsize(fdt);
> > +
> > +     efi_set_variable("BareboxState", &efi_barebox_vendor_guid,
> > +                       EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +                       EFI_VARIABLE_RUNTIME_ACCESS,
> > +                       fdt, size);
> > +
> > +     free(fdt);
> > +     ret = 0;
> > +out:
> > +     of_delete_node(np);
> > +     return ret;
> > +}
> > +late_efi_initcall(state_to_efivars_export);
> >  static int do_efiexit(int argc, char *argv[])
> >  {
> >       if (!BS)
> >
>
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
>

best regards.
Anis

Re: [PATCH v3 1/4] state: make of_state_fixup() usable outside common/state/

[anis chali]

Hi,

Le mar. 25 août 2026 à 19:00, Ahmad Fatoum <a.fatoum@pengutronix.de> a écrit :
>
> Hi,
>
> On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> > From: Chali Anis <chalianis1@gmail.com>
> >
> > of_state_fixup() was static, callable only via of_register_fixup().
> > Export it so other subsystems can invoke it directly to render a
> > state instance's devicetree representation on demand, without going
> > through the global fixup-registration/of_fix_tree() machinery.
>
> I guess I will see later what this is needed for.
>
> >
> > While exporting it, teach it to resolve backend nodes that are
> > top-level "barebox,fixed-partitions" subnodes carrying a partuuid
> > property instead of being tied to a real, already-probed storage
> > device node in the tree - the same globally-resolvable-by-UUID
> > binding drivers/of/of_path.c's of_cdev_find() already supports for
> > EFI, where devices aren't instantiated from devicetree. Without this,
> > of_state_fixup() could only find a backend reachable by walking real
> > hardware nodes already present in root, which such a partuuid-only
> > declaration never is.
>
> of_fixup_partitions() already takes care of fixing up partitions into
> the kernel DT. If it doesn't work for your use case here, it should
> perhaps be adapted instead.
>
I'm not sure, I the of_fixup_partitions does not take care of partitions defined
by their partuuid, the reproductible name does not find the partition
in the kernel
device tree as for a real mmc or spi memory where there reg and ranges to build
that string.
>
> I haven't reviewed the code, because I am unsure why this is needed and
> the commit message didn't really explain.
>
Maybe give it a try and see!
> Cheers,
> Ahmad

best regards.
Anis.
>
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
>

Re: [PATCH v3 2/4] state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree overlay

[anis chali]

Hi,

Le mar. 25 août 2026 à 18:57, Ahmad Fatoum <a.fatoum@pengutronix.de> a écrit :
>
> Hi,
>
> On 8/25/26 5:05 AM, chalianis1@gmail.com wrote:
> > From: Chali Anis <chalianis1@gmail.com>
> >
> > Until now, a "barebox,state" node had to be part of a board's own,
> > statically compiled-in devicetree source. That's a hard requirement
> > for external build systems (Yocto, buildroot, ...) that want to add a
> > state layout without carrying a board-specific dts patch.
>
> or externally in the ESP.
>
> > Add CONFIG_STATE_OVERLAY, which compiles an externally supplied
> > devicetree overlay (.dtso, pointed to by CONFIG_STATE_OVERLAY_DTS)
>
> Why two options?
it could be one option.

> > into the barebox binary and applies it to barebox's own live
> > devicetree at postcore_initcall time, mirroring how
> > CONFIG_EXTERNAL_DTS_FRAGMENTS already lets an external build system
> > inject plain dts fragments. Once applied, the resulting node is
> > picked up by the regular state probing like any statically defined
> > one. This selects CONFIG_OF_OVERLAY_LIVE, required so &label
> > references in the overlay (e.g. to an existing backend partition)
> > resolve against the base devicetree's __symbols__ node.
>
> The cover letter mentions QEMU and board-dt-2nd as benefiting from this,
> but OF_OVERLAY_LIVE helps neither of them as the DT comes from outside
> barebox.
>
> > Not every target has a live devicetree by postcore_initcall time,
> > though, so guard against that explicitly and skip cleanly rather than
> > calling into the overlay code with a NULL root. Once applied, call
> > of_alias_scan() so the overlay's /aliases entry becomes visible the
> > same way a live overlay applied via the interactive of_overlay command
> > already does. Also select CONFIG_OFDEVICE: registering a live
> > devicetree root at all, on targets with no firmware-supplied one of
> > their own, depends on it.
>
> OFDEVICE is not really meant to be selected by generic features, rather
> generic features should depend on it if they need it. Architectures /
> Platforms are wgi should select OFDEVICE if they want to probe OF devices.
>
> >
> > Assisted-by: Claude Sonnet 5
> > Signed-off-by: Chali Anis <chalianis1@gmail.com>
> > ---
> >  .../bindings/barebox/barebox,state.rst        |  9 ++++
> >  Documentation/user/state.rst                  | 32 +++++++++++++++
> >  common/Kconfig                                | 41 +++++++++++++++++++
> >  common/state/Makefile                         | 20 +++++++++
> >  common/state/state_overlay.c                  | 29 +++++++++++++
> >  5 files changed, 131 insertions(+)
> >  create mode 100644 common/state/state_overlay.c
> >
> > diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst b/Documentation/devicetree/bindings/barebox/barebox,state.rst
> > index 390e148a2879..36b1d9acb038 100644
> > --- a/Documentation/devicetree/bindings/barebox/barebox,state.rst
> > +++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst
> > @@ -23,6 +23,15 @@ Required Properties
> >  * additionally a *state* node must have an alias in the ``/aliases`` node pointing
> >    to it.
> >
> > +.. note:: A *state* node does not have to be part of the board's static
> > +   devicetree source. It can instead be added at runtime via a devicetree
> > +   overlay, see :ref:`CONFIG_STATE_OVERLAY <state_overlay>`. In that case,
> > +   the node referenced by ``backend`` must still exist in the board's own
> > +   devicetree source under a stable, well-known *label* (not merely an
> > +   ``/aliases`` entry), because overlay phandle resolution works by
> > +   resolving ``&label`` references against the base devicetree's
> > +   ``__symbols__`` node, which requires ``CONFIG_OF_OVERLAY_LIVE``.
>
> As mentioned above, this is not enough. If it's an external DT,
> CONFIG_OF_OVERLAY_LIVE won't help.
>
> > +
> >  .. _barebox,state_magic:
> >
> >  The ``magic`` property is a unique number which identifies the *state* variable
> > diff --git a/Documentation/user/state.rst b/Documentation/user/state.rst
> > index d97ba4e9f157..a03670dfa68e 100644
> > --- a/Documentation/user/state.rst
> > +++ b/Documentation/user/state.rst
> > @@ -759,6 +759,38 @@ content, its backend-type and *state* variable layout.
> >               };
> >       };
> >
> > +.. _state_overlay:
> > +
> > +Devicetree Overlay based State Node
> > +------------------------------------
> > +
> > +Normally the *state* node is part of the board's own, statically compiled-in
> > +devicetree source. ``CONFIG_STATE_OVERLAY`` allows a *state* node to instead
> > +be added at runtime, via a devicetree overlay that is compiled into the
> > +barebox binary and applied to barebox's own live devicetree during boot.
> > +Once applied, the resulting node is picked up by the regular *state* probing
> > +just like a statically defined one, and is fixed up into whatever devicetree
> > +barebox eventually boots (internal or external), without requiring any
> > +board-specific code.
> > +
> > +This is primarily meant for use by an external build system (Yocto,
> > +buildroot, ...) that wants to inject a state layout without patching the
> > +board's dts: set ``CONFIG_STATE_OVERLAY=y`` and point
> > +``CONFIG_STATE_OVERLAY_DTS`` at the ``.dtso`` overlay file's path, similar to
> > +how ``CONFIG_EXTERNAL_DTS_FRAGMENTS`` works for regular dts fragments. As
> > +with that option, it's not intended to be set in barebox's own defconfig
> > +files.
> > +
> > +Because the overlay is applied to barebox's *live* devicetree, its
> > +``backend`` phandle can only resolve references to nodes that already exist
> > +in the board's own devicetree source, and only if that devicetree carries a
> > +``__symbols__`` node - i.e. ``CONFIG_OF_OVERLAY_LIVE`` must be enabled
> > +(``CONFIG_STATE_OVERLAY`` selects it automatically). This means the
> > +referenced backend node needs a stable, well-known *label* defined in the
> > +board's own devicetree source, not merely an ``/aliases`` entry - the
> > +overlay itself then only needs to add the *state* node and its alias,
> > +referencing that existing label.
>
> Thanks for including docs.
>
> > +
> >  Frontend
> >  --------
> >
> > diff --git a/common/Kconfig b/common/Kconfig
> > index 85df7f7daec6..abe7d100150c 100644
> > --- a/common/Kconfig
> > +++ b/common/Kconfig
> > @@ -1351,6 +1351,47 @@ config STATE_BACKWARD_COMPATIBLE
> >         compatibility with the state framework of barebox <= v2016.08.0. Newer
> >         revisions expect an additional 'meta header' and fail otherwise.
> >
> > +config STATE_OVERLAY
> > +     bool "apply an external devicetree overlay to add a state node"
> > +     depends on STATE
> > +     select OF_OVERLAY
> > +     select OF_OVERLAY_LIVE
> > +     select OFDEVICE
> > +     help
> > +       Compile an externally supplied devicetree overlay (.dtso) into the
> > +       barebox binary and apply it to barebox's own live devicetree at
> > +       boot, in order to add a "barebox,state" node (and its /aliases
> > +       entry) that isn't part of the board's own compiled-in devicetree.
> > +
> > +       This selects CONFIG_OF_OVERLAY_LIVE, required so the board's own
> > +       built-in devicetree carries a __symbols__ node, needed to resolve
> > +       &label references from the overlay back into the base devicetree
> > +       (e.g. a reference to a backend partition already defined in the
> > +       board's static dts).
> > +
> > +       This also selects CONFIG_OFDEVICE: registering a live devicetree
> > +       root at all, on targets with no firmware-supplied one of their
> > +       own, depends on it.
> > +
> > +       See CONFIG_STATE_OVERLAY_DTS to specify the overlay source file.
>
> As mentioned above, unclear to me why we need two options.
>
> > +
> > +config STATE_OVERLAY_DTS
> > +     string "external state overlay .dtso file"
> > +     depends on STATE_OVERLAY
> > +     help
> > +       Path to a devicetree overlay source file (.dtso) that will be
> > +       compiled and linked into the barebox image and applied to the
> > +       live devicetree at boot to add a "barebox,state" node.
> > +
> > +       As with CONFIG_EXTERNAL_DTS_FRAGMENTS, this is not intended to be
> > +       put into Barebox's defconfig files. It's an external build
> > +       system's job, like Yocto or buildroot, to inject a state overlay
> > +       file from outside the Barebox source tree.
> > +
> > +       Any backend node referenced from the overlay via &label must
> > +       already exist in the board's own devicetree source, under a
> > +       stable, well-known label (not merely an /aliases entry).
>
>
>
> > +
> >  config BOOTCHOOSER
> >       bool "bootchooser infrastructure"
> >       select BOOT
> > diff --git a/common/state/Makefile b/common/state/Makefile
> > index 93215dd06921..a906c66a0747 100644
> > --- a/common/state/Makefile
> > +++ b/common/state/Makefile
> > @@ -7,3 +7,23 @@ obj-y += backend_format_raw.o
> >  obj-y += backend_storage.o
> >  obj-y += backend_bucket_direct.o
> >  obj-$(CONFIG_MTD) += backend_bucket_circular.o
> > +
> > +# External state devicetree overlay
> > +# ---------------------------------------------------------------------------
> > +state-overlay-dts := $(call remove_quotes,$(CONFIG_STATE_OVERLAY_DTS))
> > +
> > +ifdef CONFIG_STATE_OVERLAY
> > +ifeq ($(state-overlay-dts),)
> > +$(error CONFIG_STATE_OVERLAY is enabled but CONFIG_STATE_OVERLAY_DTS is empty)
> > +endif
> > +ifeq ($(wildcard $(state-overlay-dts)),)
> > +$(error CONFIG_STATE_OVERLAY_DTS="$(state-overlay-dts)" does not exist)
> > +endif
> > +
> > +obj-y += state_overlay.o state-overlay.dtbo.o
> > +
> > +$(obj)/state-overlay.dtbo: $(state-overlay-dts) $(DTC) FORCE
> > +     $(call if_changed_dep,dtc)
> > +endif
> > +
> > +clean-files += *.dtbo *.dtbo.S .*.dtso
> > diff --git a/common/state/state_overlay.c b/common/state/state_overlay.c
> > new file mode 100644
> > index 000000000000..b3f68eaea4b2
> > --- /dev/null
> > +++ b/common/state/state_overlay.c
> > @@ -0,0 +1,29 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +#include <common.h>
> > +#include <init.h>
> > +#include <of.h>
> > +#include <linux/err.h>
> > +
> > +extern char __dtbo_state_overlay_start[];
> > +
> > +static int state_overlay_apply(void)
> > +{
> > +     struct device_node *root = of_get_root_node();
> > +     int ret;
> > +
> > +     if (!root) {
> > +             pr_err("no live devicetree yet, skipping state overlay\n");
> > +             return 0;
> > +     }
> > +
> > +     ret = of_overlay_apply_dtbo(root, __dtbo_state_overlay_start);
> > +     if (ret) {
> > +             pr_err("failed to apply state overlay: %pe\n", ERR_PTR(ret));
> > +             return ret;
> > +     }
> > +
> > +     of_alias_scan();
> > +
> > +     return 0;
> > +}
> > +postcore_initcall(state_overlay_apply);
>
> This can be used to apply arbitrary overlay content, so the option name
> should probably not be state specific.
>
> Cheers,
> Ahmad
>
> >
>
> --
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
>

Best regards,
Anis