Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-14 08:57:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/include/config_distro_bootcmd.h

544 lines
20 KiB
C
Raw Normal View History

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-06 21:58:06 +00:00
/* SPDX-License-Identifier: GPL-2.0+ */
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-07-30 22:37:14 +00:00
/*
* (C) Copyright 2014
* NVIDIA Corporation <www.nvidia.com>
*
* Copyright 2014 Red Hat, Inc.
*/
#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
#define _CONFIG_CMD_DISTRO_BOOTCMD_H
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-10 21:40:58 +00:00
/*
* A note on error handling: It is possible for BOOT_TARGET_DEVICES to
* reference a device that is not enabled in the U-Boot configuration, e.g.
* it may include MMC in the list without CONFIG_CMD_MMC being enabled. Given
* that BOOT_TARGET_DEVICES is a macro that's expanded by the C pre-processor
* at compile time, it's not possible to detect and report such problems via
* a simple #ifdef/#error combination. Still, the code needs to report errors.
* The best way I've found to do this is to make BOOT_TARGET_DEVICES expand to
* reference a non-existent symbol, and have the name of that symbol encode
* the error message. Consequently, this file contains references to e.g.
* BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC. Given the
* prevalence of capitals here, this looks like a pre-processor macro and
* hence seems like it should be all capitals, but it's really an error
* message that includes some other pre-processor symbols in the text.
*/
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-07-30 22:37:14 +00:00
#define BOOTENV_SHARED_BLKDEV_BODY(devtypel) \
"if " #devtypel " dev ${devnum}; then " \
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>
2018-12-04 06:46:55 +00:00
"devtype=" #devtypel "; " \
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-05 17:13:38 +00:00
"run scan_dev_for_boot_part; " \
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-07-30 22:37:14 +00:00
"fi\0"
#define BOOTENV_SHARED_BLKDEV(devtypel) \
#devtypel "_boot=" \
BOOTENV_SHARED_BLKDEV_BODY(devtypel)
#define BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance) \
"bootcmd_" #devtypel #instance "=" \
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>
2018-12-04 06:46:55 +00:00
"devnum=" #instance "; " \
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-07-30 22:37:14 +00:00
"run " #devtypel "_boot\0"
#define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \
#devtypel #instance " "
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-13 20:54:24 +00:00
#ifdef CONFIG_SANDBOX
#define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host)
#define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_HOST BOOTENV_DEV_NAME_BLKDEV
#else
#define BOOTENV_SHARED_HOST
#define BOOTENV_DEV_HOST \
BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX
#define BOOTENV_DEV_NAME_HOST \
BOOT_TARGET_DEVICES_references_HOST_without_CONFIG_SANDBOX
#endif
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-07-30 22:37:14 +00:00
#ifdef CONFIG_CMD_MMC
#define BOOTENV_SHARED_MMC BOOTENV_SHARED_BLKDEV(mmc)
#define BOOTENV_DEV_MMC BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_MMC BOOTENV_DEV_NAME_BLKDEV
#else
#define BOOTENV_SHARED_MMC
#define BOOTENV_DEV_MMC \
BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC
#define BOOTENV_DEV_NAME_MMC \
BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC
#endif
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-09-17 22:46:59 +00:00
#ifdef CONFIG_CMD_UBIFS
#define BOOTENV_SHARED_UBIFS \
"ubifs_boot=" \
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-07 19:04:22 +00:00
"if ubi part ${bootubipart} ${bootubioff} && " \
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-05-31 08:32:36 +00:00
"ubifsmount ubi0:${bootubivol}; " \
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-21 03:16:13 +00:00
"then " \
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>
2018-12-04 06:46:55 +00:00
"devtype=ubi; " \
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-05-31 08:32:36 +00:00
"devnum=ubi0; " \
"bootfstype=ubifs; " \
"distro_bootpart=${bootubivol}; " \
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-21 03:16:13 +00:00
"run scan_dev_for_boot; " \
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-05-31 08:32:36 +00:00
"ubifsumount; " \
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-09-17 22:46:59 +00:00
"fi\0"
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-07 19:04:22 +00:00
#define BOOTENV_DEV_UBIFS_BOOTUBIOFF(off) #off /* type check, throw error when called with more args */
#define BOOTENV_DEV_UBIFS(devtypeu, devtypel, instance, bootubipart, bootubivol, ...) \
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-05-31 08:32:36 +00:00
"bootcmd_ubifs" #instance "=" \
"bootubipart=" #bootubipart "; " \
"bootubivol=" #bootubivol "; " \
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-07 19:04:22 +00:00
"bootubioff=" BOOTENV_DEV_UBIFS_BOOTUBIOFF(__VA_ARGS__) "; " \
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-05-31 08:32:36 +00:00
"run ubifs_boot\0"
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-07 19:04:22 +00:00
#define BOOTENV_DEV_NAME_UBIFS(devtypeu, devtypel, instance, ...) \
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-05-31 08:32:36 +00:00
#devtypel #instance " "
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-09-17 22:46:59 +00:00
#else
#define BOOTENV_SHARED_UBIFS
#define BOOTENV_DEV_UBIFS \
BOOT_TARGET_DEVICES_references_UBIFS_without_CONFIG_CMD_UBIFS
#define BOOTENV_DEV_NAME_UBIFS \
BOOT_TARGET_DEVICES_references_UBIFS_without_CONFIG_CMD_UBIFS
#endif
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-09 23:26:15 +00:00
#ifdef CONFIG_EFI_LOADER
#if defined(CONFIG_ARM64)
#define BOOTEFI_NAME "bootaa64.efi"
#elif defined(CONFIG_ARM)
#define BOOTEFI_NAME "bootarm.efi"
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-24 21:32:35 +00:00
#elif defined(CONFIG_X86_RUN_32BIT)
#define BOOTEFI_NAME "bootia32.efi"
#elif defined(CONFIG_X86_RUN_64BIT)
#define BOOTEFI_NAME "bootx64.efi"
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-22 10:26:12 +00:00
#elif defined(CONFIG_ARCH_RV32I)
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-04-23 05:59:48 +00:00
#define BOOTEFI_NAME "bootriscv32.efi"
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-22 10:26:12 +00:00
#elif defined(CONFIG_ARCH_RV64I)
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-04-23 05:59:48 +00:00
#define BOOTEFI_NAME "bootriscv64.efi"
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-09 23:26:15 +00:00
#endif
#endif
#ifdef BOOTEFI_NAME
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-14 14:07:54 +00:00
#if defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
/*
* On 32bit ARM systems there is a reasonable number of systems that follow
* the $soc-$board$boardver.dtb name scheme for their device trees. Use that
* scheme if we don't have an explicit fdtfile variable.
*/
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK \
"if test -z \"${fdtfile}\" -a -n \"${soc}\"; then " \
"setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; " \
"fi; "
#else
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-04-01 23:28:55 +00:00
#ifndef BOOTENV_EFI_SET_FDTFILE_FALLBACK
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-14 14:07:54 +00:00
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK
#endif
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-04-01 23:28:55 +00:00
#endif
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-14 14:07:54 +00:00
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-15 18:02:50 +00:00
#ifdef CONFIG_CMD_BOOTEFI_BOOTMGR
#define BOOTENV_EFI_BOOTMGR \
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-09-29 06:54:48 +00:00
"boot_efi_bootmgr=" \
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-03-31 10:53:22 +00:00
"if fdt addr -q ${fdt_addr_r}; then " \
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-13 22:05:38 +00:00
"bootefi bootmgr ${fdt_addr_r};" \
"else " \
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-09-29 06:54:48 +00:00
"bootefi bootmgr;" \
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-15 18:02:50 +00:00
"fi\0"
#else
#define BOOTENV_EFI_BOOTMGR
#endif
#define BOOTENV_SHARED_EFI \
BOOTENV_EFI_BOOTMGR \
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-09-29 06:54:48 +00:00
\
"boot_efi_binary=" \
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-09 23:26:15 +00:00
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${kernel_addr_r} efi/boot/"BOOTEFI_NAME"; " \
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-03-31 10:53:22 +00:00
"if fdt addr -q ${fdt_addr_r}; then " \
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-14 14:07:53 +00:00
"bootefi ${kernel_addr_r} ${fdt_addr_r};" \
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-21 03:16:13 +00:00
"else " \
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-14 14:07:53 +00:00
"bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
"fi\0" \
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-09 23:26:15 +00:00
\
"load_efi_dtb=" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
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-14 14:07:54 +00:00
"${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
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-09 23:26:15 +00:00
\
"efi_dtb_prefixes=/ /dtb/ /dtb/current/\0" \
"scan_dev_for_efi=" \
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-14 14:07:54 +00:00
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
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-08-09 15:54:07 +00:00
BOOTENV_RUN_EXTENSION_INIT \
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-09 23:26:15 +00:00
"for prefix in ${efi_dtb_prefixes}; do " \
"if test -e ${devtype} " \
"${devnum}:${distro_bootpart} " \
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-14 14:07:54 +00:00
"${prefix}${efi_fdtfile}; then " \
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-09 23:26:15 +00:00
"run load_efi_dtb; " \
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-08-09 15:54:07 +00:00
BOOTENV_RUN_EXTENSION_APPLY \
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-09 23:26:15 +00:00
"fi;" \
"done;" \
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-09-29 06:54:48 +00:00
"run boot_efi_bootmgr;" \
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-09 23:26:15 +00:00
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then " \
"echo Found EFI removable media binary " \
"efi/boot/"BOOTEFI_NAME"; " \
"run boot_efi_binary; " \
"echo EFI LOAD FAILED: continuing...; " \
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-14 14:07:54 +00:00
"fi; " \
"setenv efi_fdtfile\0"
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-09 23:26:15 +00:00
#define SCAN_DEV_FOR_EFI "run scan_dev_for_efi;"
#else
#define BOOTENV_SHARED_EFI
#define SCAN_DEV_FOR_EFI
#endif
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-06-15 03:28:25 +00:00
#ifdef CONFIG_SATA
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-07-30 22:37:14 +00:00
#define BOOTENV_SHARED_SATA BOOTENV_SHARED_BLKDEV(sata)
#define BOOTENV_DEV_SATA BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_SATA BOOTENV_DEV_NAME_BLKDEV
#else
#define BOOTENV_SHARED_SATA
#define BOOTENV_DEV_SATA \
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-06-15 03:28:25 +00:00
BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_SATA
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-07-30 22:37:14 +00:00
#define BOOTENV_DEV_NAME_SATA \
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-06-15 03:28:25 +00:00
BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_SATA
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-07-30 22:37:14 +00:00
#endif
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>
2018-12-21 01:18:16 +00:00
#ifdef CONFIG_NVME
#define BOOTENV_RUN_NVME_INIT "run nvme_init; "
#define BOOTENV_SET_NVME_NEED_INIT "setenv nvme_need_init; "
#define BOOTENV_SHARED_NVME \
"nvme_init=" \
"if ${nvme_need_init}; then " \
"setenv nvme_need_init false; " \
"nvme scan; " \
"fi\0" \
\
"nvme_boot=" \
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-03 09:10:57 +00:00
BOOTENV_RUN_PCI_ENUM \
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>
2018-12-21 01:18:16 +00:00
BOOTENV_RUN_NVME_INIT \
BOOTENV_SHARED_BLKDEV_BODY(nvme)
#define BOOTENV_DEV_NVME BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_NVME BOOTENV_DEV_NAME_BLKDEV
#else
#define BOOTENV_RUN_NVME_INIT
#define BOOTENV_SET_NVME_NEED_INIT
#define BOOTENV_SHARED_NVME
#define BOOTENV_DEV_NVME \
BOOT_TARGET_DEVICES_references_NVME_without_CONFIG_NVME
#define BOOTENV_DEV_NAME_NVME \
BOOT_TARGET_DEVICES_references_NVME_without_CONFIG_NVME
#endif
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-01 17:36:02 +00:00
#ifdef CONFIG_SCSI
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-16 07:26:23 +00:00
#define BOOTENV_RUN_SCSI_INIT "run scsi_init; "
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>
2018-12-04 06:46:55 +00:00
#define BOOTENV_SET_SCSI_NEED_INIT "scsi_need_init=; "
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-16 07:26:23 +00:00
#define BOOTENV_SHARED_SCSI \
"scsi_init=" \
"if ${scsi_need_init}; then " \
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>
2018-12-04 06:46:55 +00:00
"scsi_need_init=false; " \
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-16 07:26:23 +00:00
"scsi scan; " \
"fi\0" \
\
"scsi_boot=" \
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-09-17 07:37:05 +00:00
BOOTENV_RUN_PCI_ENUM \
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-16 07:26:23 +00:00
BOOTENV_RUN_SCSI_INIT \
BOOTENV_SHARED_BLKDEV_BODY(scsi)
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-07-30 22:37:14 +00:00
#define BOOTENV_DEV_SCSI BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_SCSI BOOTENV_DEV_NAME_BLKDEV
#else
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-16 07:26:23 +00:00
#define BOOTENV_RUN_SCSI_INIT
#define BOOTENV_SET_SCSI_NEED_INIT
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-07-30 22:37:14 +00:00
#define BOOTENV_SHARED_SCSI
#define BOOTENV_DEV_SCSI \
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-01 17:36:02 +00:00
BOOT_TARGET_DEVICES_references_SCSI_without_CONFIG_SCSI
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-07-30 22:37:14 +00:00
#define BOOTENV_DEV_NAME_SCSI \
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-01 17:36:02 +00:00
BOOT_TARGET_DEVICES_references_SCSI_without_CONFIG_SCSI
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-07-30 22:37:14 +00:00
#endif
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-17 09:25:30 +00:00
#ifdef CONFIG_IDE
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-20 21:31:35 +00:00
#define BOOTENV_RUN_IDE_INIT "run ide_init; "
#define BOOTENV_SET_IDE_NEED_INIT "setenv ide_need_init; "
#define BOOTENV_SHARED_IDE \
"ide_init=" \
"if ${ide_need_init}; then " \
"setenv ide_need_init false; " \
"ide reset; " \
"fi\0" \
\
"ide_boot=" \
BOOTENV_RUN_IDE_INIT \
BOOTENV_SHARED_BLKDEV_BODY(ide)
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-07-30 22:37:14 +00:00
#define BOOTENV_DEV_IDE BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_IDE BOOTENV_DEV_NAME_BLKDEV
#else
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-20 21:31:35 +00:00
#define BOOTENV_RUN_IDE_INIT
#define BOOTENV_SET_IDE_NEED_INIT
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-07-30 22:37:14 +00:00
#define BOOTENV_SHARED_IDE
#define BOOTENV_DEV_IDE \
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-17 09:25:30 +00:00
BOOT_TARGET_DEVICES_references_IDE_without_CONFIG_IDE
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-07-30 22:37:14 +00:00
#define BOOTENV_DEV_NAME_IDE \
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-17 09:25:30 +00:00
BOOT_TARGET_DEVICES_references_IDE_without_CONFIG_IDE
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-07-30 22:37:14 +00:00
#endif
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-02 00:54:38 +00:00
#if defined(CONFIG_PCI)
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-22 08:38:11 +00:00
#define BOOTENV_RUN_PCI_ENUM "run boot_pci_enum; "
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-26 18:10:13 +00:00
#define BOOTENV_SHARED_PCI \
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-22 08:38:11 +00:00
"boot_pci_enum=pci enum\0"
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-26 18:10:13 +00:00
#else
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-22 08:38:11 +00:00
#define BOOTENV_RUN_PCI_ENUM
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-26 18:10:13 +00:00
#define BOOTENV_SHARED_PCI
#endif
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-07-30 22:37:14 +00:00
#ifdef CONFIG_CMD_USB
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-26 18:10:12 +00:00
#define BOOTENV_RUN_NET_USB_START "run boot_net_usb_start; "
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-07-30 22:37:14 +00:00
#define BOOTENV_SHARED_USB \
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-26 18:10:12 +00:00
"boot_net_usb_start=usb start\0" \
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-07-30 22:37:14 +00:00
"usb_boot=" \
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-26 18:10:12 +00:00
"usb start; " \
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-07-30 22:37:14 +00:00
BOOTENV_SHARED_BLKDEV_BODY(usb)
#define BOOTENV_DEV_USB BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_USB BOOTENV_DEV_NAME_BLKDEV
#else
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-26 18:10:12 +00:00
#define BOOTENV_RUN_NET_USB_START
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-07-30 22:37:14 +00:00
#define BOOTENV_SHARED_USB
#define BOOTENV_DEV_USB \
BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
#define BOOTENV_DEV_NAME_USB \
BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB
#endif
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-22 10:26:33 +00:00
#ifdef CONFIG_CMD_VIRTIO
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-22 08:38:11 +00:00
#define BOOTENV_RUN_VIRTIO_INIT "run virtio_init; "
#define BOOTENV_SET_VIRTIO_NEED_INIT "virtio_need_init=; "
#define BOOTENV_SHARED_VIRTIO \
"virtio_init=" \
"if ${virtio_need_init}; then " \
"virtio_need_init=false; " \
"virtio scan; " \
"fi\0" \
\
"virtio_boot=" \
BOOTENV_RUN_PCI_ENUM \
BOOTENV_RUN_VIRTIO_INIT \
BOOTENV_SHARED_BLKDEV_BODY(virtio)
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-22 10:26:33 +00:00
#define BOOTENV_DEV_VIRTIO BOOTENV_DEV_BLKDEV
#define BOOTENV_DEV_NAME_VIRTIO BOOTENV_DEV_NAME_BLKDEV
#else
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-22 08:38:11 +00:00
#define BOOTENV_RUN_VIRTIO_INIT
#define BOOTENV_SET_VIRTIO_NEED_INIT
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-22 10:26:33 +00:00
#define BOOTENV_SHARED_VIRTIO
#define BOOTENV_DEV_VIRTIO \
BOOT_TARGET_DEVICES_references_VIRTIO_without_CONFIG_CMD_VIRTIO
#define BOOTENV_DEV_NAME_VIRTIO \
BOOT_TARGET_DEVICES_references_VIRTIO_without_CONFIG_CMD_VIRTIO
#endif
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-07-30 22:37:14 +00:00
#if defined(CONFIG_CMD_DHCP)
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-06 19:01:07 +00:00
#if defined(CONFIG_EFI_LOADER)
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-04-23 05:59:48 +00:00
/* http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml */
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-15 06:50:52 +00:00
#if defined(CONFIG_ARM64) || defined(__aarch64__)
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-06 19:01:07 +00:00
#define BOOTENV_EFI_PXE_ARCH "0xb"
#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00011:UNDI:003000"
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-15 06:50:52 +00:00
#elif defined(CONFIG_ARM) || defined(__arm__)
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-06 19:01:07 +00:00
#define BOOTENV_EFI_PXE_ARCH "0xa"
#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00010:UNDI:003000"
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-15 06:50:52 +00:00
#elif defined(CONFIG_X86) || defined(__x86_64__)
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-06 19:01:07 +00:00
#define BOOTENV_EFI_PXE_ARCH "0x7"
#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00007:UNDI:003000"
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-15 06:50:52 +00:00
#elif defined(__i386__)
#define BOOTENV_EFI_PXE_ARCH "0x6"
#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00006:UNDI:003000"
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-22 10:26:12 +00:00
#elif defined(CONFIG_ARCH_RV32I) || ((defined(__riscv) && __riscv_xlen == 32))
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-04-23 05:59:48 +00:00
#define BOOTENV_EFI_PXE_ARCH "0x19"
#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00025:UNDI:003000"
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-22 10:26:12 +00:00
#elif defined(CONFIG_ARCH_RV64I) || ((defined(__riscv) && __riscv_xlen == 64))
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-04-23 05:59:48 +00:00
#define BOOTENV_EFI_PXE_ARCH "0x1b"
#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000"
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-15 06:50:52 +00:00
#elif defined(CONFIG_SANDBOX)
# error "sandbox EFI support is only supported on ARM and x86"
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-06 19:01:07 +00:00
#else
#error Please specify an EFI client identifier
#endif
/*
* Ask the dhcp server for an EFI binary. If we get one, check for a
* device tree in the same folder. Then boot everything. If the file was
* not an EFI binary, we just return from the bootefi command and continue.
*/
#define BOOTENV_EFI_RUN_DHCP \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK \
"setenv efi_old_vci ${bootp_vci};" \
"setenv efi_old_arch ${bootp_arch};" \
"setenv bootp_vci " BOOTENV_EFI_PXE_VCI ";" \
"setenv bootp_arch " BOOTENV_EFI_PXE_ARCH ";" \
"if dhcp ${kernel_addr_r}; then " \
"tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};" \
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-03-31 10:53:22 +00:00
"if fdt addr -q ${fdt_addr_r}; then " \
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-06 19:01:07 +00:00
"bootefi ${kernel_addr_r} ${fdt_addr_r}; " \
"else " \
"bootefi ${kernel_addr_r} ${fdtcontroladdr};" \
"fi;" \
"fi;" \
"setenv bootp_vci ${efi_old_vci};" \
"setenv bootp_arch ${efi_old_arch};" \
"setenv efi_fdtfile;" \
"setenv efi_old_arch;" \
"setenv efi_old_vci;"
#else
#define BOOTENV_EFI_RUN_DHCP
#endif
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-07-30 22:37:14 +00:00
#define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
"bootcmd_dhcp=" \
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-11 23:07:09 +00:00
"devtype=" #devtypel "; " \
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-26 18:10:12 +00:00
BOOTENV_RUN_NET_USB_START \
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-22 08:38:11 +00:00
BOOTENV_RUN_PCI_ENUM \
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-19 23:39:11 +00:00
"if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
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-07-30 22:37:14 +00:00
"source ${scriptaddr}; " \
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-06 19:01:07 +00:00
"fi;" \
BOOTENV_EFI_RUN_DHCP \
"\0"
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-07-30 22:37:14 +00:00
#define BOOTENV_DEV_NAME_DHCP(devtypeu, devtypel, instance) \
"dhcp "
#else
#define BOOTENV_DEV_DHCP \
BOOT_TARGET_DEVICES_references_DHCP_without_CONFIG_CMD_DHCP
#define BOOTENV_DEV_NAME_DHCP \
BOOT_TARGET_DEVICES_references_DHCP_without_CONFIG_CMD_DHCP
#endif
#if defined(CONFIG_CMD_DHCP) && defined(CONFIG_CMD_PXE)
#define BOOTENV_DEV_PXE(devtypeu, devtypel, instance) \
"bootcmd_pxe=" \
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-26 18:10:12 +00:00
BOOTENV_RUN_NET_USB_START \
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-22 08:38:11 +00:00
BOOTENV_RUN_PCI_ENUM \
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-07-30 22:37:14 +00:00
"dhcp; " \
"if pxe get; then " \
"pxe boot; " \
"fi\0"
#define BOOTENV_DEV_NAME_PXE(devtypeu, devtypel, instance) \
"pxe "
#else
#define BOOTENV_DEV_PXE \
BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
#define BOOTENV_DEV_NAME_PXE \
BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
#endif
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-08-09 15:54:07 +00:00
#if defined(CONFIG_CMD_EXTENSION)
#define BOOTENV_RUN_EXTENSION_INIT "run extension_init; "
#define BOOTENV_RUN_EXTENSION_APPLY "run extension_apply; "
#define BOOTENV_SET_EXTENSION_NEED_INIT \
"extension_need_init=; " \
"setenv extension_overlay_addr ${fdtoverlay_addr_r}; "
#define BOOTENV_SHARED_EXTENSION \
"extension_init=" \
"echo Extension init...; " \
"if ${extension_need_init}; then " \
"extension_need_init=false; " \
"extension scan; " \
"fi\0" \
\
"extension_overlay_cmd=" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${extension_overlay_addr} ${prefix}${extension_overlay_name}\0" \
"extension_apply=" \
"if fdt addr -q ${fdt_addr_r}; then " \
"extension apply all; " \
"fi\0"
#else
#define BOOTENV_RUN_EXTENSION_INIT
#define BOOTENV_RUN_EXTENSION_APPLY
#define BOOTENV_SET_EXTENSION_NEED_INIT
#define BOOTENV_SHARED_EXTENSION
#endif
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-05-31 08:32:36 +00:00
#define BOOTENV_DEV_NAME(devtypeu, devtypel, instance, ...) \
BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance, ## __VA_ARGS__)
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-07-30 22:37:14 +00:00
#define BOOTENV_BOOT_TARGETS \
"boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
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-05-31 08:32:36 +00:00
#define BOOTENV_DEV(devtypeu, devtypel, instance, ...) \
BOOTENV_DEV_##devtypeu(devtypeu, devtypel, instance, ## __VA_ARGS__)
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-07-30 22:37:14 +00:00
#define BOOTENV \
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-13 20:54:24 +00:00
BOOTENV_SHARED_HOST \
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-07-30 22:37:14 +00:00
BOOTENV_SHARED_MMC \
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-26 18:10:13 +00:00
BOOTENV_SHARED_PCI \
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-07-30 22:37:14 +00:00
BOOTENV_SHARED_USB \
BOOTENV_SHARED_SATA \
BOOTENV_SHARED_SCSI \
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>
2018-12-21 01:18:16 +00:00
BOOTENV_SHARED_NVME \
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-07-30 22:37:14 +00:00
BOOTENV_SHARED_IDE \
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-09-17 22:46:59 +00:00
BOOTENV_SHARED_UBIFS \
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-09 23:26:15 +00:00
BOOTENV_SHARED_EFI \
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-22 10:26:33 +00:00
BOOTENV_SHARED_VIRTIO \
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-08-09 15:54:07 +00:00
BOOTENV_SHARED_EXTENSION \
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-07-30 22:37:14 +00:00
"boot_prefixes=/ /boot/\0" \
"boot_scripts=boot.scr.uimg boot.scr\0" \
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-19 23:39:11 +00:00
"boot_script_dhcp=boot.scr.uimg\0" \
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-07-30 22:37:14 +00:00
BOOTENV_BOOT_TARGETS \
\
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-06 12:23:53 +00:00
"boot_syslinux_conf=extlinux/extlinux.conf\0" \
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-07-30 22:37:14 +00:00
"boot_extlinux=" \
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-08-28 13:01:54 +00:00
"sysboot ${devtype} ${devnum}:${distro_bootpart} any " \
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-06 12:23:53 +00:00
"${scriptaddr} ${prefix}${boot_syslinux_conf}\0" \
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-07-30 22:37:14 +00:00
\
"scan_dev_for_extlinux=" \
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-08-28 13:01:54 +00:00
"if test -e ${devtype} " \
"${devnum}:${distro_bootpart} " \
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-06 12:23:53 +00:00
"${prefix}${boot_syslinux_conf}; then " \
"echo Found ${prefix}${boot_syslinux_conf}; " \
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-07-30 22:37:14 +00:00
"run boot_extlinux; " \
distro_bootcmd: Fix copy-paste error 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>
2023-01-05 01:26:03 +00:00
"echo EXTLINUX FAILED: continuing...; " \
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-07-30 22:37:14 +00:00
"fi\0" \
\
"boot_a_script=" \
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-08-28 13:01:54 +00:00
"load ${devtype} ${devnum}:${distro_bootpart} " \
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-07-30 22:37:14 +00:00
"${scriptaddr} ${prefix}${script}; " \
"source ${scriptaddr}\0" \
\
"scan_dev_for_scripts=" \
"for script in ${boot_scripts}; do " \
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-08-28 13:01:54 +00:00
"if test -e ${devtype} " \
"${devnum}:${distro_bootpart} " \
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-07-30 22:37:14 +00:00
"${prefix}${script}; then " \
"echo Found U-Boot script " \
"${prefix}${script}; " \
"run boot_a_script; " \
"echo SCRIPT FAILED: continuing...; " \
"fi; " \
"done\0" \
\
"scan_dev_for_boot=" \
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-08-28 13:01:54 +00:00
"echo Scanning ${devtype} " \
"${devnum}:${distro_bootpart}...; " \
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-07-30 22:37:14 +00:00
"for prefix in ${boot_prefixes}; do " \
"run scan_dev_for_extlinux; " \
"run scan_dev_for_scripts; " \
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-09 23:26:15 +00:00
"done;" \
SCAN_DEV_FOR_EFI \
"\0" \
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-07-30 22:37:14 +00:00
\
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-05 17:13:38 +00:00
"scan_dev_for_boot_part=" \
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-02-25 22:23:52 +00:00
"part list ${devtype} ${devnum} -bootable devplist; " \
"env exists devplist || setenv devplist 1; " \
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-08-28 13:01:54 +00:00
"for distro_bootpart in ${devplist}; do " \
"if fstype ${devtype} " \
"${devnum}:${distro_bootpart} " \
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-05 17:13:38 +00:00
"bootfstype; then " \
distro_bootcmd: Set distro_bootpart_uuid for block devices 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>
2023-01-05 13:08:23 +00:00
"part uuid ${devtype} " \
"${devnum}:${distro_bootpart} " \
"distro_bootpart_uuid ; " \
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-05 17:13:38 +00:00
"run scan_dev_for_boot; " \
"fi; " \
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>
2018-12-04 06:46:55 +00:00
"done; " \
"setenv devplist\0" \
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-05 17:13:38 +00:00
\
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-07-30 22:37:14 +00:00
BOOT_TARGET_DEVICES(BOOTENV_DEV) \
\
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-05 17:13:39 +00:00
"distro_bootcmd=" BOOTENV_SET_SCSI_NEED_INIT \
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>
2018-12-21 01:18:16 +00:00
BOOTENV_SET_NVME_NEED_INIT \
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-20 21:31:35 +00:00
BOOTENV_SET_IDE_NEED_INIT \
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-22 08:38:11 +00:00
BOOTENV_SET_VIRTIO_NEED_INIT \
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-08-09 15:54:07 +00:00
BOOTENV_SET_EXTENSION_NEED_INIT \
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-07-30 22:37:14 +00:00
"for target in ${boot_targets}; do " \
"run bootcmd_${target}; " \
"done\0"
#endif /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
Reference in a new issue Copy permalink