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>

When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter
again so does not see any devices. Fix this by telling bootstd about the
state of USB.

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

This name is a little confusing since it suggests that it sets up the
sibling block device. In fact it sets up a bootdev for it. Rename the
function to make this clearer.

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

It seems better to call this a 'bootdev' since this is name used in the
documentation. The older 'Bootdevice' name is no-longer used and may cause
confusion with the 'bootdevice' environment variable.

Update throughout to use bootdev.

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

Use the -l flag to indicate whether to report missing uclasses.

Also try to be more helpful when no devices are found. For example, when
we see something 'scsi0' requested and nothing was found, this indicates
that there are no SCSI devices, so show a suitable message.

Move messages out of the low-level functions so that silent operation
is possible.

This means they are never reported unless BOOTSTD_FULL is enabled, since
the -l flag cannot otherwise be set.

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

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

We want to support scanning a single label, like 'mmc' or 'usb0'. Add
this feature by plumbing the label through to the iterator, setting a
flag to indicate that only siblings of the initial device should be used.

This means that scanning a bootdev by its name is not supported anymore.
That feature doesn't seem very useful in practice, so it is no great loss.

Add a test for bootdev_find_by_any() while we are here.

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

At present we set up the bootdev order at the start, then scan the
bootdevs one by one.

However this approach cannot be used with hunters, since the bootdevs may
not exist until the hunter is used. Nor can we just run all the hunters at
the start, since that violate's U-Boot's 'lazy init' requirement. It also
increases boot time.

So we need to adjust the algorithm to scan by labels instead. As a first
step, drop the dev_order[] array in favour of a list of labels. Update the
name of bootdev_setup_iter_order() to better reflect what it does.

Update some related comments and log messages. Also disable a few tests
until a later commit where we can use them.

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

Add a function which moves to the next priority to be processed.

This works by storing the current priority in the bootflow iterator. The
logic to set this up is included in a subsequent commit.

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

Add a function which moves to the next label in a list of labels. This
allows processing the boot_targets environment variable.

This works using a new label list in the bootflow iterator. The logic to
set this up is included in a subsequent commit.

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

Add a function to hunt for a bootdev label and find the bootdev produced
by the hunter (or already present).

Add a few extra flags so that we can distinguish between "mmc1", "mmc" and
"1" which all need to be handled differently.

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