summaryrefslogtreecommitdiffstats
path: root/include/config_distro_bootcmd.h
Commit message (Collapse)AuthorAgeFilesLines
* NVMe: do PCI enumerate before nvme scanPatrick Wildt2019-10-311-0/+1
| | | | | | | | 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>
* distro_bootcmd: refactor virtio to support PCI block devicesDavid Abdurachmanov2019-07-241-6/+21
| | | | | | | | | | | | | | | 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>
* config_distro_bootcmd: Init IDE devicesJoshua Watt2019-06-211-1/+15
| | | | | | | | 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>
* distro: not taint environment variables if possibleAKASHI Takahiro2019-02-131-6/+7
| | | | | | | | | | | | | | | | | 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>
* distro_bootcmd: add NVME supportHeinrich Schuchardt2019-02-131-0/+27
| | | | | | | | | | | 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>
* distro_bootcmd: add VirtIO distro boot commandLukas Auer2018-11-261-0/+13
| | | | | | | | | 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>
* riscv: rename CPU_RISCV_32/64 to match architecture names ARCH_RV32I/64ILukas Auer2018-11-261-4/+4
| | | | | | | | | | 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>
* Ability to modify distro boot filenameMartyn Welch2018-11-161-3/+4
| | | | | | | | | | | | | | | | | | 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>
* efi: sandbox: Add distroboot supportSimon Glass2018-09-231-6/+10
| | | | | | | | 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>
* distro: Extend with RISC-V definesAlexander Graf2018-05-291-0/+11
| | | | | | | | | | | 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>
* SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini2018-05-071-2/+1
| | | | | | | | | | | | | | | | | | | | 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>
* distro bootcmd: Allow board defined UBI partition and volume namesDerald D. Woods2018-01-281-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* distro bootcmd: define bootloader name for x86Heinrich Schuchardt2017-11-301-0/+4
| | | | | | | | | | | | | | | 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>
* efi_loader: add bootmgrRob Clark2017-09-201-0/+5
| | | | | | | | | | | | | | | 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>
* Kconfig: Drop CONFIG_CMD_PCI_ENUMSimon Glass2017-08-111-1/+1
| | | | | | | | | | | | | 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>
* Kconfig: Add CONFIG_SATA to enable SATASimon Glass2017-07-111-3/+3
| | | | | | | | | 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>
* Kconfig: Add a CONFIG_IDE optionSimon Glass2017-05-221-3/+3
| | | | | | | | | | | 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>
* cmd, disk: convert CONFIG_PARTITION_UUIDS, CMD_PART and CMD_GPTPatrick Delaunay2017-01-281-4/+0
| | | | | | | | | | | 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>
* efi_loader: Fix typo in distro scriptAlexander Graf2016-06-241-1/+1
| | | | | | | | | | | 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>
* distro: Add efi pxe boot codeAlexander Graf2016-05-271-1/+46
| | | | | | | | | | | | | | | | | | 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>
* dm: scsi: Rename CONFIG_CMD_SCSI to CONFIG_SCSISimon Glass2016-05-171-3/+3
| | | | | | | | 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>
* efi_loader: Fall back to fdtfile naming conventionAlexander Graf2016-04-181-3/+21
| | | | | | | | | | | | | 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>
* efi_loader: Pass fdt address directly to bootefi cmdAlexander Graf2016-04-181-3/+6
| | | | | | | | | | | | | | | 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>
* arm64: Replace fdt_name env variables with fdtfileAlexander Graf2016-03-151-2/+2
| | | | | | | | 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>
* efi_loader: Add distro boot script for removable mediaAlexander Graf2016-03-151-1/+46
| | | | | | | | | | | | | | | | | | 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>
* distro bootcmd: enumerate PCI before network operationsStephen Warren2016-01-281-0/+12
| | | | | | | | | 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>
* distro bootcmd: make net boot only optionally start USBStephen Warren2016-01-281-5/+6
| | | | | | | | | | | | | | | | | | | 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>
* distro_bootcmd: Add support for booting from ubifsRoy Spliet2015-10-241-0/+19
| | | | | | | | | 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>
* config_distro_bootcmd.h: Use a private variable for bootpartSjoerd Simons2015-10-221-7/+11
| | | | | | | | | | | | | | 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>
* config_distro_bootcmd.h: Add shared block definition for the host interfaceSjoerd Simons2015-04-191-0/+13
| | | | | | | | | 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>
* config_distro_bootcmd.h: Prefer booting from bootable paritionsSjoerd Simons2015-03-251-1/+2
| | | | | | | | | 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>
* config_distro_bootcmd.h: add note on error handlingStephen Warren2015-03-131-0/+16
| | | | | | | | | | | 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>
* config_distro_bootcmd.h: Enable CONFIG_CMD_PARTHans de Goede2015-02-161-0/+4
| | | | | | | | | | 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>
* distro_bootcmd: read DHCP boot script name from a variableStephen Warren2015-01-301-1/+2
| | | | | | | | | 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>
* distro_distro_bootcmd: use CONFIG_BOOTCOMMAND instead of setting bootcmd=Sjoerd Simons2015-01-291-1/+5
| | | | | | | | | | | | | | | 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>
* config_distro_bootcmd: Scan all partitions for boot filesSjoerd Simons2015-01-291-3/+11
| | | | | | | | | | | 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>
* config_distro_bootcmd.h: Remove unnecessary magic to avoid repeated USB scansHans de Goede2015-01-181-10/+2
| | | | | | | | 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>
* config_distro_bootcmd: Run 'scsi scan' before trying scsi disksHans de Goede2014-09-241-2/+15
| | | | | | | | | | 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>
* config: introduce a generic $bootcmdDennis Gilmore2014-08-091-0/+197
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>
generated by cgit (git 2.34.1) at 2024-11-17 11:58:49 +0000