Commit graph

38 commits

Author SHA1 Message Date
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
Hans de Goede
a03bdaa140 config_distro_bootcmd: Run 'scsi scan' before trying scsi disks
Scsi disks need to be probed before we try to access them, otherwise all
accesses fail with: ** Bad device size - scsi 0 **.

Reported-by: Karsten Merker <merker@debian.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Karsten Merker <merker@debian.org>
2014-09-24 18:30:28 -04:00
Dennis Gilmore
2a43201a13 config: introduce a generic $bootcmd
This generic $bootcmd, and associated support macros, automatically
searches a defined set of storage devices (or network protocols) for an
extlinux configuration file or U-Boot boot script in various standardized
locations. Distros that install such a boot config file/script in those
standard locations will get easy-to-set-up booting on HW that enables
this generic $bootcmd.

Boards can define the set of devices from which boot is attempted, and
the order in which they are attempted. Users may later customize this
set/order by edting $boot_targets.

Users may interrupt the boot process and boot from a specific device
simply by executing e.g.:

$ run bootcmd_mmc1
or:
$ run bootcmd_pxe

This patch was originally written by Dennis Gilmore based on Tegra and
rpi_b boot scripts. I have made the following modifications since then:

* Boards must define the BOOT_TARGET_DEVICES macro in order to specify
  the set of devices (and order) from which to attempt boot. If needed,
  we can define a default directly in config_distro_bootcmd.h.

* Removed $env_import and related variables; nothing used them, and I
  think it's better for boards to pre-load an environment customization
  file using CONFIG_PREBOOT if they need.

* Renamed a bunch of variables to suit my whims:-)

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Simon Glass <sjg@chromium.org>
2014-08-09 11:17:04 -04:00