[PATCH 1/3] config: introduce a generic $bootcmd

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PATCH 1/3] config: introduce a generic $bootcmd

Stephen Warren-2
From: Dennis Gilmore <[hidden email]>

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 <[hidden email]>
Signed-off-by: Stephen Warren <[hidden email]>
---
 include/config_distro_bootcmd.h | 197 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 197 insertions(+)
 create mode 100644 include/config_distro_bootcmd.h

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
new file mode 100644
index 000000000000..90d990157f63
--- /dev/null
+++ b/include/config_distro_bootcmd.h
@@ -0,0 +1,197 @@
+/*
+ * (C) Copyright 2014
+ * NVIDIA Corporation <www.nvidia.com>
+ *
+ * Copyright 2014 Red Hat, Inc.
+ *
+ * SPDX-License-Identifier:     GPL-2.0+
+ */
+
+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
+#define _CONFIG_CMD_DISTRO_BOOTCMD_H
+
+#define BOOTENV_SHARED_BLKDEV_BODY(devtypel) \
+ "if " #devtypel " dev ${devnum}; then " \
+ "setenv devtype " #devtypel "; " \
+ "run scan_dev_for_boot; " \
+ "fi\0"
+
+#define BOOTENV_SHARED_BLKDEV(devtypel) \
+ #devtypel "_boot=" \
+ BOOTENV_SHARED_BLKDEV_BODY(devtypel)
+
+#define BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance) \
+ "bootcmd_" #devtypel #instance "=" \
+ "setenv devnum " #instance "; " \
+ "run " #devtypel "_boot\0"
+
+#define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \
+ #devtypel #instance " "
+
+#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
+
+#ifdef CONFIG_CMD_SATA
+#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 \
+ BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_CMD_SATA
+#define BOOTENV_DEV_NAME_SATA \
+ BOOT_TARGET_DEVICES_references_SATA_without_CONFIG_CMD_SATA
+#endif
+
+#ifdef CONFIG_CMD_SCSI
+#define BOOTENV_SHARED_SCSI BOOTENV_SHARED_BLKDEV(scsi)
+#define BOOTENV_DEV_SCSI BOOTENV_DEV_BLKDEV
+#define BOOTENV_DEV_NAME_SCSI BOOTENV_DEV_NAME_BLKDEV
+#else
+#define BOOTENV_SHARED_SCSI
+#define BOOTENV_DEV_SCSI \
+ BOOT_TARGET_DEVICES_references_SCSI_without_CONFIG_CMD_SCSI
+#define BOOTENV_DEV_NAME_SCSI \
+ BOOT_TARGET_DEVICES_references_SCSI_without_CONFIG_CMD_SCSI
+#endif
+
+#ifdef CONFIG_CMD_IDE
+#define BOOTENV_SHARED_IDE BOOTENV_SHARED_BLKDEV(ide)
+#define BOOTENV_DEV_IDE BOOTENV_DEV_BLKDEV
+#define BOOTENV_DEV_NAME_IDE BOOTENV_DEV_NAME_BLKDEV
+#else
+#define BOOTENV_SHARED_IDE
+#define BOOTENV_DEV_IDE \
+ BOOT_TARGET_DEVICES_references_IDE_without_CONFIG_CMD_IDE
+#define BOOTENV_DEV_NAME_IDE \
+ BOOT_TARGET_DEVICES_references_IDE_without_CONFIG_CMD_IDE
+#endif
+
+#ifdef CONFIG_CMD_USB
+#define BOOTENV_RUN_USB_INIT "run usb_init; "
+#define BOOTENV_SET_USB_NEED_INIT "setenv usb_need_init; "
+#define BOOTENV_SHARED_USB \
+ "usb_init=" \
+ "if ${usb_need_init}; then " \
+ "setenv usb_need_init false; " \
+ "usb start 0; " \
+ "fi\0" \
+ \
+ "usb_boot=" \
+ BOOTENV_RUN_USB_INIT \
+ BOOTENV_SHARED_BLKDEV_BODY(usb)
+#define BOOTENV_DEV_USB BOOTENV_DEV_BLKDEV
+#define BOOTENV_DEV_NAME_USB BOOTENV_DEV_NAME_BLKDEV
+#else
+#define BOOTENV_RUN_USB_INIT
+#define BOOTENV_SET_USB_NEED_INIT
+#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
+
+#if defined(CONFIG_CMD_DHCP)
+#define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \
+ "bootcmd_dhcp=" \
+ BOOTENV_RUN_USB_INIT \
+ "if dhcp ${scriptaddr} boot.scr.uimg; then " \
+ "source ${scriptaddr}; " \
+ "fi\0"
+#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=" \
+ BOOTENV_RUN_USB_INIT \
+ "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
+
+#define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \
+ BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance)
+#define BOOTENV_BOOT_TARGETS \
+ "boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
+
+#define BOOTENV_DEV(devtypeu, devtypel, instance) \
+ BOOTENV_DEV_##devtypeu(devtypeu, devtypel, instance)
+#define BOOTENV \
+ BOOTENV_SHARED_MMC \
+ BOOTENV_SHARED_USB \
+ BOOTENV_SHARED_SATA \
+ BOOTENV_SHARED_SCSI \
+ BOOTENV_SHARED_IDE \
+ "boot_prefixes=/ /boot/\0" \
+ "boot_scripts=boot.scr.uimg boot.scr\0" \
+ BOOTENV_BOOT_TARGETS \
+ "bootpart=1\0" \
+ \
+ "boot_extlinux="                                                  \
+ "sysboot ${devtype} ${devnum}:${bootpart} any "           \
+ "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \
+ \
+ "scan_dev_for_extlinux="                                          \
+ "if test -e ${devtype} ${devnum}:${bootpart} "            \
+ "${prefix}extlinux/extlinux.conf; then "  \
+ "echo Found ${prefix}extlinux/extlinux.conf; "    \
+ "run boot_extlinux; "                             \
+ "echo SCRIPT FAILED: continuing...; "             \
+ "fi\0"                                                    \
+ \
+ "boot_a_script="                                                  \
+ "load ${devtype} ${devnum}:${bootpart} "                  \
+ "${scriptaddr} ${prefix}${script}; "              \
+ "source ${scriptaddr}\0"                                  \
+ \
+ "scan_dev_for_scripts="                                           \
+ "for script in ${boot_scripts}; do "                      \
+ "if test -e ${devtype} ${devnum}:${bootpart} "    \
+ "${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="                                              \
+ "echo Scanning ${devtype} ${devnum}...; "                 \
+ "for prefix in ${boot_prefixes}; do "                     \
+ "run scan_dev_for_extlinux; "                     \
+ "run scan_dev_for_scripts; "                      \
+ "done\0"                                                  \
+ \
+ BOOT_TARGET_DEVICES(BOOTENV_DEV)                                  \
+ \
+ "bootcmd=" BOOTENV_SET_USB_NEED_INIT                              \
+ "for target in ${boot_targets}; do "                      \
+ "run bootcmd_${target}; "                         \
+ "done\0"
+
+#endif  /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
--
1.9.1

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

[PATCH 2/3] ARM: tegra: use new generic $bootcmd

Stephen Warren-2
From: Stephen Warren <[hidden email]>

Replace the custom $bootcmd with that from <config_distro_bootcmd.h>.
There should be no functional change, since the new generic $bootcmd was
derived strongly from tegra-common-post.h.

Signed-off-by: Stephen Warren <[hidden email]>
---
 include/configs/tegra-common-post.h | 140 +++---------------------------------
 1 file changed, 10 insertions(+), 130 deletions(-)

diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h
index 1c770c90feca..c337e3016e76 100644
--- a/include/configs/tegra-common-post.h
+++ b/include/configs/tegra-common-post.h
@@ -8,136 +8,16 @@
 #ifndef __TEGRA_COMMON_POST_H
 #define __TEGRA_COMMON_POST_H
 
-#ifdef CONFIG_BOOTCOMMAND
-
-#define BOOTCMDS_COMMON ""
-
-#else
-
-#ifdef CONFIG_CMD_MMC
-#define BOOTCMDS_MMC \
- "mmc_boot=" \
- "setenv devtype mmc; " \
- "if mmc dev ${devnum}; then " \
- "run scan_boot; " \
- "fi\0" \
- "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
- "bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
-#define BOOT_TARGETS_MMC "mmc1 mmc0"
+#ifndef CONFIG_SPL_BUILD
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 1) \
+ func(MMC, mmc, 0) \
+ func(USB, usb, 0) \
+ func(PXE, pxe, na) \
+ func(DHCP, dhcp, na)
+#include <config_distro_bootcmd.h>
 #else
-#define BOOTCMDS_MMC ""
-#define BOOT_TARGETS_MMC ""
-#endif
-
-#ifdef CONFIG_CMD_USB
-#define BOOTCMD_INIT_USB "run usb_init; "
-#define BOOTCMDS_USB \
- "usb_init=" \
- "if ${usb_need_init}; then " \
- "set usb_need_init false; " \
- "usb start 0; " \
- "fi\0" \
- \
- "usb_boot=" \
- "setenv devtype usb; " \
- BOOTCMD_INIT_USB \
- "if usb dev ${devnum}; then " \
- "run scan_boot; " \
- "fi\0" \
- \
- "bootcmd_usb0=setenv devnum 0; run usb_boot;\0"
-#define BOOT_TARGETS_USB "usb0"
-#else
-#define BOOTCMD_INIT_USB ""
-#define BOOTCMDS_USB ""
-#define BOOT_TARGETS_USB ""
-#endif
-
-#ifdef CONFIG_CMD_DHCP
-#define BOOTCMDS_DHCP \
- "bootcmd_dhcp=" \
- BOOTCMD_INIT_USB \
- "if dhcp ${scriptaddr} boot.scr.uimg; then "\
- "source ${scriptaddr}; " \
- "fi\0"
-#define BOOT_TARGETS_DHCP "dhcp"
-#else
-#define BOOTCMDS_DHCP ""
-#define BOOT_TARGETS_DHCP ""
-#endif
-
-#if defined(CONFIG_CMD_DHCP) && defined(CONFIG_CMD_PXE)
-#define BOOTCMDS_PXE \
- "bootcmd_pxe=" \
- BOOTCMD_INIT_USB \
- "dhcp; " \
- "if pxe get; then " \
- "pxe boot; " \
- "fi\0"
-#define BOOT_TARGETS_PXE "pxe"
-#else
-#define BOOTCMDS_PXE ""
-#define BOOT_TARGETS_PXE ""
-#endif
-
-#define BOOTCMDS_COMMON \
- "rootpart=1\0" \
- \
- "do_script_boot="                                                 \
- "load ${devtype} ${devnum}:${rootpart} "                  \
- "${scriptaddr} ${prefix}${script}; "              \
- "source ${scriptaddr}\0"                                  \
- \
- "script_boot="                                                    \
- "for script in ${boot_scripts}; do "                      \
- "if test -e ${devtype} ${devnum}:${rootpart} "    \
- "${prefix}${script}; then "       \
- "echo Found U-Boot script "               \
- "${prefix}${script}; "            \
- "run do_script_boot; "                    \
- "echo SCRIPT FAILED: continuing...; "     \
- "fi; "                                            \
- "done\0"                                                  \
- \
- "do_sysboot_boot="                                                \
- "sysboot ${devtype} ${devnum}:${rootpart} any "           \
- "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \
- \
- "sysboot_boot="                                                   \
- "if test -e ${devtype} ${devnum}:${rootpart} "            \
- "${prefix}extlinux/extlinux.conf; then "  \
- "echo Found ${prefix}extlinux/extlinux.conf; "    \
- "run do_sysboot_boot; "                           \
- "echo SCRIPT FAILED: continuing...; "             \
- "fi\0"                                                    \
- \
- "scan_boot="                                                      \
- "echo Scanning ${devtype} ${devnum}...; "                 \
- "for prefix in ${boot_prefixes}; do "                     \
- "run sysboot_boot; "                              \
- "run script_boot; "                               \
- "done\0"                                                  \
- \
- "boot_targets=" \
- BOOT_TARGETS_MMC " " \
- BOOT_TARGETS_USB " " \
- BOOT_TARGETS_PXE " " \
- BOOT_TARGETS_DHCP " " \
- "\0" \
- \
- "boot_prefixes=/ /boot/\0" \
- \
- "boot_scripts=boot.scr.uimg boot.scr\0" \
- \
- BOOTCMDS_MMC \
- BOOTCMDS_USB \
- BOOTCMDS_DHCP \
- BOOTCMDS_PXE
-
-#define CONFIG_BOOTCOMMAND \
- "set usb_need_init; " \
- "for target in ${boot_targets}; do run bootcmd_${target}; done"
-
+#define BOOTENV
 #endif
 
 #ifdef CONFIG_TEGRA_KEYBOARD
@@ -175,7 +55,7 @@
  MEM_LAYOUT_ENV_SETTINGS \
  "fdt_high=ffffffff\0" \
  "initrd_high=ffffffff\0" \
- BOOTCMDS_COMMON \
+ BOOTENV \
  BOARD_EXTRA_ENV_SETTINGS
 
 #if defined(CONFIG_TEGRA20_SFLASH) || defined(CONFIG_TEGRA20_SLINK) || defined(CONFIG_TEGRA114_SPI)
--
1.9.1

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

[PATCH 3/3] ARM: rpi_b: use new generic $bootcmd

Stephen Warren-2
In reply to this post by Stephen Warren-2
From: Stephen Warren <[hidden email]>

Replace the custom $bootcmd with that from <config_distro_bootcmd.h>.
There should be no functional change, since the new generic $bootcmd was
derived strongly from tegra-common-post.h, after which this part of
rpi_b.h was modelled.

The #defines to enable/disable U-Boot commands/features were moved
earlier in rpi_b.h, so they are set up before config_distro_bootcmd.h
is included, since it tests whether certain features should be included
based on those defines.

Signed-off-by: Stephen Warren <[hidden email]>
---
Note that while I've tested the Tegra conversion, I haven't tested this
one yet. I also didn't convert Wanda/Beagle/Panda, since I don't have
those boards to test. If this series is accepted, hopefully Dennis can
convert them, or perhaps I can try doing so blind:-)
---
 include/configs/rpi_b.h | 129 ++++++++++++++----------------------------------
 1 file changed, 36 insertions(+), 93 deletions(-)

diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index ff48598dd562..eea8471666fb 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -101,6 +101,38 @@
  "env import -t ${loadaddr} ${filesize}; " \
  "fi"
 
+/* Shell */
+#define CONFIG_SYS_MAXARGS 8
+#define CONFIG_SYS_PROMPT "U-Boot> "
+#define CONFIG_COMMAND_HISTORY
+
+/* Commands */
+#include <config_cmd_default.h>
+#define CONFIG_CMD_GPIO
+#define CONFIG_CMD_MMC
+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_CMD_PART
+
+/* Device tree support */
+#define CONFIG_OF_BOARD_SETUP
+/* ATAGs support for bootm/bootz */
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_CMDLINE_TAG
+#define CONFIG_INITRD_TAG
+
+#include <config_distro_defaults.h>
+
+/* Some things don't make sense on this HW or yet */
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_NET
+#undef CONFIG_CMD_NFS
+#undef CONFIG_CMD_SAVEENV
+#undef CONFIG_CMD_DHCP
+#undef CONFIG_CMD_MII
+#undef CONFIG_CMD_NET
+#undef CONFIG_CMD_PING
+
+/* Environment */
 #define ENV_DEVICE_SETTINGS \
  "stdin=serial,lcd\0" \
  "stdout=serial,lcd\0" \
@@ -138,104 +170,15 @@
  "fdtfile=bcm2835-rpi-b.dtb\0" \
  "ramdisk_addr_r=0x02100000\0" \
 
-#define BOOTCMDS_MMC \
- "mmc_boot=" \
- "setenv devtype mmc; " \
- "if mmc dev ${devnum}; then " \
- "run scan_boot; " \
- "fi\0" \
- "bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0"
-#define BOOT_TARGETS_MMC "mmc0"
-
-#define BOOTCMDS_COMMON \
- "rootpart=1\0" \
- \
- "do_script_boot="                                                 \
- "load ${devtype} ${devnum}:${rootpart} "                  \
- "${scriptaddr} ${prefix}${script}; "              \
- "source ${scriptaddr}\0"                                  \
- \
- "script_boot="                                                    \
- "for script in ${boot_scripts}; do "                      \
- "if test -e ${devtype} ${devnum}:${rootpart} "    \
- "${prefix}${script}; then "       \
- "echo Found ${prefix}${script}; "         \
- "run do_script_boot; "                    \
- "echo SCRIPT FAILED: continuing...; "     \
- "fi; "                                            \
- "done\0"                                                  \
- \
- "do_sysboot_boot="                                                \
- "sysboot ${devtype} ${devnum}:${rootpart} any "           \
- "${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \
- \
- "sysboot_boot="                                                   \
- "if test -e ${devtype} ${devnum}:${rootpart} "            \
- "${prefix}extlinux/extlinux.conf; then "  \
- "echo Found ${prefix}extlinux/extlinux.conf; "    \
- "run do_sysboot_boot; "                           \
- "echo SCRIPT FAILED: continuing...; "             \
- "fi\0"                                                    \
- \
- "scan_boot="                                                      \
- "echo Scanning ${devtype} ${devnum}...; "                 \
- "for prefix in ${boot_prefixes}; do "                     \
- "run sysboot_boot; "                              \
- "run script_boot; "                               \
- "done\0"                                                  \
- \
- "boot_targets=" \
- BOOT_TARGETS_MMC " " \
- "\0" \
- \
- "boot_prefixes=/\0" \
- \
- "boot_scripts=boot.scr.uimg\0" \
- \
- BOOTCMDS_MMC
-
-#define CONFIG_BOOTCOMMAND \
- "for target in ${boot_targets}; do run bootcmd_${target}; done"
-
-#define CONFIG_BOOTCOMMAND \
- "for target in ${boot_targets}; do run bootcmd_${target}; done"
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 0)
+#include <config_distro_bootcmd.h>
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
  ENV_DEVICE_SETTINGS \
  ENV_MEM_LAYOUT_SETTINGS \
- BOOTCMDS_COMMON
+ BOOTENV
 
 #define CONFIG_BOOTDELAY 2
 
-/* Shell */
-#define CONFIG_SYS_MAXARGS 8
-#define CONFIG_SYS_PROMPT "U-Boot> "
-#define CONFIG_COMMAND_HISTORY
-
-/* Commands */
-#include <config_cmd_default.h>
-#define CONFIG_CMD_GPIO
-#define CONFIG_CMD_MMC
-#define CONFIG_PARTITION_UUIDS
-#define CONFIG_CMD_PART
-
-/* Device tree support */
-#define CONFIG_OF_BOARD_SETUP
-/* ATAGs support for bootm/bootz */
-#define CONFIG_SETUP_MEMORY_TAGS
-#define CONFIG_CMDLINE_TAG
-#define CONFIG_INITRD_TAG
-
-#include <config_distro_defaults.h>
-
-/* Some things don't make sense on this HW or yet */
-#undef CONFIG_CMD_FPGA
-#undef CONFIG_CMD_NET
-#undef CONFIG_CMD_NFS
-#undef CONFIG_CMD_SAVEENV
-#undef CONFIG_CMD_DHCP
-#undef CONFIG_CMD_MII
-#undef CONFIG_CMD_NET
-#undef CONFIG_CMD_PING
-
 #endif
--
1.9.1

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Marek Vasut-3
In reply to this post by Stephen Warren-2
On Thursday, July 31, 2014 at 12:37:14 AM, Stephen Warren wrote:

> From: Dennis Gilmore <[hidden email]>
>
> 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 <[hidden email]>
> Signed-off-by: Stephen Warren <[hidden email]>

Reviewed-by: Marek Vasut <[hidden email]>

Looks nice, thanks!

Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Ian Campbell
In reply to this post by Stephen Warren-2
On Wed, 2014-07-30 at 16:37 -0600, Stephen Warren wrote:
> From: Dennis Gilmore <[hidden email]>
>
> 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.

From a distro PoV this is awesome, thanks!

Are you planning to convert any more platforms during this merge window?
Hans & I would really like to see sunxi switch this time around, before
it gets more widely used (since v2014.10 will support loads more
platforms).

I'm AFK after today but Hans has offered to try and whip something up
ASAP.

Cheers,
Ian.

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Stephen Warren-2
On 07/31/2014 04:47 AM, Ian Campbell wrote:

> On Wed, 2014-07-30 at 16:37 -0600, Stephen Warren wrote:
>> From: Dennis Gilmore <[hidden email]>
>>
>> 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.
>
>  From a distro PoV this is awesome, thanks!
>
> Are you planning to convert any more platforms during this merge window?
> Hans & I would really like to see sunxi switch this time around, before
> it gets more widely used (since v2014.10 will support loads more
> platforms).
>
> I'm AFK after today but Hans has offered to try and whip something up
> ASAP.

It would be best if individual board/SoC owners (or at least people who
have the HW) converted the config files, since they have full knowledge
of the best boot order, and can test the changes.

Still, if anyone needs me to take a look at specific platforms, let me
know and I'll see what I can do.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Simon Glass-3
In reply to this post by Stephen Warren-2
Hi Stephen,

On 30 July 2014 23:37, Stephen Warren <[hidden email]> wrote:

> From: Dennis Gilmore <[hidden email]>
>
> 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 <[hidden email]>
> Signed-off-by: Stephen Warren <[hidden email]>

I do understand the desirability of getting something sorted in this
area. But I am not thrilled with all the macro magic. How does this
fit with the new Kconfig setup? It encourages a single setting for
each variable, and I feel that the #ifdefs are not compatible with
that.

Would it be possible to put the settings in the device tree somehow
instead of CONFIGs?

I did send a series some time ago that aimed to improve the default
environment specification in config files - it was parked while
Kconfig was going on, but we could revisit it.

Regards,
Simon
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Stephen Warren-2
On 07/31/2014 04:03 PM, Simon Glass wrote:

> Hi Stephen,
>
> On 30 July 2014 23:37, Stephen Warren <[hidden email]> wrote:
>> From: Dennis Gilmore <[hidden email]>
>>
>> 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 <[hidden email]>
>> Signed-off-by: Stephen Warren <[hidden email]>
>
> I do understand the desirability of getting something sorted in this
> area. But I am not thrilled with all the macro magic. How does this
> fit with the new Kconfig setup? It encourages a single setting for
> each variable, and I feel that the #ifdefs are not compatible with
> that.

I think Kconfig would be completely unsuitable for this kind of detailed
configuration. Kconfig is great for enabling/disabling features, but
applying it here feels too much to me. Equally, Kconfig is rather new in
U-Boot. It'd be better to enable the feature so that distros can rely on
it, and then refactor it later if required.

I do feel that actually implementing the boot script as U-Boot
environment variables is much preferred over hard-coding any algorithm
into U-Boot. That way, the user can easily modify the scripts as they
desire. If we just put e.g. $boot_targets into the environment or DT,
but none of the other scripts in this patch, the user would be much more
severely restricted in how they could reconfigure the system to act how
they want.

> Would it be possible to put the settings in the device tree somehow
> instead of CONFIGs?

At least part of the information isn't a HW description, but rather
user-/vendor configuration. So, I don't think it's appropriate to put
this into DT. Equally, very few U-Boot platforms currently use DT, and I
certainly hope it doesn't become mandatory in any way. So, using DT for
this purpose would severely limit the platforms where this feature was
available.

> I did send a series some time ago that aimed to improve the default
> environment specification in config files - it was parked while
> Kconfig was going on, but we could revisit it.

I think we'd still need to use a C pre-processor (or some other code
generation/templating tool) even with that scheme in place. So, I think
the two are orthogonal.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Simon Glass-3
Hi Stephen,

On 31 July 2014 17:00, Stephen Warren <[hidden email]> wrote:

> On 07/31/2014 04:03 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 30 July 2014 23:37, Stephen Warren <[hidden email]> wrote:
>>>
>>> From: Dennis Gilmore <[hidden email]>
>>>
>>> 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 <[hidden email]>
>>> Signed-off-by: Stephen Warren <[hidden email]>
>>
>>
>> I do understand the desirability of getting something sorted in this
>> area. But I am not thrilled with all the macro magic. How does this
>> fit with the new Kconfig setup? It encourages a single setting for
>> each variable, and I feel that the #ifdefs are not compatible with
>> that.
>
>
> I think Kconfig would be completely unsuitable for this kind of detailed
> configuration. Kconfig is great for enabling/disabling features, but
> applying it here feels too much to me. Equally, Kconfig is rather new in
> U-Boot. It'd be better to enable the feature so that distros can rely on it,
> and then refactor it later if required.

Are you saying that we can reimplement this in a nicer way and distros
will still see the same behaviour?

>
> I do feel that actually implementing the boot script as U-Boot environment
> variables is much preferred over hard-coding any algorithm into U-Boot. That
> way, the user can easily modify the scripts as they desire. If we just put
> e.g. $boot_targets into the environment or DT, but none of the other scripts
> in this patch, the user would be much more severely restricted in how they
> could reconfigure the system to act how they want.

But that worries me. It means that it is easy for one board to deviate
from what is essentially an undocumented boot standard, and then we
will end up having to support that use case in the future.

Or if it is documented, where is that?

>
>
>> Would it be possible to put the settings in the device tree somehow
>> instead of CONFIGs?
>
>
> At least part of the information isn't a HW description, but rather
> user-/vendor configuration. So, I don't think it's appropriate to put this
> into DT. Equally, very few U-Boot platforms currently use DT, and I
> certainly hope it doesn't become mandatory in any way. So, using DT for this
> purpose would severely limit the platforms where this feature was available.

The only platforms I see support for in your series are Tegra (which
has DT) and Raspberry PI. Adding basic DT support is not really
onerous so doesn't impose any real limits on adoption. In any case I'm
mostly just responding to what I see might become a large and
mandatory script setup in U-Boot. Would it not be better now to
document this clearly and specify that changes are not supported? Then
we might be able to refactor it later and still retain compatibility.
If we have a clear API separate from the implementation then it is
easier to live with the scripts knowing we can do things a different
way later.

Looking at this from a driver model perspective we would probably want
to have a list of devices to try, in a certain order. Certainly driver
model would support the approach in this series, but it would be a
very ugly way of achieving the goal IMO.

BTW in your series bootpart is always 1 - is that always the case for
all boards?

As to the question of HW description, I'm not sure I follow. The
devices that are attached to the hardware presumably appear in the DT,
the partition is fixed anyway, all you need to know is whether it is a
bootable device or not. What part of the description is not related to
the hardware?

In trying to figure out what was going on, I was hampered by the fact
that autoconf.mk does not get the full environment (e.g. since BOOTDEV
doesn't have a CONFIG_ prefix). I can see what it doesn't, I think.

>
>
>> I did send a series some time ago that aimed to improve the default
>> environment specification in config files - it was parked while
>> Kconfig was going on, but we could revisit it.
>
>
> I think we'd still need to use a C pre-processor (or some other code
> generation/templating tool) even with that scheme in place. So, I think the
> two are orthogonal.

Yes, but the more of this sort of stuff we add to U-Boot the harder it
becomes to revisit. As you may recall the tegra config files were
already pretty hard to move over.

Regards,
Simon
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Dennis Gilmore
On Mon, 4 Aug 2014 04:13:41 -0600
Simon Glass <[hidden email]> wrote:

> Hi Stephen,
>
> On 31 July 2014 17:00, Stephen Warren <[hidden email]> wrote:
> > On 07/31/2014 04:03 PM, Simon Glass wrote:
> >>
> >> Hi Stephen,
> >>
> >> On 30 July 2014 23:37, Stephen Warren <[hidden email]>
> >> wrote:
> >>>
> >>> From: Dennis Gilmore <[hidden email]>
> >>>
> >>> 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 <[hidden email]>
> >>> Signed-off-by: Stephen Warren <[hidden email]>
> >>
> >>
> >> I do understand the desirability of getting something sorted in
> >> this area. But I am not thrilled with all the macro magic. How
> >> does this fit with the new Kconfig setup? It encourages a single
> >> setting for each variable, and I feel that the #ifdefs are not
> >> compatible with that.
> >
> >
> > I think Kconfig would be completely unsuitable for this kind of
> > detailed configuration. Kconfig is great for enabling/disabling
> > features, but applying it here feels too much to me. Equally,
> > Kconfig is rather new in U-Boot. It'd be better to enable the
> > feature so that distros can rely on it, and then refactor it later
> > if required.
>
> Are you saying that we can reimplement this in a nicer way and distros
> will still see the same behaviour?
As long as the implementation loads a extlinux.conf file yes. how
things are implemented in u-boot really does not matter at all. the API
between os and u-boot is the config file.

> >
> > I do feel that actually implementing the boot script as U-Boot
> > environment variables is much preferred over hard-coding any
> > algorithm into U-Boot. That way, the user can easily modify the
> > scripts as they desire. If we just put e.g. $boot_targets into the
> > environment or DT, but none of the other scripts in this patch, the
> > user would be much more severely restricted in how they could
> > reconfigure the system to act how they want.
>
> But that worries me. It means that it is easy for one board to deviate
> from what is essentially an undocumented boot standard, and then we
> will end up having to support that use case in the future.
>
> Or if it is documented, where is that?

http://www.syslinux.org/wiki/index.php/Doc/syslinux
we have added fdt and fdtdir options for dealing with dtb.  we probably
should have our own documentation. We have adopted a standard.

> >
> >
> >> Would it be possible to put the settings in the device tree somehow
> >> instead of CONFIGs?
> >
> >
> > At least part of the information isn't a HW description, but rather
> > user-/vendor configuration. So, I don't think it's appropriate to
> > put this into DT. Equally, very few U-Boot platforms currently use
> > DT, and I certainly hope it doesn't become mandatory in any way.
> > So, using DT for this purpose would severely limit the platforms
> > where this feature was available.
>
> The only platforms I see support for in your series are Tegra (which
> has DT) and Raspberry PI. Adding basic DT support is not really
> onerous so doesn't impose any real limits on adoption. In any case I'm
> mostly just responding to what I see might become a large and
> mandatory script setup in U-Boot. Would it not be better now to
> document this clearly and specify that changes are not supported? Then
> we might be able to refactor it later and still retain compatibility.
> If we have a clear API separate from the implementation then it is
> easier to live with the scripts knowing we can do things a different
> way later.
>
> Looking at this from a driver model perspective we would probably want
> to have a list of devices to try, in a certain order. Certainly driver
> model would support the approach in this series, but it would be a
> very ugly way of achieving the goal IMO.
>
> BTW in your series bootpart is always 1 - is that always the case for
> all boards?

It generally is, longer term we need to look at the partition table and
find the bootable partition. This is a good starting point.

> As to the question of HW description, I'm not sure I follow. The
> devices that are attached to the hardware presumably appear in the DT,
> the partition is fixed anyway, all you need to know is whether it is a
> bootable device or not. What part of the description is not related to
> the hardware?
>
> In trying to figure out what was going on, I was hampered by the fact
> that autoconf.mk does not get the full environment (e.g. since BOOTDEV
> doesn't have a CONFIG_ prefix). I can see what it doesn't, I think.

having u-boot enumerate over the connected devices in a known good
boot order would be nice. Better still would be easily enabling the
user to change the boot order.

having u-boot default to output on both serial and video is really
needed. Think of a arm based laptop, the user should easily be able to
pxe boot to install, select the kernel to run. There is plenty of room
for improvement here.
 

> >
> >
> >> I did send a series some time ago that aimed to improve the default
> >> environment specification in config files - it was parked while
> >> Kconfig was going on, but we could revisit it.
> >
> >
> > I think we'd still need to use a C pre-processor (or some other code
> > generation/templating tool) even with that scheme in place. So, I
> > think the two are orthogonal.
>
> Yes, but the more of this sort of stuff we add to U-Boot the harder it
> becomes to revisit. As you may recall the tegra config files were
> already pretty hard to move over.

knowing the interface we have should make it easier to improve the
backend later.

Dennis

_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Stephen Warren-2
In reply to this post by Simon Glass-3
On 08/04/2014 04:13 AM, Simon Glass wrote:

> Hi Stephen,
>
> On 31 July 2014 17:00, Stephen Warren <[hidden email]> wrote:
>> On 07/31/2014 04:03 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 30 July 2014 23:37, Stephen Warren <[hidden email]> wrote:
>>>>
>>>> From: Dennis Gilmore <[hidden email]>
>>>>
>>>> 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 <[hidden email]>
>>>> Signed-off-by: Stephen Warren <[hidden email]>
>>>
>>>
>>> I do understand the desirability of getting something sorted in this
>>> area. But I am not thrilled with all the macro magic. How does this
>>> fit with the new Kconfig setup? It encourages a single setting for
>>> each variable, and I feel that the #ifdefs are not compatible with
>>> that.
>>
>>
>> I think Kconfig would be completely unsuitable for this kind of detailed
>> configuration. Kconfig is great for enabling/disabling features, but
>> applying it here feels too much to me. Equally, Kconfig is rather new in
>> U-Boot. It'd be better to enable the feature so that distros can rely on it,
>> and then refactor it later if required.
>
> Are you saying that we can reimplement this in a nicer way and distros
> will still see the same behaviour?

I expect we could.

The only thing distros should rely upon is that if they put
extlinux.conf in the right directory on their media, it will get loaded
and executed.

There are obviously various ways that could be implemented in U-Boot, or
indeed other bootloaders.

>> I do feel that actually implementing the boot script as U-Boot environment
>> variables is much preferred over hard-coding any algorithm into U-Boot. That
>> way, the user can easily modify the scripts as they desire. If we just put
>> e.g. $boot_targets into the environment or DT, but none of the other scripts
>> in this patch, the user would be much more severely restricted in how they
>> could reconfigure the system to act how they want.
>
> But that worries me. It means that it is easy for one board to deviate
> from what is essentially an undocumented boot standard, and then we
> will end up having to support that use case in the future.
>
> Or if it is documented, where is that?

I was talking about an end-user changing the boot process.

An individual board could only change the boot scripts by either not
using config_distro_bootcmd.h, or by explicitly overriding something
that it does. Either of those would simply mean that the board doesn't
provide the standard boot environment to distros, and as such wouldn't
be expected to boot distros in the standard way.

Note that all we're talking about here is that U-Boot can search all (or
perhaps most) attached storage devices for extlinux.conf and interpret
it correctly. This patch adds the "search for" part; the definition of
"interpret it correctly" is already part of the implementation of the
"pxe" and "sysboot" commands in U-Boot.

>>> Would it be possible to put the settings in the device tree somehow
>>> instead of CONFIGs?
>>
>>
>> At least part of the information isn't a HW description, but rather
>> user-/vendor configuration. So, I don't think it's appropriate to put this
>> into DT. Equally, very few U-Boot platforms currently use DT, and I
>> certainly hope it doesn't become mandatory in any way. So, using DT for this
>> purpose would severely limit the platforms where this feature was available.
>
> The only platforms I see support for in your series are Tegra (which
> has DT) and Raspberry PI.

Those are the only platforms I put into my patch set. In Dennis
Gilmore's previous patch set, he converted 3 other platforms, and since
I posted my series, someone posted a conversion for sunxi too.

> Adding basic DT support is not really
> onerous so doesn't impose any real limits on adoption.

It implies that the board/SoC maintainers buy into the idea that using
DT is a useful thing to do for U-Boot. I believe there's plenty of
disagreement with that on Tegra already, just not vocal.

> In any case I'm
> mostly just responding to what I see might become a large and
> mandatory script setup in U-Boot. Would it not be better now to
> document this clearly and specify that changes are not supported?

The fact that changes aren't allowed is rather implied by opting in to
using the header in the first place.

Dennis has a patch that provides documentation for the concepts that he
included in his series, upon which I based mine. I assume he'll respin
that patch, since he received some comments on it when posted.

> Then
> we might be able to refactor it later and still retain compatibility.
> If we have a clear API separate from the implementation then it is
> easier to live with the scripts knowing we can do things a different
> way later.

That said, I'm not sure what aspect of documentation is needed. This
patch doesn't introduce any new API. The patch is simply about searching
for an extlinux.conf file and executing it. The important "ABI" things
are implied by the definition of extlinux.conf (which already has
documentation) not by this patch.

> Looking at this from a driver model perspective we would probably want
> to have a list of devices to try, in a certain order. Certainly driver
> model would support the approach in this series, but it would be a
> very ugly way of achieving the goal IMO.
>
> BTW in your series bootpart is always 1 - is that always the case for
> all boards?

For now yes. At some point, I did intend to enhance the scripts to use
the "default" partition on the media, as defined by the partition
table's bootable flag. I haven't implemented that yet. I expect that
it'd work something like: unset $bootpart in order to use that "default"
partition, or set it to some specific value in order to use that
specific partition. IIRC, that's already how disk-oriented commands
parse their command-line arguments.

> As to the question of HW description, I'm not sure I follow. The
> devices that are attached to the hardware presumably appear in the DT,
> the partition is fixed anyway, all you need to know is whether it is a
> bootable device or not. What part of the description is not related to
> the hardware?

The concept of bootable, and the order in which bootable devices should
be searched, are SW policy, not HW definition.

> In trying to figure out what was going on, I was hampered by the fact
> that autoconf.mk does not get the full environment (e.g. since BOOTDEV
> doesn't have a CONFIG_ prefix). I can see what it doesn't, I think.

I don't quite understand how the contents of autoconf.mk is relevant.
The scripts that config_distro_bootcmd.h defines are self-contained, so
I think you can just read that file.

>>> I did send a series some time ago that aimed to improve the default
>>> environment specification in config files - it was parked while
>>> Kconfig was going on, but we could revisit it.
>>
>>
>> I think we'd still need to use a C pre-processor (or some other code
>> generation/templating tool) even with that scheme in place. So, I think the
>> two are orthogonal.
>
> Yes, but the more of this sort of stuff we add to U-Boot the harder it
> becomes to revisit. As you may recall the tegra config files were
> already pretty hard to move over.

The conversion to Kconfig didn't seem to change any of the Tegra config
files.

In my opinion at least, Kconfig shouldn't seek to replace
include/configs/tegra_*.h, but rather should control user-visible
options rather than internal details.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Simon Glass-3
Hi Stephen & Dennis,

On 4 August 2014 12:04, Stephen Warren <[hidden email]> wrote:

> On 08/04/2014 04:13 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 31 July 2014 17:00, Stephen Warren <[hidden email]> wrote:
>>>
>>> On 07/31/2014 04:03 PM, Simon Glass wrote:
>>>>
>>>>
>>>> Hi Stephen,
>>>>
>>>> On 30 July 2014 23:37, Stephen Warren <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> From: Dennis Gilmore <[hidden email]>

Thanks for the doc pointers.

>>>>>
>>>>> 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 <[hidden email]>
>>>>> Signed-off-by: Stephen Warren <[hidden email]>
>>>>
>>>>
>>>>
>>>> I do understand the desirability of getting something sorted in this
>>>> area. But I am not thrilled with all the macro magic. How does this
>>>> fit with the new Kconfig setup? It encourages a single setting for
>>>> each variable, and I feel that the #ifdefs are not compatible with
>>>> that.
>>>
>>>
>>>
>>> I think Kconfig would be completely unsuitable for this kind of detailed
>>> configuration. Kconfig is great for enabling/disabling features, but
>>> applying it here feels too much to me. Equally, Kconfig is rather new in
>>> U-Boot. It'd be better to enable the feature so that distros can rely on
>>> it,
>>> and then refactor it later if required.
>>
>>
>> Are you saying that we can reimplement this in a nicer way and distros
>> will still see the same behaviour?
>
>
> I expect we could.
>
> The only thing distros should rely upon is that if they put extlinux.conf in
> the right directory on their media, it will get loaded and executed.
>
> There are obviously various ways that could be implemented in U-Boot, or
> indeed other bootloaders.

OK, that makes me more comfortable.

>
>
>>> I do feel that actually implementing the boot script as U-Boot
>>> environment
>>> variables is much preferred over hard-coding any algorithm into U-Boot.
>>> That
>>> way, the user can easily modify the scripts as they desire. If we just
>>> put
>>> e.g. $boot_targets into the environment or DT, but none of the other
>>> scripts
>>> in this patch, the user would be much more severely restricted in how
>>> they
>>> could reconfigure the system to act how they want.
>>
>>
>> But that worries me. It means that it is easy for one board to deviate
>> from what is essentially an undocumented boot standard, and then we
>> will end up having to support that use case in the future.
>>
>> Or if it is documented, where is that?
>
>
> I was talking about an end-user changing the boot process.
>
> An individual board could only change the boot scripts by either not using
> config_distro_bootcmd.h, or by explicitly overriding something that it does.
> Either of those would simply mean that the board doesn't provide the
> standard boot environment to distros, and as such wouldn't be expected to
> boot distros in the standard way.

OK, so long as that is clear then all is well. I thought you meant the
board author could change the scripts in order to tweak the process.

>
> Note that all we're talking about here is that U-Boot can search all (or
> perhaps most) attached storage devices for extlinux.conf and interpret it
> correctly. This patch adds the "search for" part; the definition of
> "interpret it correctly" is already part of the implementation of the "pxe"
> and "sysboot" commands in U-Boot.

OK.

>
>
>>>> Would it be possible to put the settings in the device tree somehow
>>>> instead of CONFIGs?
>>>
>>>
>>>
>>> At least part of the information isn't a HW description, but rather
>>> user-/vendor configuration. So, I don't think it's appropriate to put
>>> this
>>> into DT. Equally, very few U-Boot platforms currently use DT, and I
>>> certainly hope it doesn't become mandatory in any way. So, using DT for
>>> this
>>> purpose would severely limit the platforms where this feature was
>>> available.
>>
>>
>> The only platforms I see support for in your series are Tegra (which
>> has DT) and Raspberry PI.
>
>
> Those are the only platforms I put into my patch set. In Dennis Gilmore's
> previous patch set, he converted 3 other platforms, and since I posted my
> series, someone posted a conversion for sunxi too.
>
>
>> Adding basic DT support is not really
>> onerous so doesn't impose any real limits on adoption.
>
>
> It implies that the board/SoC maintainers buy into the idea that using DT is
> a useful thing to do for U-Boot. I believe there's plenty of disagreement
> with that on Tegra already, just not vocal.

Well that's another discussion, and fair enough you don't want to tie
the two together.

>
>
>> In any case I'm
>> mostly just responding to what I see might become a large and
>> mandatory script setup in U-Boot. Would it not be better now to
>> document this clearly and specify that changes are not supported?
>
>
> The fact that changes aren't allowed is rather implied by opting in to using
> the header in the first place.
>
> Dennis has a patch that provides documentation for the concepts that he
> included in his series, upon which I based mine. I assume he'll respin that
> patch, since he received some comments on it when posted.

OK good.

>
>
>> Then
>> we might be able to refactor it later and still retain compatibility.
>> If we have a clear API separate from the implementation then it is
>> easier to live with the scripts knowing we can do things a different
>> way later.
>
>
> That said, I'm not sure what aspect of documentation is needed. This patch
> doesn't introduce any new API. The patch is simply about searching for an
> extlinux.conf file and executing it. The important "ABI" things are implied
> by the definition of extlinux.conf (which already has documentation) not by
> this patch.

I was referring more to things like the partitions that are searched,
and other things specific to your implementation. Dennis pointed me to
the syslinux stuff and that is pretty clear. I did try to bring it up
at one point but got lost in a maze of U-Boot scripts. Would like to
keep the U-Boot side as simple as possible.

>
>
>> Looking at this from a driver model perspective we would probably want
>> to have a list of devices to try, in a certain order. Certainly driver
>> model would support the approach in this series, but it would be a
>> very ugly way of achieving the goal IMO.
>>
>> BTW in your series bootpart is always 1 - is that always the case for
>> all boards?
>
>
> For now yes. At some point, I did intend to enhance the scripts to use the
> "default" partition on the media, as defined by the partition table's
> bootable flag. I haven't implemented that yet. I expect that it'd work
> something like: unset $bootpart in order to use that "default" partition, or
> set it to some specific value in order to use that specific partition. IIRC,
> that's already how disk-oriented commands parse their command-line
> arguments.

OK

>
>
>> As to the question of HW description, I'm not sure I follow. The
>> devices that are attached to the hardware presumably appear in the DT,
>> the partition is fixed anyway, all you need to know is whether it is a
>> bootable device or not. What part of the description is not related to
>> the hardware?
>
>
> The concept of bootable, and the order in which bootable devices should be
> searched, are SW policy, not HW definition.
>

So that is it? I wonder whether if this is the only configuration
option, we might eventually write this feature in C as a new U-Boot
command, with an environment variable listing the devices in order?

>
>> In trying to figure out what was going on, I was hampered by the fact
>> that autoconf.mk does not get the full environment (e.g. since BOOTDEV
>> doesn't have a CONFIG_ prefix). I can see what it doesn't, I think.
>
>
> I don't quite understand how the contents of autoconf.mk is relevant. The
> scripts that config_distro_bootcmd.h defines are self-contained, so I think
> you can just read that file.

The macro magic makes it hard to see what is going on though.

>
>
>>>> I did send a series some time ago that aimed to improve the default
>>>> environment specification in config files - it was parked while
>>>> Kconfig was going on, but we could revisit it.
>>>
>>>
>>>
>>> I think we'd still need to use a C pre-processor (or some other code
>>> generation/templating tool) even with that scheme in place. So, I think
>>> the
>>> two are orthogonal.
>>
>>
>> Yes, but the more of this sort of stuff we add to U-Boot the harder it
>> becomes to revisit. As you may recall the tegra config files were
>> already pretty hard to move over.
>
>
> The conversion to Kconfig didn't seem to change any of the Tegra config
> files.
>
> In my opinion at least, Kconfig shouldn't seek to replace
> include/configs/tegra_*.h, but rather should control user-visible options
> rather than internal details.

Sure but to my mind the list of bootable devices might well be
something that people want to change in configuration. But really I
was talking about the series to move environment variables and scripts
to a text file from the config/*.h files. That's quite a tricky
transition if we attempt it, and is made trickier by tricky macro
stuff in specific board header files. It's just a comment, not a
blocker.

Regards,
Simon
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Stephen Warren-2
On 08/05/2014 06:27 AM, Simon Glass wrote:
> On 4 August 2014 12:04, Stephen Warren <[hidden email]> wrote:
>> On 08/04/2014 04:13 AM, Simon Glass wrote:

>>> As to the question of HW description, I'm not sure I follow. The
>>> devices that are attached to the hardware presumably appear in the DT,
>>> the partition is fixed anyway, all you need to know is whether it is a
>>> bootable device or not. What part of the description is not related to
>>> the hardware?
>>
>> The concept of bootable, and the order in which bootable devices should be
>> searched, are SW policy, not HW definition.
>
> So that is it? I wonder whether if this is the only configuration
> option, we might eventually write this feature in C as a new U-Boot
> command, with an environment variable listing the devices in order?

It would certainly be possible to do that.

In some ways I prefer implementing this all as user-accessible macros.
That way, if the user wants to tweak them, it's as simple as editing the
macro and re-saving the environment, rather than rebuilding the
bootloader from source.

Obviously, if someone changes something it may not work in the same way
as originally intended, but it's not everybody's goal to boot a
"standard" distro in a "standard" way - rather they may want to play
around with their own custom ideas.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Stephen Warren-2
In reply to this post by Stephen Warren-2
On 07/30/2014 04:37 PM, Stephen Warren wrote:
> From: Dennis Gilmore <[hidden email]>
>
> 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.

Simon, are you OK with these patches following the discussion? Dennis, I
assume you're OK with the new version of this patch?

I assume that your acks would go a long way towards Tom applying this
series.

Thanks.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Simon Glass-3
Hi Stephen,

On 6 August 2014 10:01, Stephen Warren <[hidden email]> wrote:

> On 07/30/2014 04:37 PM, Stephen Warren wrote:
>>
>> From: Dennis Gilmore <[hidden email]>
>>
>> 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.
>
>
> Simon, are you OK with these patches following the discussion? Dennis, I
> assume you're OK with the new version of this patch?

I looked it through fairly closely as you cleared up my doubts (i.e.
we can move the implementation from scripts to a command later if we
want without anyone outside U-Boot knowing/caring). I'll take another
look.

>
> I assume that your acks would go a long way towards Tom applying this
> series.
>
> Thanks.

Regards,
Simon
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Simon Glass-3
Acked-by: Simon Glass <[hidden email]>
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 3/3] ARM: rpi_b: use new generic $bootcmd

Simon Glass-3
In reply to this post by Stephen Warren-2
Acked-by: Simon Glass <[hidden email]>
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Stephen Warren-2
In reply to this post by Simon Glass-3
On 08/07/2014 06:17 PM, Simon Glass wrote:
> Acked-by: Simon Glass <[hidden email]>

For the list archive's record: Simon also replied to patch 2 with the
same ack, but somehow the CC list got dropped to only myself and TomW.
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 2/3] ARM: tegra: use new generic $bootcmd

Simon Glass-3
In reply to this post by Stephen Warren-2
On 30 July 2014 16:37, Stephen Warren <[hidden email]> wrote:
> From: Stephen Warren <[hidden email]>
>
> Replace the custom $bootcmd with that from <config_distro_bootcmd.h>.
> There should be no functional change, since the new generic $bootcmd was
> derived strongly from tegra-common-post.h.
>
> Signed-off-by: Stephen Warren <[hidden email]>

(Resending to list)

Acked-by: Simon Glass <[hidden email]>
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH 1/3] config: introduce a generic $bootcmd

Hans de Goede
In reply to this post by Stephen Warren-2
Hi,

On 08/08/2014 06:00 PM, Stephen Warren wrote:
> On 08/07/2014 06:17 PM, Simon Glass wrote:
>> Acked-by: Simon Glass <[hidden email]>
>
> For the list archive's record: Simon also replied to patch 2 with the same ack, but somehow the CC list got dropped to only myself and TomW.

I've a bunch of patches relying on this, is there anything stopping this
from getting merged ?

Reviewed-by: Hans de Goede <[hidden email]>

Regards,

Hans
_______________________________________________
U-Boot mailing list
[hidden email]
http://lists.denx.de/mailman/listinfo/u-boot
12