A recent change tried to speed up EFI booting by not calling dhcp_run
from eth_bootdev_hunt() every time. PXE so far relied on that dhcp_run
call to get an IP address.

Fix that by adding a dhcp_run call to the pxe bootflow, with autoload
disabled to only get the ip address and nothing else.

Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Fixes: 1f68057e0320 ("net: eth_bootdev_hunt() should not run DHCP")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Add support for starting TFA from U-Boot running in EL3 as part of
fitImage boot, so the user can start U-Boot in the highest privilege
level on the platform, bundle TFA, Linux, DT into a single fitImage
and boot such a bundle as a whole.

There are two main benefits of this approach. First is the ability
to run U-Boot in EL3, where it has unrestricted access to the entire
system and can act as a useful debug tool, as it was always intended
to be used. Second is the ability to easily and safely update of any
component in the fitImage, be it TFA, Linux or DT.

The boot process is similar to regular Linux with DT fitImage boot
process, except the TFA has to be bundled into the fitImage. For the
bundling instructions, see below. The TFA is started as a 'loadables'
with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling implemented in board code, and performing the handoff and
boot in case the TFA was loaded.

The loadables handler is optional and meant to set up any sort of
handoff structures used by the TFA BL31 or perform any other setup
that is needed by the blob. The custom armv8_switch_to_el2_prep()
has to implement the jump to TFA BL31 with return to U-Boot just
before booting the Linux kernel.

Example fitImage image and configuration section:

/dts-v1/;

/ {
    description = "Linux kernel with FDT blob and TFA BL31";

    images {
        kernel-1 { ... };
        fdt-1 { ... };
        atf-1 {                  /* This is the TFA BL31 image */
            description = "TFA BL31";
            data = /incbin/("../build/plat/release/bl31.bin");
            type = "tfa-bl31";
            arch = "arm64";
            os = "arm-trusted-firmware";
            compression = "none";
            load = <0x46400000>;
            entry = <0x46400000>;
        };
    };

    configurations {
        default = "conf-1";
        conf-1 {
            description = "Boot Linux";
            kernel = "kernel-1";
            fdt = "fdt-1";
            loadables = "atf-1"; /* This is the TFA BL31 loadable */
        };
    };
};

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

607b07554e2 removed the check on the return status of the
android_image_get_dtb_img_addr call from android_image_get_dtb_by_index,
which results in null pointer accesses shortly after when trying to
check the header of a nonexistent DTB.

Fixes: 607b07554e2 ("android: boot: move to andr_image_data structure")
Signed-off-by: Sam Day <me@samcday.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250123-android-handle-no-dtb-v1-1-1cb7373247da@samcday.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>

A FIT image which is NOT using -E when created by mkimage - that is with
image data within the FIT - will fail to apply FDTO if the base FDT
image node does not specify a load property (which points to an address
in DRAM). This is because we check that the FDT address we want to apply
overlay to (i.e. modify and likely increase in size) is not inside the
FIT and give up otherwise. This is assumed necessary because we may then
overwrite other data when applying in-place.

However, we can do better than giving up: relocating the FDT in another
place in DRAM where it's safe to increase its size and apply FDTOs.

While at it, do not discriminate anymore on whether the data is within
the FIT data address space - that is FIT images created with mkimage -E
- as that still may be susceptible to unintended data overwrites as
mkimage -E simply concatenates all blobs after the FIT. If the FDT blob
isn't the last, it'll result in overwriting later blobs when resizing.

The side effect is that the load property in the FIT is only
temporarily used to load the FDT but then relocated right before we
start applying overlays.

Suggested-by: Marek Vasut <marex@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

So far only VBE-simple is implemented in U-Boot. This supports a single
image which can be updated in situ.

It is often necessary to support two images (A and B) so that the board
is not bricked if the update is interrupted or is bad.

In some cases, a non-updatable recovery image is desirable, so that the
board can be returned to a known-good state in the event of a serious
failure.

Introduce ABrec which provides these features. It supports three
independent images and the logic to select the desired one on boot.

While we are here, fix a debug message to indicate the function it
called. Provide a maintainers entry for VBE.

Note that fwupdated only supports VBE-simple so far, but supports for
ABrec will appear in time.

Signed-off-by: Simon Glass <sjg@chromium.org>

When VBE operates within VPL it does not want the FDT to be changed.
Provide a way to disable this feature.

Move the FIT_IMAGE_TINY condition out of spl_fit_record_loadable() so
that both conditions are together. This makes the code easier to
understand.

Replace the existing fit_loaded member, which is no-longer used.

Signed-off-by: Simon Glass <sjg@chromium.org>

Join the comment block for the fit_image_load() call back to where it
should be. Also fix a debug statement.

Signed-off-by: Simon Glass <sjg@chromium.org>

With SPL we want to specify the phase of the image to be loaded. Add
support for this.

This is the implementation of a FIT feature added to the spec a few
years ago and entails a small code-size increase, about 70 bytes on
Thumb2.

Signed-off-by: Simon Glass <sjg@chromium.org>
Link: https://docs.u-boot.org/en/latest/usage/fit/index.html

Finish off the implementation so it is possible to boot an EFI app over
a network.

Signed-off-by: Simon Glass <sjg@chromium.org>

Rather than setting up the global variables and then making the call,
pass them into function directly. This cleans up the code and makes it
all a bit easier to understand.

Signed-off-by: Simon Glass <sjg@chromium.org>