Check whether the loaded image or entry point does not overlap SPL.

Signed-off-by: Marek Vasut <marex@denx.de>

   Commands causing reset in some configs:

When bootflow scan is run, this will cause a UCLASS_BOOTDEV device to
be added as sibling of those UCLASS_BLK devices found in the search
chain defined in environment variable "boot_targets", until boot
succeeds from some device. This can happen automatically as part of
the default boot process on some boards (example: Rock Pi 4) depending
on the board configuration (DISTRO_DEFAULTS, BOOTSTD, BOOTCOMMAND,
etc.) because they have bootcmd=bootflow scan.

If boot doesn't succeed from any device, and usb is in boot_targets,
and an usb storage device is plugged to some usb port at boot time,
its UCLASS_MASS_STORAGE device will have a UCLASS_BOOTDEV device as
child, besides a UCLASS_BLK child.

If once the boot fails the user enters at the U-Boot shell prompt:

usb info

or

usb tree

The code in cmd/usb.c will eventually recurse into the UCLASS_BOOTDEV
device and pass a null usb_device pointer to usb_show_tree_graph() or
usb_show_info() (because it has no parent_priv_).

This causes a reset. The expected behaviour would be to ignore the
UCLASS_BOOTDEV device, continue listing the usb information and return
to the prompt.

   Minimal test:

Another way to trigger this reset as a minimal test or on boards with
a different bootcmd would be:

- make sure "usb" is in environment variable boot_targets (might need
  setenv boot_targets usb; and/or saveenv and reset), then, with a usb
  storage device plugged to a usb port, run:

=> usb reset ; bootflow scan ; usb info

   Solution:

Fix it (twice) by checking for null parent_priv_ and adding
UCLASS_BOOTDEV to the list of ignored class ids before the recursive
call.

This prevents the current particular problem with UCLASS_BOOTDEV, even
in case it ever gets some parent_priv_ struct which is not an
usb_device, despite being the child of a usb_device->dev. And it also
prevents possible future problems if other children are added to usb
devices that don't have parent_priv_ because they are not part of the
usb tree, just abstractions of functionality (like UCLASS_BLK and
UCLASS_BOOTDEV are now).

Signed-off-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Tested-by: Marek Vasut <marex@denx.de>

CID 453851 : sprintf() shouldn't copy from/to tmp
CID 436278 : DHCP6 option_len should be checked before use

Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>

The ubifsload command is truncating any address above 4GiB as it casts
this address to an u32, instead of using an unsigned long which most of
the other load commands do. Change this to an unsigned long to allow
loading into high memory for boards which use these areas.

Fixes the following error:

=> ubifsload 0x2100000000 /boot/Image.lzma
Loading file '/boot/Image.lzma' to addr 0x00000000...
Unhandled exception: Store/AMO access fault

Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>

Pull request efi-2023-07-rc3

Documentation:

* update the description of signature algorithms

UEFI:

* fix unaligned access to GUID in HII database protocol
* fix launching EFI binaries loaded via semihosting
* fix filling of file path in loaded image protocol for non-block devices

In a few cases the error handling is not quite right. Make sure we
return the actual error in distro_efi_read_bootflow_file() rather than
-EINVAL. Return -IO when a file cannot be read. Also show the error name
if available.

This does not change operation, but does make it easier to diagnose
problems.

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

The patch to relax flag requirements was not accepted[1], so we still have
to have separate bootcommands depending on CMD_BOOTFLOW_FULL.

The previous attempt at this did not work, since it used the wrong name
for the options.

Fix this and change the message to mention BOOTSTD_FULL since this affects
not just the flags, but all functionality, so is more likely what the user
wants.

Drop the useless condition on CMD_BOOTFLOW_FULL while we are here.

[1] https://patchwork.ozlabs.org/project/uboot/patch/20230329071655.1959513-2-sjg@chromium.org/

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: a91492b6e9c ("bootstd: Provide a default command")

This should be declared in a header file so that type-checking works
correctly.

Add a single declaration to usb.h and remove the others.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>

* When called from efi_dp_from_name() we miss to append the filename
  for non-block devices.
* expand_media_path() could be simplified by using efi_dp_from_file to
  prepend the device path of the boot device.

This can be avoided by passing a device path to efi_dp_from_file() instead
of a block device descriptor and a partition number.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Sometimes coreboot adds new tags that U-Boot does not know about. These
are silently ignored, but it is useful to at least know what we are
missing.

Add a way to collect this information. For Brya it shows:

   Unimpl. 38 41 37 34 42 40

These are:

   LB_TAG_PLATFORM_BLOB_VERSION
   LB_TAG_ACPI_CNVS
   LB_TAG_FMAP
   LB_TAG_VBOOT_WORKBUF
   LB_TAG_TYPE_C_INFO
   LB_TAG_BOARD_CONFIG

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>