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 <semen.protsenko@linaro.org>

Since the bootmeth "rauc" is not a global boot method, do not select the
corresponding BOOTMETH_GLOBAL option.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>

Martin Schwan <m.schwan@phytec.de> says:

This series fixes a segfault, that would occur at the end of scanning a
device, which does not contain the required partition layout scheme for
a RAUC system.

With this series, a "bootflow scan" should now correctly scan the
specified devices with boot method "rauc" without crashing on invalid
partition schemes.

Link: https://lore.kernel.org/r/20250813-wip-bootmeth-rauc-priv-free-v1-0-1ef928169469@phytec.de

The private data struct can be freed when loading the boot script, as we
don't need the slot information anymore at this point.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

Move freeing a distro_rauc_priv struct to a new, separate function for
better reuse.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

Don't null bootflow->bootmeth_priv, as the private struct is freed later
on by the bootflow.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

Fix a segfault when cleaning up the slots from the private struct. This
fault was generated by accessing a member of a null pointer.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

The bootmeth rauc should scan all partitions, in particular whole
devices, and not be a global method. There may exist multiple RAUC
systems on different devices and they should all be detected. This also
fixes a bug, where both a global bootflow and one using an actual,
complete device would be detected at the same time, when scanning for
valid bootflows.

Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Tested-by: Wadim Egorov <w.egorov@phytec.de>

This changes the default value to the most commonly used one among
existing defconfigs.

Signed-off-by: Martin Herren <sputnik@on-the-web.ch>
Acked-by: Michal Simek <michal.simek@amd.com> # xilinx_mbv
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>

uclass_find_next_device always returns 0, so instead make it a void and
update calling sites.

Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>