u-boot.git/boot/fdt_support.c, branch master

boot/bootfdt: Add smbios3-entrypoint to FDT for non-EFI boots

2025-12-02T22:34:27+00:00

The Linux kernel can discover SMBIOS tables through two primary methods:
1. Via EFI tables, when using EFI boot;
2. Via the 'smbios3-entrypoint' property in the /chosen node of the
device tree.

When U-Boot boots a Linux kernel using a non-EFI command ("bootm",
"bootz", or "booti"), the kernel relies on the device tree to detect
the hardware. If SMBIOS tables are available in U-Boot, they should
be passed to the kernel via this device tree property.

This patch modifies boot_fdt_prepare(), to inject the SMBIOSv3 table
address into the device tree if there is a table generated by U-boot.
The "board_fdt_chosen_smbios" is weak in order to leave the possibilty
for specific boards to select custom SMBIOS addresses.

The changes in this patch are added in the context of supporting this
device tree property in linux kernel:
https://lkml.org/lkml/2025/10/24/1393

Device tree schema was updated to include the "smbios3-entrypoint" node
in pull request: https://github.com/devicetree-org/dt-schema/pull/177

Signed-off-by: Adriana Nicolae

Revert "fdt: Make sure there is no stale initrd left"

2025-10-03T13:45:20+00:00

This reverts commit 9fe2e4b46458f9c4ec6b8115ebf18b4b26fe6127.

Commit 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
introduces a regression in case when U-Boot transfers control to an EFI
app which acts as a subsequent bootloading program. Such an app might
try to set "linux,initrd-start" and "linux,initrd-end" fdt properties,
but by that time those properties are already removed by the code added
in the mentioned commit.

Particularly, the issue was observed on the E850-96 board where GBL EFI
app [1] can't run Android successfully anymore. More specifically, the
kernel can't see the ramdisk and panics with next messages:

    /dev/root: Can't open blockdev
    VFS: Cannot open root device "" or unknown-block(0,0): error -6
    Please append a correct "root=" boot option; ...
    Kernel panic - not syncing: VFS: Unable to mount root fs on
    unknown-block(0,0)

fdt_initrd() function (where initrd dts properties are removed) is
called two times:

1. First it's called by EFI boot manager (e.g. as a part of U-Boot
Standard Boot mechanism) when it's installing FDT:

    fdt_initrd
    image_setup_libfdt
    efi_install_fdt
    efi_bootmgr_run
    efi_mgr_boot

It's already enough for EFI app to malfunction. But then it's also
called second time:

2. From the EFI app, via EFI DT fixup protocol:

    fdt_initrd
    image_setup_libfdt
    efi_dt_fixup
    struct efi_dt_fixup_protocol efi_dt_fixup_prot = {
        .fixup = efi_dt_fixup
    };

See [2] for specific GBL code which sets those fdt properties and then
runs DT fixup protocol callback.

This issue was discussed [3], but no action was taken since then. Revert
this patch for now, until a proper solution can be found.

[1] https://source.android.com/docs/core/architecture/bootloader/generic-bootloader/gbl-dev
[2] https://android.googlesource.com/platform/bootable/libbootloader/+/refs/heads/gbl-mainline/gbl/libgbl/src/android_boot/mod.rs#208
[3] https://lists.denx.de/pipermail/u-boot/2025-July/593879.html

Fixes: 9fe2e4b46458 ("fdt: Make sure there is no stale initrd left")
Signed-off-by: Sam Protsenko

fdt: Make sure there is no stale initrd left

2025-06-12T22:13:51+00:00

Although if we don't setup an initrd, there could be a stale initrd
setting from the previous boot firmware in the live device tree. So,
make sure there is no setting left if we don't want an initrd.

This can happen when booting on a Raspberry Pi. The boot firmware can
happily load an initrd before us and configuring the addresses in the
live device tree we get handed over.

Especially the setting `auto_initramfs` in config.txt is dangerous.
When enabled (default), the firmware tries to be smart and looks for
initramfs files.

Signed-off-by: Richard Weinberger

fdt: add support for adding pmem nodes

2025-03-26T11:28:08+00:00

One of the problems an OS may face, when running in EFI, is that
a mounted ISO, after calling ExitBootServices goes away, if that ISO
is resident in RAM memory as a ramdisk.

ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
don't have anything in place for DTs. Linux and device trees have support
for persistent memory devices. So add a function that can inject a pmem
node in a DT, so we can pass information on the ramdisk the OS.

Signed-off-by: Masahisa Kojima 
Signed-off-by: Sughosh Ganu 
Reviewed-by: Ilias Apalodimas 
Signed-off-by: Ilias Apalodimas

common: fdt: hand over original fdt bootargs into board chosen handler

2025-01-14T21:41:56+00:00

Sometimes, it is necessary to provide an additional bootargs string to
the kernel command line.

We have a real scenario where one U-Boot blob needs to boot several
kernel images: the vendor-patched kernel image and the latest upstream
kernel image. The Amlogic (Meson architecture) tty driver has different
tty suffixes in these kernels: the vendor uses 'ttySx', while the
upstream implementation uses 'ttyAMLx'. The initial console setup is
provided to the kernel using the kernel command line (bootargs). For the
vendor kernel, we should use 'console=ttyS0,115200', while for the
upstream kernel, it must be 'console=ttyAML0,115200'. This means we have
to use different command line strings depending on the kernel version.

To resolve this issue, we cannot use the CMDLINE_EXTEND kernel
configuration because it is considered legacy and is not supported for
the arm64 architecture. CMDLINE_EXTEND is outdated primarily because we
can provide additional command line strings through the
'chosen/bootargs' FDT node. However, U-Boot uses this node to inject the
U-Boot bootargs environment variable content, which results in U-Boot
silently overriding all data in the 'chosen/bootargs' node. While we do
have the board_fdt_chosen_bootargs() board hook to address such issues,
this function lacks any FDT context, such as the original value of the
'chosen/bootargs' node.

This patch introduces a read-only (RO) fdt_property argument to
board_fdt_chosen_bootargs() to share the original 'chosen/bootargs' data
with the board code. Consequently, the board developer can decide how to
handle this information for their board setup: whether to drop it or
merge it with the bootargs environment.

Signed-off-by: Dmitry Rokosov 
Reviewed-by: Quentin Schulz

fdt_support: board_fdt_chosen_bootargs() should return const char*

2025-01-14T21:41:56+00:00

It should be structured this way to demonstrate to the caller that
freeing the return value is unnecessary and that the caller cannot
modify it.
The function fdt_setprop() includes a parameter with a const char*
prototype, so it is better to use the const qualifier.

Signed-off-by: Dmitry Rokosov 
Reviewed-by: Heinrich Schuchardt

Merge patch series "automatically add /chosen/kaslr-seed and deduplicate code"

2024-06-28T23:31:28+00:00

Tim Harvey  says:

This series will automatically add /chosen/kaslr-seed to the dt if
DM_RNG is enabled
during the boot process.

If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.

If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).

As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to overwrite
the node if present.

For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.

Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.

Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.

fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled

2024-06-28T23:30:45+00:00

If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.

If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as its implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).

Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.

Signed-off-by: Tim Harvey 
Reviewed-by: Simon Glass 
Cc: Michal Simek 
Cc: Andy Yan 
Cc: Akash Gajjar 
Cc: Ilias Apalodimas 
Cc: Simon Glass 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Cc: Devarsh Thakkar 
Cc: Heinrich Schuchardt 
Cc: Hugo Villeneuve 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Chris Morgan

Add fdt_kaslrseed function to add kaslr-seed to chosen node

2024-06-28T23:30:45+00:00

If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.

Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.

Signed-off-by: Tim Harvey 
Reviewed-by: Simon Glass 
Cc: Michal Simek 
Cc: Andy Yan 
Cc: Akash Gajjar 
Cc: Ilias Apalodimas 
Cc: Simon Glass 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Cc: Devarsh Thakkar 
Cc: Heinrich Schuchardt 
Cc: Hugo Villeneuve 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Chris Morgan 
Reviewed-by: Caleb Connolly

Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"

2024-05-20T19:35:03+00:00

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman 
Signed-off-by: Tom Rini