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 v2 0/1] efi: payload: apply barebox fixups to the devicetree passed to Linux
Date: Tue, 25 Aug 2026 01:43:44 +0200	[thread overview]
Message-ID: <20260824234345.84068-1-chalianis1@gmail.com> (raw)

From: Chali Anis <chalianis1@gmail.com>

efi_load_fdt() never ran barebox's fixup/overlay pipeline on the
devicetree it handed to the kernel. When bootm.oftree was set, the raw
file bytes were extracted straight into EFI pages and installed as-is;
of_unflatten_dtb(), of_fix_tree() and of_flatten_dtb() were never
called. When bootm.oftree was unset, the function just returned early,
so there was no path at all for adopting (and fixing up) a devicetree
already exposed by firmware. Either way, none of barebox's usual
fixups - memory nodes, bootargs, state, overlays, and everything else
hung off of_register_fixup() - ever reached the tree Linux booted
with.

This single patch fixes both paths: efi_load_fdt() now falls back to
the FDT firmware exposes via its EFI configuration table when no
bootm.oftree is set, and either way runs the resulting tree through
the standard bootm_set_pending_oftree_overlays()/of_fix_tree()
sequence before installing it, matching what every other barebox boot
path already guarantees. This is what makes fixups registered via
of_register_fixup() actually reach the devicetree the EFI payload
hands off to Linux.

On real hardware (as opposed to QEMU, where none of this is normally
present or needed) this matters concretely for two node types: the
/memory node, since of_memory_fixup() (common/memory.c) is one of the
fixups of_fix_tree() runs, and without this patch it never got a
chance to correct the tree Linux actually booted with; and the
/firmware and /reserved-memory nodes, since a devicetree supplied
out-of-band (e.g. embedded in a FIT image) was flattened at build
time and so can never carry the secure-world carve-outs and secure
monitor call conduit firmware such as TF-A/OP-TEE only add to its own
copy of the tree at runtime. This patch adds
efi_of_fixup_firmware_nodes() to import exactly those two nodes from
firmware's own devicetree onto the one Linux boots with, registered
as another of_register_fixup() callback so it runs as part of the
same pipeline.

Changes since v1: none, resent as v2.

Chali Anis (1):
  efi: payload: apply barebox fixups to the devicetree passed to Linux

 efi/payload/bootm.c   | 60 ++++++++++++++++++++++++++++++-------
 efi/payload/fdt.c     | 34 ++++++++++++++-------
 efi/payload/init.c    | 69 +++++++++++++++++++++++++++++++++++++++++++
 include/efi/payload.h | 10 +++++++
 4 files changed, 152 insertions(+), 21 deletions(-)




             reply	other threads:[~2026-08-24 23:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 23:43 chalianis1 [this message]
2026-08-24 23:43 ` [PATCH v2 1/1] " 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=20260824234345.84068-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