From: chalianis1@gmail.com
To: s.hauer@pengutronix.de
Cc: barebox@lists.infradead.org, Chali Anis <chalianis1@gmail.com>
Subject: [PATCH v2 0/3] state: generic devicetree-overlay based state node injection
Date: Tue, 25 Aug 2026 01:52:47 +0200 [thread overview]
Message-ID: <20260824235250.94681-1-chalianis1@gmail.com> (raw)
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. Patch 3 builds on both to publish
the resolved state description as a UEFI variable once such a node
exists, and makes the standalone state.dtb loading path step aside when
it does, since it's then redundant.
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.
- 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.
Chali Anis (3):
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
.../bindings/barebox/barebox,state.rst | 9 +++
Documentation/user/state.rst | 32 +++++++++
common/Kconfig | 36 ++++++++++
common/state/Makefile | 20 ++++++
common/state/state.c | 72 +++++++++++++++----
common/state/state_overlay.c | 19 +++++
efi/payload/init.c | 46 +++++++++++-
include/state.h | 5 ++
8 files changed, 225 insertions(+), 14 deletions(-)
create mode 100644 common/state/state_overlay.c
next reply other threads:[~2026-08-24 23:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 23:52 chalianis1 [this message]
2026-08-24 23:52 ` [PATCH v2 1/3] state: make of_state_fixup() usable outside common/state/ chalianis1
2026-08-24 23:52 ` [PATCH v2 2/3] state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree overlay chalianis1
2026-08-24 23:52 ` [PATCH v2 3/3] efi: payload: export resolved state as a BareboxState UEFI variable chalianis1
2026-08-25 0:06 [PATCH v2 0/3] state: generic devicetree-overlay based state node injection chalianis1
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260824235250.94681-1-chalianis1@gmail.com \
--to=chalianis1@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox