When BLK is not enabled but BOOTSTD is, some features of standard boot
become unavailable. Add a check for this in the only site that is
currently apparent.

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

When a device fails to probe, the next device should be tried, until
either we find a suitable device or run out of devices. A device
should never be tried twice.

When we run out of devices of a particular priority, the hunter should
be used to generate devices of the next priority. Only if all attempts
fail should this function return an error.

Update the function to use the latent 'found' boolean to determine
whether another loop iteration is warranted, rather than setting 'dev'
to NULL, which creates confusion, suggesting that no devices have been
scanned and the whole process is starting from the beginning.

Note that the upcoming bootflow_efi() test is used to test this
behaviour.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/17

This turns out to be insufficient to fix the problem, since when
bootdev_next_prio() exits, the caller has no idea that this really
is the end. Nor is it, since there may be other devices which should
be checked.

The caller iterates which calls iter_incr() which calls
bootdev_next_prio() again, which finds the same device and the loop
continues.

We never did create a test for this[1], which makes it hard to be
sure which problem was fixed.

The original code had the virtue of staying in the loop looking for a
bootdev, so let's go back to that and try to fix this another way.

A future patch will make bootdev_next_prio() continue after failure
which should provide same effect.

This reverts commit 9d92c418acfb7576e12e2bd53fed294bb9543724.

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

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 <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Remove <common.h> from all "boot/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

The "bootflow" command currently doesn't support scanning a single
partition. This is inconvenient in setups with multiple bootable
partitions within a single disk, but only one is desired.

Support scanning a single disk partition. Specifically, support the
syntax:
	bootflow scan mmc1:4
which scans only mmc device 1, partition 4.

Signed-off-by: Nam Cao <namcao@linutronix.de>

Not all flows have a device and the function already contains logic to
handle this case.

Fixes: eccb25cd5922 ("bootstd: Allow the bootdev to be optional in bootflows")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Sometimes, when only one bootdev is available, and it fails to probe, we
end up in an infinite loop calling probe() on the same device over and
over. With only debug level log output.

Break the loop if we fail to probe the same device twice in a row, and
promote the probe failure message to log_warning().

Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>

During bootstd scanning for bootdevs, if bootdev_hunt_drv() encounters
a device not found error (e.g. ENOENT), let it return a successful status
so that bootstd will continue scanning the next devices, not stopping
prematurely.

Background:

During scanning for bootflows, it's possible for bootstd to encounter a
faulty device controller. Also when the same u-boot is used for another
variant of the same board, some device controller such as SATA might
not exist.

I've found this issue while converting the Marvell Sheevaplug board to
use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
USB only, but the later variant comes with USB, MMC, and eSATA ports. We
have been using the same u-boot (starting with CONFIG_IDE and later with DM
CONFIG_SATA) for both variants. This worked well with the old
envs-scripting booting scheme.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>