mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: chalianis1@gmail.com
To: s.hauer@pengutronix.de
Cc: barebox@lists.infradead.org, Chali Anis <chalianis1@gmail.com>
Subject: [PATCH v3 0/4] state: generic devicetree-overlay based state node injection
Date: Tue, 25 Aug 2026 05:05:44 +0200	[thread overview]
Message-ID: <20260825030548.473672-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 - 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




             reply	other threads:[~2026-08-25  3:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-25  3:05 chalianis1 [this message]
2026-08-25  3:05 ` [PATCH v3 1/4] state: make of_state_fixup() usable outside common/state/ chalianis1
2026-08-25 17:00   ` Ahmad Fatoum
2026-08-25 23:34     ` anis chali
2026-08-25  3:05 ` [PATCH v3 2/4] state: add CONFIG_STATE_OVERLAY to inject a state node via devicetree overlay chalianis1
2026-08-25 16:57   ` Ahmad Fatoum
2026-08-25 23:36     ` anis chali
2026-08-25  3:05 ` [PATCH v3 3/4] efi: payload: export resolved state as a BareboxState UEFI variable chalianis1
2026-08-25 17:04   ` Ahmad Fatoum
2026-08-25 23:30     ` anis chali
2026-08-25  3:05 ` [PATCH v3 4/4] efi: payload: make CONFIG_STATE_OVERLAY (and BareboxState export) work on x86 chalianis1
2026-08-25 17:06   ` Ahmad Fatoum
2026-08-25 15:02 ` [PATCH v3 0/4] state: generic devicetree-overlay based state node injection Ahmad Fatoum
2026-08-25 17:10   ` Ahmad Fatoum
2026-08-25 23:23     ` anis chali
2026-08-25 23:13   ` anis chali

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=20260825030548.473672-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