Commit graph

52 commits

Author SHA1 Message Date
Tom Rini
e9a1ff9724 Merge branch 'master' into next
Signed-off-by: Tom Rini <trini@konsulko.com>
2022-09-19 16:07:12 -04:00
Matwey V. Kornilov
d88260710b distro_bootcmd: Introduce support for extension command
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>
2022-09-02 12:22:56 -04:00
Pali Rohár
53a9f9ef87 distroboot: ubifs: Add support for specifying UBI header offset
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>
2022-08-26 20:45:15 -04:00
Pali Rohár
e6ca148104 distroboot: Fix ubifs
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>
2022-07-08 09:05:47 -04:00
Peter Hoyes
e9496ec374 fdt: Add -q option to fdt addr for distro_bootcmd
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>
2022-04-22 15:44:10 -04:00
Tom Rini
970bf8603b Convert CONFIG_USE_BOOTCOMMAND et al to Kconfig
This converts the following to Kconfig:
   CONFIG_USE_BOOTCOMMAND
   CONFIG_BOOTCOMMAND
   CONFIG_RAMBOOTCOMMAND
   CONFIG_NFSBOOTCOMMAND

Signed-off-by: Tom Rini <trini@konsulko.com>
2021-12-01 10:58:10 -05:00
Neil Armstrong
d565a35dbd distro_bootcmd: run pci enum for scsi_boot just like it is done for nvme_boot
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>
2021-10-07 10:14:50 +02:00
Simon Glass
e15ba68029 distro_bootcmd: Update DM_PCI check
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>
2021-08-06 08:26:09 -04:00
Andre Przywara
ccadfca251 distro_boot: Fix block device after DHCP boot sequence
The generic distro boot sequence iterates over several types of devices,
trying one after another. In doing do, it starts with setting the
"devtype" variable, then uses this later in more generic commands.

Now most (block) device types use a local variable for that, but DHCP
puts the type into the environment, where it shadows any local variables.
As a consequence any boot attempt after bootcmd_dhcp has been run fails:
===========================
VExpress64# run bootcmd_dhcp
...
VExpress64# run bootcmd_sata0
SATA#0:
        (3.0 Gbps)
SATA#1:
        (No RDY)
Device 0: Model: 16GB SATA Flash Drive  ....
... is now current device
Couldn't find partition dhcp 0:1
===========================
This problem typically doesn't show, because DHCP is mostly the last
command to try, but is a problem when this order is different, or when
distro_bootcmd or bootcmd_xxx are run separately or multiple times.

Let bootcmd_dhcp use a local variable, as the other kids do, to make the
order of boot commands irrelevant, and allow repeated calls.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2021-07-23 07:13:25 -04:00
Heinrich Schuchardt
ff2f532fad efi_loader: make the UEFI boot manager configurable
Some boards are very tight on the binary size. Booting via UEFI is possible
without using the boot manager.

Provide a configuration option to make the boot manager available.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-01-20 08:09:34 +01:00
Igor Opaniuk
c9cb6a6002 distro_bootcmd: set devtype for dhcp boot
Set $devtype for DHCP boot, which can be handy for the boot.scr
for detection of devtype used (for example, when the same boot.scr is
used for both mmc/dhcp boot):

if test ${devtype} = "dhcp"; then
	...
fi

Signed-off-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Reviewed-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
2020-12-15 13:56:50 -05:00
Peter Robinson
fe669925cb arm: tegra: add options for BOOTENV_EFI_SET_FDTFILE_FALLBACK for tegra186
Upstream linux DT naming doesn't align with the U-Boot DT, which may
not always be the case so this allows using BOOTENV_EFI_SET_FDTFILE_FALLBACK
where it might be appropriate for some boards.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
2020-12-04 13:30:42 -07:00
Michael Walle
f3866909e3 distro_bootcmd: call EFI bootmgr even without having /EFI/boot
Currently, the EFI bootmgr is only called if there is a EFI binary
inside the path for removable media is found, i.e. /EFI/boot/. This
doesn't make sense. It is the duty of the bootmgr to find out the
path and name of the EFI binary to boot. It should be called even
if there is no /EFI/boot directory.

Thus, call the bootmgr before we try to boot the EFI binary inside
the removable media path.

Also remove the ${fdtcontroladdr} parameter because the fallback is
handled in cmd/bootefi.c and that already takes care of correct settings
if the board has ACPI and thus no device tree at all.

Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-10-06 07:43:56 +02:00
Patrick Wildt
52e1d93c14 NVMe: do PCI enumerate before nvme scan
Make sure that the PCI busses are enumerated before trying to
find a NVMe device.

Signed-off-by: Patrick Wildt <patrick@blueri.se>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-10-31 07:22:53 -04:00
David Abdurachmanov
f0ebcf8c17 distro_bootcmd: refactor virtio to support PCI block devices
Starting libvirt v5.3.0 with QEMU 4.0.0 use of PCI is automatic
and thus storage is connected via PCI, which is not visible to
U-Boot out-of-the-box.

Refactor to do "pci enum" followed by "virtio scan" to see PCI
connected storage, and allow bootloader to load kernel and
initramfs images.

Tested with Fedora/RISCV using releases: libvirt 5.4.0 & 5.5.0,
QEMU 4.0.0 and U-Boot 2019.07 RC4.

Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
2019-07-24 14:15:38 -04:00
Joshua Watt
d5e994fc55 config_distro_bootcmd: Init IDE devices
IDE devices are no longer automatically probed by u-boot, so it should
be done by the distro boot command before attempting to boot from IDE
(just like scsi and nvme)

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
2019-06-21 10:07:11 -04:00
AKASHI Takahiro
13dd6665ed distro: not taint environment variables if possible
The aim of this patch is not to have temporary variables used in
distro_bootcmd left as environment variables after run something.
See the discussion[1].
Without this patch, saveenv command also saves those variables, too.
While they are apparently safe, scsi_need_init can be harmful.

Please note that, in most cases, a variable should be converted to
hush's local variable, while "devplist" cannot because it is created
by "part" command as an environment variable.

[1] https://lists.denx.de/pipermail/u-boot/2018-December/350209.html

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2019-02-13 09:40:05 +01:00
Heinrich Schuchardt
9493e39cd4 distro_bootcmd: add NVME support
Some boards support NVME drives. We should be able to use them as boot
devices.

NVME access requires running 'nvme scan'.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2019-02-13 09:40:05 +01:00
Lukas Auer
a8da9ff466 distro_bootcmd: add VirtIO distro boot command
Add a boot command to distro boot to support disks connected over the
VirtIO bus. The boot command uses the shared block environment.

Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
2018-11-26 13:57:32 +08:00
Lukas Auer
862e2e75e8 riscv: rename CPU_RISCV_32/64 to match architecture names ARCH_RV32I/64I
RISC-V defines the base integer instruction sets as RV32I and RV64I.
Rename CPU_RISCV_32 and CPU_RISCV_64 to ARCH_RV32I and ARCH_RV64I to
match this convention.

Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
2018-11-26 13:57:29 +08:00
Martyn Welch
ad5fbc6e88 Ability to modify distro boot filename
Add in the ability to modify the distro boot filename. Whilst not
immediately useful in normal usage, it allows an alternative
configuration to be provided when other u-boot functionality is used, such
as bootcount limit, to fallback to an alternative boot configuration. In
this case we can follow the same boot path as for normal boot, just
using an alternatively named configuration file.

For example, by providing the following `altbootcmd` when bootcount is in
use:

altbootcmd=setenv boot_extlinx_conf extlinux-rollback.conf; \
	run distro_bootcmd

Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2018-11-16 16:52:01 -05:00
Simon Glass
a4958a7101 efi: sandbox: Add distroboot support
With sandbox these values depend on the host system. Let's assume that it
is x86_64 for now.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-23 21:55:30 +02:00
Alexander Graf
2c6903fa7b distro: Extend with RISC-V defines
While we don't have UEFI naming conventions for RISC-V file paths yet,
we need to search for something. So let's copy the removable file paths
from the RISC-V edk2 port.

Also add the official VCI strings that contain the standardized RISC-V
architecture ID fields.

Signed-off-by: Alexander Graf <agraf@suse.de>
2018-05-29 14:43:12 +08:00
Tom Rini
83d290c56f SPDX: Convert all of our single license tags to Linux Kernel style
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from.  So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry.  Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.

In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.

This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents.  There's also a few places where I found we did not have a tag
and have introduced one.

Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-07 09:34:12 -04:00
Derald D. Woods
6e1364fe45 distro bootcmd: Allow board defined UBI partition and volume names
This commit allows overriding the default assumption that the boot UBI
MTD partition is named 'UBI' and the UBI volume is 'boot'. A board
desiring to use a legacy or alternative NAND layout can now define the
following two extra environment variables:

	bootubipart=<some_ubi_partition_name>
	bootubivol=<some_ubi_volume_name>

EXAMPLE:

[include/configs/some_board.h]
---8<-------------------------------------------------------------------
[...]
	#include <config_distro_defaults.h>

	#define MEM_LAYOUT_ENV_SETTINGS \
		DEFAULT_LINUX_BOOT_ENV

	#define BOOT_TARGET_DEVICES(func) \
		func(UBIFS, ubifs, 0)

	#include <config_distro_bootcmd.h>
[...]
	#define CONFIG_EXTRA_ENV_SETTINGS \
		MEM_LAYOUT_ENV_SETTINGS \
		"bootubivol=rootfs\0" \
		"bootubipart=rootfs\0" \
		BOOTENV
[...]
---8<-------------------------------------------------------------------

Signed-off-by: Derald D. Woods <woods.technical@gmail.com>
2018-01-28 12:27:29 -05:00
Heinrich Schuchardt
a53fbf4046 distro bootcmd: define bootloader name for x86
Currently X86 does not properly support distro defaults.
This patch is only a partial fix.

It provides the name of the bootloader EFI application
for the X86 architecture.

The architecture dependent file names are defined in the UEFI
specification.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-11-30 13:50:17 +08:00
Rob Clark
9975fe96b6 efi_loader: add bootmgr
Similar to a "real" UEFI implementation, the bootmgr looks at the
BootOrder and BootXXXX variables to try to find an EFI payload to load
and boot.  This is added as a sub-command of bootefi.

The idea is that the distro bootcmd would first try loading a payload
via the bootmgr, and then if that fails (ie. first boot or corrupted
EFI variables) it would fallback to loading bootaa64.efi.  (Which
would then load fallback.efi which would look for \EFI\*\boot.csv and
populate BootOrder and BootXXXX based on what it found.)

Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
2017-09-20 11:08:01 +02:00
Simon Glass
186424248d Kconfig: Drop CONFIG_CMD_PCI_ENUM
This option enables the 'pci enum' command. It is only enabled by a few
board and these have not yet been converted to driver model, which always
enables this command. It seems easiest to just remove this option.

The affected boards can be converted to use driver model for PCI if
needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-08-11 15:41:51 -04:00
Simon Glass
10e40d54b3 Kconfig: Add CONFIG_SATA to enable SATA
At present CONFIG_CMD_SATA enables the 'sata' command which also brings
in SATA support. Some boards may wish to enable SATA without the command.
Add a separate CONFIG to permit this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2017-07-11 10:08:19 -06:00
Simon Glass
fc843a02ac Kconfig: Add a CONFIG_IDE option
At present IDE support is controlled by CONFIG_CMD_IDE. Add a separate
CONFIG_IDE option so that IDE support can be enabled without requiring
the 'ide' command.

Update existing users and move the ide driver into drivers/block since
it should not be in common/.

Signed-off-by: Simon Glass <sjg@chromium.org>
2017-05-22 12:45:27 -04:00
Patrick Delaunay
b331cd6204 cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPT
We convert CONFIG_PARTITION_UUIDS to Kconfig first.  But in order to cleanly
update all of the config files we must also update CMD_PART and CMD_GPT to also
be in Kconfig in order to avoid complex logic elsewhere to update all of the
config files.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
2017-01-28 08:48:03 -05:00
Alexander Graf
fba5f93c71 efi_loader: Fix typo in distro script
The distro script is supposed to use the internal fdt as fallback if we
find no viable other option. However, we're missing a space key to actually
make that work.

Add the space, so we can successfully load an EFI blob even when there is
no device tree provided on the target device.

Signed-off-by: Alexander Graf <agraf@suse.de>
2016-06-24 17:24:41 -04:00
Alexander Graf
20898ea934 distro: Add efi pxe boot code
Now that we can expose network functionality to EFI applications,
the logical next step is to load them via pxe to execute them as
well.

This patch adds the necessary bits to the distro script to automatically
load and execute EFI payloads. It identifies the dhcp client as a uEFI
capable PXE client, hoping the server returns a tftp path to a workable
EFI binary that we can then execute.

To enable boards that don't come with a working device tree preloaded,
this patch also adds support to load a device tree from the /dtb directory
on the remote tftp server.

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-05-27 15:39:45 -04:00
Simon Glass
c649e3c91c dm: scsi: Rename CONFIG_CMD_SCSI to CONFIG_SCSI
This option currently enables both the command and the SCSI functionality.
Rename the existing option to CONFIG_SCSI since most of the code relates
to the feature.

Signed-off-by: Simon Glass <sjg@chromium.org>
2016-05-17 09:54:43 -06:00
Alexander Graf
ff2545ab78 efi_loader: Fall back to fdtfile naming convention
When there is no $fdtfile variable set, we still have a good chance
that on 32bit arm the fdtfile really is just called $soc-$board.dtb.

Enable the exports for $soc and $board in our distr defaults and make
use of them in the efi boot script.

Reported-by: Andreas Faerber <afaerber@suse.de>
Reported-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Andreas Färber <afaerber@suse.de>
2016-04-18 17:11:50 -04:00
Alexander Graf
1c39809b92 efi_loader: Pass fdt address directly to bootefi cmd
The bootefi cmd today fetches its device tree pointer from either the
location appointed by "fdt addr" with a fallback to the U-Boot control
fdt.

This integration is unusual for U-Boot and diverges from the way we
usually handle parameters to boot commands. So let's pass the fdt
directly into the bootefi command instead and move the control fdt
logic into the distro boot script.

Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
2016-04-18 17:11:49 -04:00
Alexander Graf
da3e620d68 arm64: Replace fdt_name env variables with fdtfile
The commonly defined environment variable to determine the device tree
file name is called fdtfile rather than fdt_name. Replace all occurences
of fdt_name with fdtfile.

Signed-off-by: Alexander Graf <agraf@suse.de>
2016-03-15 21:30:13 -04:00
Alexander Graf
74522c898b efi_loader: Add distro boot script for removable media
UEFI defines a simple boot protocol for removable media. There we should look
at the EFI (first GPT FAT) partition and search for /efi/boot/bootXXX.efi with
XXX being different between different platforms (x86, x64, arm, aa64, ...).

This patch implements a simple version of that protocol for the default distro
boot script. With this we can automatically boot from valid UEFI enabled
removable media.

Because from all I could see U-Boot by default doesn't deliver device tree
blobs with its firmware, we also need to load the dtb from somewhere. Traverse
the same EFI partition for an fdt file that fits our current board so that
an OS receives a valid device tree when booted automatically.

Signed-off-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-03-15 21:30:11 -04:00
Stephen Warren
986691fb97 distro bootcmd: enumerate PCI before network operations
The PCI bus must be enumerated before PCI devices, such as Ethernet
devices, are known to U-Boot. Enhance the distro boot commands to perform
PCI enumeration when needed.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-01-28 21:01:23 -07:00
Stephen Warren
3483b75d94 distro bootcmd: make net boot only optionally start USB
Currently, the distro boot commands always enumerate USB devices before
performing network operations. However, depending on the board and end-
user configuration, network devices may not be attached to USB, and so
enumerating USB may not be necessary. Enhance the scripts to make this
step optional, so that the user can decrease boot time if they don't
need USB.

This change is performed by moving the "usb start" invocation into a
standalone variable. If the user desires, they can replace that
variable's value with some no-op command such as "true" instead.

Booting from a USB storage device always needs to enumerate USB devices,
so this action is still hard-coded.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-01-28 21:01:23 -07:00
Roy Spliet
40d2154726 distro_bootcmd: Add support for booting from ubifs
Under the assumptions of having a UBI volume called boot, containing
a ubifs filesystem.

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
2015-10-24 13:50:33 -04:00
Sjoerd Simons
59d03cb377 config_distro_bootcmd.h: Use a private variable for bootpart
Hush has an oddity where using ${var} causes var to resolved in the the global
address space (iotw the environment) first and only afterwards will the local
variable space be searched.

This causes odd side-effects when iterating over the boot partitions
using ${bootpart} if the environment also has a bootpart variable (e.g. for
the various TI boards). Fix this by using the hopefully more unique
${distro_bootpart} instead of ${bootpart}.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-10-22 14:18:31 -04:00
Sjoerd Simons
d0bce0d1cb config_distro_bootcmd.h: Add shared block definition for the host interface
Define the common shared block environment for the host interface in
preperation for the sandbox build to use config_distro_bootcmd.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
2015-04-19 14:45:58 -06:00
Sjoerd Simons
f643d9294f config_distro_bootcmd.h: Prefer booting from bootable paritions
List bootable partitions and only scan those for bootable files, falling
back to partition 1 if there are no bootable partitions

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
2015-03-25 12:15:18 -04:00
Stephen Warren
90b7caaf55 config_distro_bootcmd.h: add note on error handling
This should make it more clear why there appear to be C pre-processor
symbols in the file that contain mixed case. They're really error
messages.

Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2015-03-13 09:29:36 -04:00
Hans de Goede
af21f2fb6f config_distro_bootcmd.h: Enable CONFIG_CMD_PART
The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be
defined, as the default bootcmd now uses the "part" command.

This fixes sunxi boards not booting with v2015.04-rc1.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
2015-02-16 12:41:41 -05:00
Stephen Warren
cc11b39288 distro_bootcmd: read DHCP boot script name from a variable
Modify $bootcmd_dhcp to read the downloaded script filename from an
environment variable rather than hard-coding it. This allows the user
(or another script) to select a different script name if they want,
without editing the whole value of $bootcmd_dhcp.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
2015-01-30 09:19:16 -05:00
Sjoerd Simons
453c6cc19a distro_distro_bootcmd: use CONFIG_BOOTCOMMAND instead of setting bootcmd=
Move the bootcmd commands into a seperate distro_bootcmd environment
variable. Allowing a user to easily launch the distro boot sequence if
the default bootcmd did not default to distro boot commands.

Also set CONFIG_BOOTCOMMAND to "run distro_bootcmd" if it hasn't been
configured yet rather then putting it directly in the environment. This
allows boards to make the distro boot commands available without
necessarily default to them or to use them as a fallback after running
some board specific commands instead.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
2015-01-29 13:38:39 -05:00
Sjoerd Simons
735b1cfeb2 config_distro_bootcmd: Scan all partitions for boot files
Not all devices use the convention that the boot scripts are on the
first partition. For example on chromebooks it seems common for the
first two partitions to be ChromeOS kernel partitions.

So instead of just the first partition scan all partitions on a device
with a filesystem u-boot can recognize.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
2015-01-29 13:37:24 -05:00
Hans de Goede
a1d31077d0 config_distro_bootcmd.h: Remove unnecessary magic to avoid repeated USB scans
Now that "usb start" will only start usb if not already started, we can simply
call "usb start" whenever we (may) need access to usb devices, and it will only
actually scan the bus at the first call.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2015-01-18 12:31:35 +01:00