The assignment of block device nodes in Linux is not deterministic by
default, i.e. a newly added eMMC controller or other block device can
change the assignment of /dev/mmcblkN (or other block device node like
e.g. /dev/sdXy) and prevent the system from picking the correct block
device for root filesystem in case the root filesystem is specified on
kernel command line using 'root=/dev/mmcblkNpM' (or 'root=/dev/sdXy'
etc.).

One way out is to derive PARTUUID in U-Boot, which is unique identifier
of a partition, and pass that as root=PARTUUID=<partuuid> to Linux via
kernel command line. Linux would then find the partition using PARTUUID,
no matter on which block device the partition resides and which node was
assigned to that block device.

Derive the PARTUUID before scanning for extlinux presence and assign it
into distro_bootpart_uuid environment variable, which can then be used
in extlinux.conf kernel command line specifier.

Note that it is not possible to do this in scan_dev_for_extlinux script
because this script is called from scan_dev_for_boot script, which is
called for both block devices as well as UBI volumes, and we can not
derive PARTUUID for UBI volumes.

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

The "SCRIPT FAILED" string is copied from scan_dev_for_scripts script,
update it so it prints "EXTLINUX FAILED" instead in scan_dev_for_extlinux
script.

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

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

Try to load required DTB overlays if the board supports extensions and
CONFIG_CMD_EXTENSION is enabled.

Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>

Some UBI partitions may use non-standard UBI header offset. For attaching
these UBI partitions it is required to pass second argument with offset to
"ubi part" command.

Therefore extend distroboot to allow specifying additional optional 6th
argument with UBI header offset. This offset is set in new distroboot
variable ${bootubioff} which may be used by distroboot script to e.g.
properly pass this value to linux kernel command line for proper mounting
of rootfs by kernel. This variable is set to empty string (cleared) when
UBI header offset is not specified into distroboot BOOT_TARGET_DEVICES
macro.

Usage of helper macro BOOTENV_DEV_UBIFS_BOOTUBIOFF in this change is there
as a type check. It ensures that in BOOT_TARGET_DEVICES macro was specified
UBIFS func with either 5 or 6 arguments. If not then cpp throws compile
error.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Fix multiple issues in ubifs distroboot code:

U-Boot supports attaching only one MTD device as UBI at the time. So
always call 'ubifsmount ubi0:${bootubivol}' for mounting UBI volume
${bootubivol}. Usage of 'ubi${devnum}' is incorrect as 'ubi part'
command attach MTD device always as UBI device ubi0.

Set distroboot ${bootfstype} variable to ubifs in ubifs_boot command.
Distroboot scripts require ${bootfstype} variable to be properly set and it
is already set for all other boot types.

Set distroboot ${distro_bootpart} variable to ${bootubivol} value. UBI
device does not have partitions, but has volumes. Distroboot scripts
require something to be set in ${distro_bootpart} variable, so set it to
the UBI volume which is currently mounted by ubifs.

Set distroboot ${devnum} variable to fixed string "ubi0". ubifs code
differs from the other partition code that it requires "ubi" prefix before
number.

Explicitly unmount ubifs volume after loading all data from it. This allows
to detach UBI device from MTD device.

Move definition of MTD device with UBI and UBI volume with ubifs filesystem
from global env variables ${bootubipart} and ${bootubivol} into the
distroboot "func" macro, defined in board include config files. UBIFS
distroboot macros then set ${bootubipart} and ${bootubivol} local variables
for compatibility with existing distroboot scripts.

This last change allows to define more UBIFS target devices and make it
clear what is boot MTD/UBI device.

All board include config files are adjusted to use this new scheme of
specifying boot MTD/UBI device.

Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Frieder Schrempf <frieder.schrempf@kontron.de>

distro_bootcmd uses this construct a few times to test $fdt_addr_r,
and fall back on $fdtcontroladdr if not set/invalid:

    if fdt addr ${fdt_addr_r}; then
        ...
    else
        ...
    fi

If the `fdt addr` test fails, it prints the following  message on the
console, suggesting there is an error when there is not:

    libfdt fdt_check_header(): FDT_ERR_BADMAGIC

To remove this potentially confusing error message, this patch adds -q
as a 'quiet' option for fdt addr, and uses this flag in
config_distro_bootcmd.h

Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>

This converts the following to Kconfig:
   CONFIG_USE_BOOTCOMMAND
   CONFIG_BOOTCOMMAND
   CONFIG_RAMBOOTCOMMAND
   CONFIG_NFSBOOTCOMMAND

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

The SCSI device can be a PCIe adapter, so run pcie enum if enabled.

Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>

Now that driver model is always used, check for PCI.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Update logic, reword]
Signed-off-by: Tom Rini <trini@konsulko.com>