wandboard: add pxe support, set default boot command like highbank

From: Dennis Gilmore <[email protected]>

Signed-off-by Dennis Gilmore <[email protected]>

---
 include/configs/wandboard.h | 42 +++++++++++++++++++++++++++++++++++++++---
 1 file changed, 39 insertions(+), 3 deletions(-)

include/configs/wandboard.h +2 -0

index ee6bf21..a5052c5 100644
@@ -58,6 +58,8 @@
 #define CONFIG_LOADADDR                        0x12000000
 #define CONFIG_SYS_TEXT_BASE           0x17800000
 
+#define CONFIG_SUPPORT_RAW_INITRD
+
 /* MMC Configuration */
 #define CONFIG_FSL_ESDHC
 #define CONFIG_FSL_USDHC

@@ -72,6 +74,14 @@
 #define CONFIG_CMD_FAT

include/configs/wandboard.h +5 -0

        "boot_fdt=try\0" \
+       "bootcmd_setup=mmc rescan\0" \
+       "bootcmd_pxe=setenv bootfile \"\" ;dhcp; pxe get; pxe boot\0" \
+       "bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r} boot.scr && source ${scr_addr_r}\0" \
+       "bootcmd_disk_sysboot1=setenv bootfile /boot/extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \
+       "bootcmd_disk_sysboot2=setenv bootfile /extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \

include/configs/wandboard.h +10 -4

+       "localcmd=run bootcmd_sata\0" \
+       "bootdevice=0\0" \
+       "bootargs=console=ttymxc0 root=LABEL=rootfs\0" \
+       "bootdelay=2\0" \
+       "bootretry=90\0" \
+       "netretry=once\0" \
        "ip_dyn=yes\0" \
        "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
        "mmcpart=1\0" \

@@ -139,11 +174,11 @@
        "mmcargs=setenv bootargs console=${console},${baudrate} " \
                "root=${mmcroot}\0" \
        "loadbootscript=" \
-               "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+               "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
        "bootscript=echo Running bootscript from mmc ...; " \
                "source\0" \
-       "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-       "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
+       "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
+       "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
        "mmcboot=echo Booting from mmc ...; " \
                "run mmcargs; " \
                "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \

@@ -186,6 +221,7 @@
 
 #define CONFIG_BOOTCOMMAND \
           "mmc dev ${mmcdev}; if mmc rescan; then " \
+                  "run bootcmd_default; " \
                   "if run loadbootscript; then " \
                           "run bootscript; " \
                   "else " \
--

1.8.3.1

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 26 Jul 2013 10:52:04 -0300
Otavio Salvador <[email protected]> wrote:

Quoted 4 lines · On Thu, Jul 25, 2013 at 6:13 PM, <[email protected]> wrote:

Quoted 1 line

From: Dennis Gilmore <[email protected]>

highbank? what does this means?

calxeda highbank. the overall goal of this patch set is to simplify things for distros to support the wandboard

Quoted 34 lines

Quoted 21 lines

Signed-off-by Dennis Gilmore <[email protected]>

---
 include/configs/wandboard.h | 42

+++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-)

(quoted diff) +0 -0

b/include/configs/wandboard.h index ee6bf21..a5052c5 100644

include/configs/wandboard.h +2 -0

@@ -58,6 +58,8 @@
 #define CONFIG_LOADADDR                        0x12000000
 #define CONFIG_SYS_TEXT_BASE           0x17800000
 
+#define CONFIG_SUPPORT_RAW_INITRD
+
 /* MMC Configuration */
 #define CONFIG_FSL_ESDHC
 #define CONFIG_FSL_USDHC

@@ -72,6 +74,14 @@
 #define CONFIG_CMD_FAT

include/configs/wandboard.h line 84

Quoted 10 lines

include/configs/wandboard.h +8 -0

 #define CONFIG_DOS_PARTITION
 
+/* PXE support */
+#define CONFIG_BOOTP_PXE
+#define CONFIG_BOOTP_PXE_CLIENTARCH     0x100
+#define CONFIG_BOOTP_VCI_STRING         "U-boot.armv7.wandboard"
+#define CONFIG_CMD_PXE
+#define CONFIG_MENU
+
+

Please use a single empty line.

Quoted 13 lines

include/configs/wandboard.h line 133

Quoted 11 lines

include/configs/wandboard.h +4 -0

 /* Ethernet Configuration */
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_DHCP

@@ -117,7 +127,32 @@
        "initrd_high=0xffffffff\0" \
        "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
        "fdt_addr=0x11000000\0" \
+       "pxefile_addr_r=0x12000000\0" \
+       "kernel_addr_r=0x13000000\0" \
+       "ramdisk_addr_r=0x32000000\0" \
+       "fdt_addr_r=0x11000000\0" \

Seems some vars are duplicated.

the cmd_pxe.c code requires the _r versions

Quoted 36 lines

Quoted 35 lines

include/configs/wandboard.h +4 -0

        "boot_fdt=try\0" \
+       "bootcmd_setup=mmc rescan\0" \
+       "bootcmd_pxe=setenv bootfile \"\" ;dhcp; pxe get; pxe
 boot\0" \
+       "bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice}
 ${scr_addr_r} boot.scr && source ${scr_addr_r}\0" \
+       "bootcmd_disk_sysboot1=setenv
 bootfile /boot/extlinux/extlinux.conf; sysboot ${boot_ifc}

${bootdevice} ext2\0" \
+ "bootcmd_disk_sysboot2=setenv
bootfile /extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \
+ "bootcmd_disk_uenv=ext2load ${boot_ifc} ${bootdevice}
${uenv_addr_r} uEnv.txt; env import -t ${uenv_addr_r} ${filesize}; run bootcmd_uenv\0" \
+ "bootcmd_disk_kernel=ext2load ${boot_ifc} ${bootdevice}
${kernel_addr_r} vmlinuz && ext2load ${boot_ifc} ${bootdevice} ${ramdisk_addr_r} initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr}\0" \
+ "bootcmd_disk=run bootcmd_disk_sysboot1; run
bootcmd_disk_sysboot2; run bootcmd_disk_uenv; run bootcmd_disk_scr; run bootcmd_disk_kernel\0" \
+ "bootcmd_sata=setenv boot_ifc scsi; scsi scan && run
bootcmd_disk\0" \
+ "bootcmd_mmc=setenv boot_ifc mmc; mmc rescan && run
bootcmd_disk\0" \
+ "bootcmd_default=run bootcmd_mmc; run bootcmd_sata; run
bootcmd_pxe\0" \

include/configs/wandboard.h +2 -0

+       "bootcmd0=run bootcmd_setup; run bootcmd_default\0" \
+       "bootcmd1=run bootcmd_setup; run bootcmd_pxe; run

bootcmd_default\0" \
+ "bootcmd2=run bootcmd_setup; run bootcmd_sata; run
bootcmd_default\0" \
+ "bootcmd15=run bootcmd_setup; run bootcmd_mmc; run
bootcmd_default\0" \

Quoted 2 lines

This all is need? We could have a way to make this extendable and don't have it all duplicated.

it provides a simple way to setup different boot orders.

Quoted 39 lines

Quoted 39 lines

include/configs/wandboard.h +7 -1

+       "localcmd=run bootcmd_sata\0" \
+       "bootdevice=0\0" \
+       "bootargs=console=ttymxc0 root=LABEL=rootfs\0" \
+       "bootdelay=2\0" \
+       "bootretry=90\0" \
+       "netretry=once\0" \
        "ip_dyn=yes\0" \
        "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
        "mmcpart=1\0" \

@@ -139,11 +174,11 @@
        "mmcargs=setenv bootargs console=${console},${baudrate} " \
                "root=${mmcroot}\0" \
        "loadbootscript=" \
-               "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
 ${script};\0" \
+               "load mmc ${mmcdev}:${mmcpart} ${loadaddr}

${script};\0" \ "bootscript=echo Running bootscript from mmc ...; " \ "source\0" \
- "loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr}
${uimage}\0" \
- "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr}
${fdt_file}\0" \
+ "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr}
${uimage}\0" \
+ "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr}

${fdt_file}\0" \ "mmcboot=echo Booting from mmc ...; " \
                "run mmcargs; " \
                "if test ${boot_fdt} = yes || test ${boot_fdt} =

try; then " \ @@ -186,6 +221,7 @@

 #define CONFIG_BOOTCOMMAND \
           "mmc dev ${mmcdev}; if mmc rescan; then " \
+                  "run bootcmd_default; " \
                   "if run loadbootscript; then " \
                           "run bootscript; " \
                   "else " \

--
1.8.3.1

Quoted 11 lines

Quoted 4 lines

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlHzEkIACgkQkSxm47BaWffDUACfcM4dsdVWpTNaCgOqgKlJeQ5w tIsAoJaLesZhxQ1kBZQrpR45uriHiWzD
=l+Dc
-----END PGP SIGNATURE-----

From: Dennis Gilmore <[email protected]>

Signed-off-by Dennis Gilmore <[email protected]>

---
 include/configs/wandboard.h | 42 +++++++++++++++++++++++++++++++++++++++---
 1 file changed, 39 insertions(+), 3 deletions(-)

include/configs/wandboard.h +15 -0

index ee6bf21..a5052c5 100644
@@ -58,6 +58,8 @@
 #define CONFIG_LOADADDR                        0x12000000
 #define CONFIG_SYS_TEXT_BASE           0x17800000
 
+#define CONFIG_SUPPORT_RAW_INITRD
+
 /* MMC Configuration */
 #define CONFIG_FSL_ESDHC
 #define CONFIG_FSL_USDHC

@@ -72,6 +74,14 @@
 #define CONFIG_CMD_FAT
 #define CONFIG_DOS_PARTITION
 
+/* PXE support */
+#define CONFIG_BOOTP_PXE
+#define CONFIG_BOOTP_PXE_CLIENTARCH     0x100
+#define CONFIG_BOOTP_VCI_STRING         "U-boot.armv7.wandboard"
+#define CONFIG_CMD_PXE
+#define CONFIG_MENU
+
+
 /* Ethernet Configuration */
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_DHCP

@@ -117,7 +127,32 @@
        "initrd_high=0xffffffff\0" \
        "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
        "fdt_addr=0x11000000\0" \
+       "pxefile_addr_r=0x12000000\0" \
+       "kernel_addr_r=0x13000000\0" \
+       "ramdisk_addr_r=0x32000000\0" \
+       "fdt_addr_r=0x11000000\0" \
        "boot_fdt=try\0" \
+       "bootcmd_setup=mmc rescan\0" \

Dennis,

Quoted 45 lines · On Thu, Jul 25, 2013 at 4:13 PM, <[email protected]> wrote:

From: Dennis Gilmore <[email protected]>

Signed-off-by Dennis Gilmore <[email protected]>

---
 include/configs/wandboard.h | 42 +++++++++++++++++++++++++++++++++++++++---
 1 file changed, 39 insertions(+), 3 deletions(-)

include/configs/wandboard.h +15 -0

index ee6bf21..a5052c5 100644
@@ -58,6 +58,8 @@
 #define CONFIG_LOADADDR                        0x12000000
 #define CONFIG_SYS_TEXT_BASE           0x17800000
 
+#define CONFIG_SUPPORT_RAW_INITRD
+
 /* MMC Configuration */
 #define CONFIG_FSL_ESDHC
 #define CONFIG_FSL_USDHC

@@ -72,6 +74,14 @@
 #define CONFIG_CMD_FAT
 #define CONFIG_DOS_PARTITION
 
+/* PXE support */
+#define CONFIG_BOOTP_PXE
+#define CONFIG_BOOTP_PXE_CLIENTARCH     0x100
+#define CONFIG_BOOTP_VCI_STRING         "U-boot.armv7.wandboard"
+#define CONFIG_CMD_PXE
+#define CONFIG_MENU
+
+
 /* Ethernet Configuration */
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_DHCP

@@ -117,7 +127,32 @@
        "initrd_high=0xffffffff\0" \
        "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
        "fdt_addr=0x11000000\0" \
+       "pxefile_addr_r=0x12000000\0" \
+       "kernel_addr_r=0x13000000\0" \
+       "ramdisk_addr_r=0x32000000\0" \
+       "fdt_addr_r=0x11000000\0" \
        "boot_fdt=try\0" \
+       "bootcmd_setup=mmc rescan\0" \

include/configs/wandboard.h line 145

Quoted 10 lines

include/configs/wandboard.h +10 -0

+       "bootcmd_pxe=setenv bootfile \"\" ;dhcp; pxe get; pxe boot\0" \
+       "bootcmd_disk_scr=ext2load ${boot_ifc} ${bootdevice} ${scr_addr_r} boot.scr && source ${scr_addr_r}\0" \
+       "bootcmd_disk_sysboot1=setenv bootfile /boot/extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \
+       "bootcmd_disk_sysboot2=setenv bootfile /extlinux/extlinux.conf; sysboot ${boot_ifc} ${bootdevice} ext2\0" \
+       "bootcmd_disk_uenv=ext2load ${boot_ifc} ${bootdevice} ${uenv_addr_r} uEnv.txt; env import -t ${uenv_addr_r} ${filesize}; run bootcmd_uenv\0" \
+       "bootcmd_disk_kernel=ext2load ${boot_ifc} ${bootdevice} ${kernel_addr_r} vmlinuz && ext2load ${boot_ifc} ${bootdevice} ${ramdisk_addr_r} initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr}\0" \
+       "bootcmd_disk=run bootcmd_disk_sysboot1; run bootcmd_disk_sysboot2; run bootcmd_disk_uenv; run bootcmd_disk_scr; run bootcmd_disk_kernel\0" \
+       "bootcmd_sata=setenv boot_ifc scsi; scsi scan && run bootcmd_disk\0" \
+       "bootcmd_mmc=setenv boot_ifc mmc; mmc rescan && run bootcmd_disk\0" \
+       "bootcmd_default=run bootcmd_mmc; run bootcmd_sata; run bootcmd_pxe\0" \

I really would not like to see this propagated to another board. I've completely redone the env for highbank based on what Stephen Warren did for Tegra. It would be good to come up with a common version rather than duplicating for each board. This is now what the env looks like for highbank in current firmware:

kernel_boot=echo Trying kernel...; ${fs}load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}vmlinuz && ${fs}load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr} script_boot=echo Trying script images...; for script in ${boot_scripts}; do ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}${script} && echo Executing ${prefix}${script}... && source ${script_addr}; done;
env_boot=echo Trying environment file...; ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}uEnv.txt && Executing ${prefix}uEnv.txt... && env import -t ${script_addr} ${filesize}};

Quoted 11 lines

kernel_boot=echo Trying kernel...; ${fs}load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}vmlinuz && ${fs}load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr} script_boot=echo Trying script images...; for script in ${boot_scripts}; do ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}${script} && echo Executing ${prefix}${script}... && source ${script_addr}; done;
env_boot=echo Trying environment file...; ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}uEnv.txt && Executing ${prefix}uEnv.txt... && env import -t ${script_addr} ${filesize}};

Guys, this is just silly.. Your using both uEnv.txt/boot.scr scripts by default, which you could use to "hide" all this extra stuff in a text file on the boot drive, that way mainline u-boot doesn't have to be patched for every little change. ;)

I know it's bikeshedding, but most boards can be converted to just:

#define CONFIG_BOOTCOMMAND \
	"mmc dev ${mmcdev};" \
	"if mmc rescan; then " \
		"echo SD/MMC found on device ${mmcdev};" \
		"if run loadbootenv; then " \
			"run importbootenv;" \
		"fi;" \
		"if test -n $uenvcmd; then " \
			"echo Running uenvcmd ...;" \
			"run uenvcmd;" \
		"fi;" \
		"if run loadsomefailsafedefault; then " \
			"run mmcboot;" \
		"fi;" \
	"fi;"

#endif

Hi Dennis,

Quoted 16 lines · Robert Nelson

Quoted 11 lines

kernel_boot=echo Trying kernel...; ${fs}load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}vmlinuz && ${fs}load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr} script_boot=echo Trying script images...; for script in ${boot_scripts}; do ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}${script} && echo Executing ${prefix}${script}... && source ${script_addr}; done;
env_boot=echo Trying environment file...; ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}uEnv.txt && Executing ${prefix}uEnv.txt... && env import -t ${script_addr} ${filesize}};

Guys, this is just silly.. Your using both uEnv.txt/boot.scr scripts by default, which you could use to "hide" all this extra stuff in a text file on the boot drive, that way mainline u-boot doesn't have to be patched for every little change. ;)

Quoted 17 lines

I know it's bikeshedding, but most boards can be converted to just:

#define CONFIG_BOOTCOMMAND \
	"mmc dev ${mmcdev};" \
	"if mmc rescan; then " \
		"echo SD/MMC found on device ${mmcdev};" \
		"if run loadbootenv; then " \
			"run importbootenv;" \
		"fi;" \
		"if test -n $uenvcmd; then " \
			"echo Running uenvcmd ...;" \
			"run uenvcmd;" \
		"fi;" \
		"if run loadsomefailsafedefault; then " \
			"run mmcboot;" \
		"fi;" \
	"fi;"

Quoted 1 line

#endif

Right - the meaning of CONFIG_EXTRA_ENV_SETTINGS is to have a minimal default environment, allowing the user to extend it to a full blown adding whatever he wants. However, in the last times I see that the meaning is moving to *the environment*. There is something wrong, also because, as Robert says, each small change require to patch u-boot. But then, why do you need the environment at all ?

And the setup is then suitable for a strict range of applications, but not all.

Regards,
Stefano Babic

ultimately I want to have a standard way to boot any system that just works and does not need the installer to know or care what the target system is. using boot.scr and uEnv.txt does not work for my goals.

Quoted 18 lines

Quoted 17 lines

I know it's bikeshedding, but most boards can be converted to just:

#define CONFIG_BOOTCOMMAND \
	"mmc dev ${mmcdev};" \
	"if mmc rescan; then " \
		"echo SD/MMC found on device ${mmcdev};" \
		"if run loadbootenv; then " \
			"run importbootenv;" \
		"fi;" \
		"if test -n $uenvcmd; then " \
			"echo Running uenvcmd ...;" \
			"run uenvcmd;" \
		"fi;" \
		"if run loadsomefailsafedefault; then " \
			"run mmcboot;" \
		"fi;" \
	"fi;"

Quoted 1 line

#endif

ultimately for Fedora we do not want to use uEnv.txt or boot.scr at all we want to use a extlinux.conf file and sysboot provided by cmd_pxe the rest is to provide flexibility and options to users to choose different ways to boot. the above is not at all suitable.

ultimately I want to have a standard way to boot any system that just works and does not need the installer to know or care what the target system is. using boot.scr and uEnv.txt does not work for my goals.

ultimately for Fedora we do not want to use uEnv.txt or boot.scr at all we want to use a extlinux.conf file and sysboot provided by cmd_pxe the rest is to provide flexibility and options to users to choose different ways to boot. the above is not at all suitable.

Dear Dennis,

Quoted 4 lines · In message <[email protected]> you wrote:

ultimately I want to have a standard way to boot any system that just works and does not need the installer to know or care what the target system is. using boot.scr and uEnv.txt does not work for my goals.

But your requirement is just one out of a number of such requirements, and I see no indication that an "one size fits all" approach would be possible.

Quoted 4 lines

ultimately for Fedora we do not want to use uEnv.txt or boot.scr at all we want to use a extlinux.conf file and sysboot provided by cmd_pxe the rest is to provide flexibility and options to users to choose different ways to boot. the above is not at all suitable.

Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: "I'm right, you all are wrong."

The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many.

Quoted 4 lines

But your requirement is just one out of a number of such requirements, and I see no indication that an "one size fits all" approach would be possible.

And today we have no ability to easily opt-in to any of the "one size fits many" approachs we have scattered about in config files today.

Quoted 3 lines

Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: "I'm right, you all are wrong."

Well, from their (the distro point of view) point of view, they don't want to have to come up with yet another set of tools (like they're having to do today, there's a rather large hunk of logic Fedora has for booting a handful of boards). I'd really love to see someone come up with a parser of extlinux.conf
(http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/) for U-Boot.

Quoted 8 lines

The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many.

That a large number of maker folks are using ARM boards, that use Linux and U-Boot is a good thing. That it's quite a pain for each new board and user to get a familiar environment up, is a problem. And I would say the defaults in reference platforms should be pretty wide ranging.

Dear Tom Rini,

Quoted 7 lines · In message <20130804202746.GH5164@bill-the-cat> you wrote:

Quoted 4 lines

But your requirement is just one out of a number of such requirements, and I see no indication that an "one size fits all" approach would be possible.

And today we have no ability to easily opt-in to any of the "one size fits many" approachs we have scattered about in config files today.

I am not that pessimistic. The tools are all available and in place. "env import" (and other capabilities of the "env" command) allow to import any set of environment from any storage location U-Boot can handle. This allows to implement all kind of fancy features, like "user profiles", "reset to factory defaults", etc. etc. Of course it also allows to implement settings needed to support booting of a standard distribution.

Quoted 11 lines

Quoted 3 lines

Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: "I'm right, you all are wrong."

Well, from their (the distro point of view) point of view, they don't want to have to come up with yet another set of tools (like they're having to do today, there's a rather large hunk of logic Fedora has for booting a handful of boards). I'd really love to see someone come up with a parser of extlinux.conf
(http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/) for U-Boot.

You mean, as an external tool, to translate extlinux.conf into a set of U-Boot commands?

Quoted 9 lines

Quoted 8 lines

The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many.

Quoted 4 lines

That a large number of maker folks are using ARM boards, that use Linux and U-Boot is a good thing. That it's quite a pain for each new board and user to get a familiar environment up, is a problem. And I would say the defaults in reference platforms should be pretty wide ranging.

Define "reference platform"? Do you think, for example, systems in
the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to run Fedora? Does Fedora actually support any targets below ARMv7 ?

Quoted 8 lines

I am not that pessimistic. The tools are all available and in place. "env import" (and other capabilities of the "env" command) allow to import any set of environment from any storage location U-Boot can handle. This allows to implement all kind of fancy features, like "user profiles", "reset to factory defaults", etc. etc. Of course it also allows to implement settings needed to support booting of a standard distribution.

How far back do we have an env import command available to all, is one the questions. ...

... I hadn't thought about saying part of the solution is
that distros should provide an environment file to import (and if applicable, saveenv'ing after). But what I mean is that we have a half dozen (it feels like) semi-flexible environments different boards/socs compile in, and it's not easy to share those. One of the requests is a "sane" default boot command, and we do have a number of boards out there without a savable environment.

Quoted 2 lines

You mean, as an external tool, to translate extlinux.conf into a set of U-Boot commands?

No, I mean as a run-time command in u-boot to, given a pointer to extlinux.conf in memory, translate to a set of boot commands. The use case here is that user installs (via package manager) a new kernel and just like on your desktop you can chose to boot it, easily enough.

Quoted 3 lines

Define "reference platform"? Do you think, for example, systems in
the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to run Fedora? Does Fedora actually support any targets below ARMv7 ?

Fedora (and Ubuntu) don't officialy support sub-v7 platforms but that hasn't deterred the RPi community from making it happen all the same. But yes, AM1808 and i.MX28 and anything else with community support, IOs and upstream support is quite useful for maker folks (again, see RPi). Debian, iirc, still supports ARMv5 out of the box, and I'm sure anything that makes "Just Working" out of the box would be welcome in OpenEmbedded/Yocto-land.

I'm going to (in a while) hop on the other thread Dennis started and cross-posted to the cross-distro list, but I firmly believe an opt-in set of defaults that let distros have to care less about board specifics is important.

Dear Tom,

Quoted 9 lines · In message <20130804214743.GJ5164@bill-the-cat> you wrote:

Quoted 8 lines

I am not that pessimistic. The tools are all available and in place. "env import" (and other capabilities of the "env" command) allow to import any set of environment from any storage location U-Boot can handle. This allows to implement all kind of fancy features, like "user profiles", "reset to factory defaults", etc. etc. Of course it also allows to implement settings needed to support booting of a standard distribution.

Quoted 2 lines

How far back do we have an env import command available to all, is one the questions. ...

The support for this was added with commit ea882ba "New implementation for internal handling of environment variables." on Sun Jun 20, 2010, i. e. more than 2 years ago.

That's a long time, actually.

Quoted 7 lines

... I hadn't thought about saying part of the solution is
that distros should provide an environment file to import (and if applicable, saveenv'ing after). But what I mean is that we have a half dozen (it feels like) semi-flexible environments different boards/socs compile in, and it's not easy to share those. One of the requests is a "sane" default boot command, and we do have a number of boards out there without a savable environment.

Requests for a "sane" environment are comprehensible. However, it will be difficult to reach an agreement what exactly "sane" means here. For example, I have never been able to get accustomed to all the uEnv.txt, user.txt etc. scripts used with a number of boards; for me, all this seems way too complicated and inflexible, and I always try to get rid of this stuff. I'm aware that other people like the approach. OK - I see no problems with that: TIMTOWTDI.

I would only have a problem (and a serious one) if such an approach became standard, or even mandatory. Not to mention a large number of projects I know of.

Quoted 7 lines

Quoted 2 lines

You mean, as an external tool, to translate extlinux.conf into a set of U-Boot commands?

No, I mean as a run-time command in u-boot to, given a pointer to extlinux.conf in memory, translate to a set of boot commands. The use case here is that user installs (via package manager) a new kernel and just like on your desktop you can chose to boot it, easily enough.

Can we not rather do the translation on the host side, so we don;t have to add both the code and the runtime overhead for each boot process?

Quoted 11 lines

Quoted 3 lines

Define "reference platform"? Do you think, for example, systems in
the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to run Fedora? Does Fedora actually support any targets below ARMv7 ?

Fedora (and Ubuntu) don't officialy support sub-v7 platforms but that hasn't deterred the RPi community from making it happen all the same. But yes, AM1808 and i.MX28 and anything else with community support, IOs and upstream support is quite useful for maker folks (again, see RPi). Debian, iirc, still supports ARMv5 out of the box, and I'm sure anything that makes "Just Working" out of the box would be welcome in OpenEmbedded/Yocto-land.

Well, OE and Yocto allow to build fine-tuned target environments; they really don't have any new requirements as "standard" distros like Fedroa do.

Quoted 3 lines

Well, OE and Yocto allow to build fine-tuned target environments; they really don't have any new requirements as "standard" distros like Fedroa do.

Yeah, and it's also true that less per machine hacking you have to do with each new board, the easier it is (and the better the out of box experience it is on their side). We just synced up the environment on wandboard with how OE likes to see it. If it was instead they just had to provide an environment text file in the machine overlay or even just generate a default one (since the image is only going to have one kernel most likely), it'd be a win on that side.

Quoted 11 lines · Tom Rini

Quoted 3 lines

Well, OE and Yocto allow to build fine-tuned target environments; they really don't have any new requirements as "standard" distros like Fedroa do.

Yeah, and it's also true that less per machine hacking you have to do with each new board, the easier it is (and the better the out of box experience it is on their side). We just synced up the environment on wandboard with how OE likes to see it. If it was instead they just had to provide an environment text file in the machine overlay or even just generate a default one (since the image is only going to have one kernel most likely), it'd be a win on that side.

Yes but OE is not the best reference here. There we can do whatever is need.

One thing I do miss is consistency. I've been trying to keep all Freescale boards I work with in sync, and it does make my life easier so I don't need to read the environment to understand how to accomplish what I need.

Simon's proposal for text version of default environment is a move to the right direction, it seems, as will easy reuse of environment among boards.

I think, specially for development kits, the default environment must be as flexible and generic as possible. Part of product development will be trimm it to fulfil product needs. I agree with Tom that we need to get a better and more general used default environment setting.

Quoted 4 lines

Simon's proposal for text version of default environment is a move to the right direction, it seems, as will easy reuse of environment among boards.

I need to look at this again, I think the biggest problem / concern I had was about multi-line stuff.

Dear Tom,

Quoted 5 lines · In message <20130805190949.GS5164@bill-the-cat> you wrote:

Quoted 4 lines

Simon's proposal for text version of default environment is a move to the right direction, it seems, as will easy reuse of environment among boards.

Quoted 2 lines

I need to look at this again, I think the biggest problem / concern I had was about multi-line stuff.

"env import" has been tested to even handle multi-line variable settings correctly. I know I repeat myself again, but instead of hard-coding environment settings into the U-Boot binary (no matter if they come from a C header file or form a text file processed in some way) is not the most clever way to handle such requirements.

Quoted 4 lines

But your requirement is just one out of a number of such requirements, and I see no indication that an "one size fits all" approach would be possible.

It should be possible for those systems that want a generic linux distro to run on them. ...

... AFAIK the wandboard systems are one of those
that do. It's also a system that doesn't ship with any onboard storage so distros are forced to build u-boot for it.

Quoted 3 lines

Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: "I'm right, you all are wrong."

its not at all, if there is some way to achieve much the same thing using some other method please let me know. I don't want to force some solution everywhere. but i want the same solution to be in place for boards that want to have a generic linux distro be supported on it.

Dear Dennis,

Quoted 1 line · In message <[email protected]> you wrote:

Quoted 4 lines

ultimately I want to have a standard way to boot any system that just works and does not need the installer to know or care what the target system is. using boot.scr and uEnv.txt does not work for my goals.

But your requirement is just one out of a number of such requirements, and I see no indication that an "one size fits all" approach would be possible.

Quoted 4 lines

ultimately for Fedora we do not want to use uEnv.txt or boot.scr at all we want to use a extlinux.conf file and sysboot provided by cmd_pxe the rest is to provide flexibility and options to users to choose different ways to boot. the above is not at all suitable.

Just stating what you don't want, and what you want, is not exactly a constructive process. It's like saying: "I'm right, you all are wrong."

The thing is, that the overwhelming majority of systems are not running a standard distro like Fedora, and don't have any such features as boot extlinux.conf files or sysboot or whatever -they don;t have it, and they cannot afford it because they have totally different requirements to meet. Please try and keep this in mind. Yourrequiremetns are but a special case here - one which we will try to support in the best possible way, of course, but it's just one out of many.

Hi Dennis,

Quoted 35 lines · Robert Nelson

Quoted 11 lines

kernel_boot=echo Trying kernel...; ${fs}load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}vmlinuz && ${fs}load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}initrd.img && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr} script_boot=echo Trying script images...; for script in ${boot_scripts}; do ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}${script} && echo Executing ${prefix}${script}... && source ${script_addr}; done;
env_boot=echo Trying environment file...; ${fs}load ${devtype} ${devnum} ${script_addr} ${prefix}uEnv.txt && Executing ${prefix}uEnv.txt... && env import -t ${script_addr} ${filesize}};

Guys, this is just silly.. Your using both uEnv.txt/boot.scr scripts by default, which you could use to "hide" all this extra stuff in a text file on the boot drive, that way mainline u-boot doesn't have to be patched for every little change. ;)

I know it's bikeshedding, but most boards can be converted to just:

#define CONFIG_BOOTCOMMAND \
	"mmc dev ${mmcdev};" \
	"if mmc rescan; then " \
		"echo SD/MMC found on device ${mmcdev};" \
		"if run loadbootenv; then " \
			"run importbootenv;" \
		"fi;" \
		"if test -n $uenvcmd; then " \
			"echo Running uenvcmd ...;" \
			"run uenvcmd;" \
		"fi;" \
		"if run loadsomefailsafedefault; then " \
			"run mmcboot;" \
		"fi;" \
	"fi;"

#endif

Quoted 1 line

Right - the meaning of CONFIG_EXTRA_ENV_SETTINGS is to have a minimal default environment, allowing the user to extend it to a full blown adding whatever he wants. However, in the last times I see that the meaning is moving to *the environment*. There is something wrong, also because, as Robert says, each small change require to patch u-boot. But then, why do you need the environment at all ?

And the setup is then suitable for a strict range of applications, but not all.

You both are missing the point. This patch doesn't address the problem, but does highlight it.

The distros want to get out of having to know the
u-boot environment details for every single board and need some level of standardization across platforms. The distros should only have to specify "boot the kernel at path/name X on device Y." They should not need to know what address to load the kernel to, but only that $kernel_addr_r is already setup. Variables are the first step. The second step is standardizing the boot commands.

Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ?

Hi Rob, Dennis,

Quoted 2 lines · Rob Herring

You both are missing the point. This patch doesn't address the problem, but does highlight it.

I am aware of it - I have already pointed out that we get many patches that have increased the default environment to something hard to maintain. This patch makes it more obvious.

Quoted 7 lines

The distros want to get out of having to know the
u-boot environment details for every single board and need some level of standardization across platforms. The distros should only have to specify "boot the kernel at path/name X on device Y." They should not need to know what address to load the kernel to, but only that $kernel_addr_r is already setup. Variables are the first step. The second step is standardizing the boot commands.

I understand the point - but is the way to hard code together with u-boot the right way ? Do we have some other possibilities to do this ?

Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ?

Hi Rob, Dennis,

Quoted 2 lines · Rob Herring

You both are missing the point. This patch doesn't address the problem, but does highlight it.

I am aware of it - I have already pointed out that we get many patches that have increased the default environment to something hard to maintain. This patch makes it more obvious.

Quoted 7 lines

The distros want to get out of having to know the
u-boot environment details for every single board and need some level of standardization across platforms. The distros should only have to specify "boot the kernel at path/name X on device Y." They should not need to know what address to load the kernel to, but only that $kernel_addr_r is already setup. Variables are the first step. The second step is standardizing the boot commands.

I understand the point - but is the way to hard code together with u-boot the right way ? Do we have some other possibilities to do this ?

Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ?

Quoted 6 lines

Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ?

I definitely agree that we should move this out of C code and support standalone text files as input. IIRC, CONFIG_EXTRA_ENV_SETTINGS is replaced by any separate environment. I think it also needs to support being merged with a separate environment.

Dear Rob Herring,

Quoted 11 lines · In message <CAL_JsqK++KbAajYtp9UnJuHWd=f8pjHSK0x3hzf73PCHdL_M6A@mail.gmail.com>…

Quoted 6 lines

Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ?

I definitely agree that we should move this out of C code and support standalone text files as input. IIRC, CONFIG_EXTRA_ENV_SETTINGS is replaced by any separate environment. I think it also needs to support being merged with a separate environment.

Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do.

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

Quoted 5 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

But we have to start _somewhere_ with a compiled-in set of defaults.

Yes, some boards are easily updatable (it's just an SD card), but on others it's not. And there's a strong desire on the generic distro side (and on a lot of kernel hackers sides) to treat U-Boot as never-touch binaries. What ships is what's used. So a default that tries to load

a controlable file is what started all of the boot.scr or uEnv.txt stuff.

Dear Tom,

Quoted 6 lines · In message <20130805160747.GP5164@bill-the-cat> you wrote:

Quoted 5 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

Quoted 1 line

But we have to start _somewhere_ with a compiled-in set of defaults.

Agreed, nbut that should be a very minimal set of setting that is common to most use cases.

Quoted 4 lines

Yes, some boards are easily updatable (it's just an SD card), but on others it's not. And there's a strong desire on the generic distro side (and on a lot of kernel hackers sides) to treat U-Boot as never-touch binaries. What ships is what's used. So a default that tries to load

I perfectly understand this argument, and this is exactly why I think that a hard-coded, compiled in set of complex settings (as needed for a standard distro, from what I've seen so far), would be a seriously wrong approach. You _will_ need to make changes to such settings over time, so plan for it, and provide an easy "never-touch U-Boot itself" way for it.

Dear Rob Herring,

Quoted 7 lines · In message <CAL_JsqK++KbAajYtp9UnJuHWd=f8pjHSK0x3hzf73PCHdL_M6A@mail.gmail.com>…

Quoted 6 lines

Maybe can be mkenvimage a solution (tools/mkenvimage) ? It creates an environment image from a simple ASCII text. The resulting image could be concatenated together with u-boot and in CONFIG_EXTRA_ENV_SETTINGS we could have for all boards a way to load it. Only a first idea, but as we recognize the issue, any idea to solve it ?

Quoted 4 lines

I definitely agree that we should move this out of C code and support standalone text files as input. IIRC, CONFIG_EXTRA_ENV_SETTINGS is replaced by any separate environment. I think it also needs to support being merged with a separate environment.

Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do.

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

Quoted 4 lines

Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do.

You may want to have factory default and "user" settings. Building in the factory settings would be one way to accomplish that.

Quoted 4 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

In my case, I don't want to compile the environment into u-boot. But some people do as I copied my scripts from Tegra which has them built-in. Since built-in is C and standalone is text file, sharing is impossible. That is the main thing I'd like to see changed. Whether we support merging builtin and standalone envs is secondary.

Dear Rob Herring,

Quoted 5 lines · In message <CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com>…

Quoted 4 lines

Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do.

Quoted 2 lines

You may want to have factory default and "user" settings. Building in the factory settings would be one way to accomplish that.

No. Handling these independently, outside of the compiled U-Boot image is as easy, and much more flexible.

Quoted 8 lines

Quoted 4 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

In my case, I don't want to compile the environment into u-boot. But some people do as I copied my scripts from Tegra which has them built-in.

Quoted 19 lines · Wolfgang Denk

Dear Rob Herring,

Quoted 7 lines · In message <CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com>…

Quoted 4 lines

Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do.

You may want to have factory default and "user" settings. Building in the factory settings would be one way to accomplish that.

No. Handling these independently, outside of the compiled U-Boot image is as easy, and much more flexible.

Quoted 5 lines

Quoted 4 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

Quoted 3 lines

Quoted 3 lines

In my case, I don't want to compile the environment into u-boot. But some people do as I copied my scripts from Tegra which has them built-in.

We have the *default* environment built-in, which is used when no valid environment is found in flash. If there's an environment in flash, it gets used rather than the built-in default.

Quoted 24 lines · Stephen Warren

Quoted 22 lines · Wolfgang Denk

Dear Rob Herring,

Quoted 7 lines · In message <CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com>…

Quoted 4 lines

Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do.

You may want to have factory default and "user" settings. Building in the factory settings would be one way to accomplish that.

No. Handling these independently, outside of the compiled U-Boot image is as easy, and much more flexible.

Quoted 8 lines

Quoted 4 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

In my case, I don't want to compile the environment into u-boot. But some people do as I copied my scripts from Tegra which has them built-in.

Quoted 3 lines

We have the *default* environment built-in, which is used when no valid environment is found in flash. If there's an environment in flash, it gets used rather than the built-in default.

How can someone 'overwrite' the default environment from system or when generating a FIT image?

I am interested in let my customers to revert back to a sane default running:

env -f -d -a
saveenv

Quoted 2 lines

How can someone 'overwrite' the default environment from system or when generating a FIT image?

If U-Boot is running, you can get back to the default environment by running exactly the commands you wrote below.

If you're flashing U-Boot, you could force it to use the default environment when it boots by erasing/corrupting the copy of the environment that's stored in flash (or wherever ENV_IS points) at the same time that you flash the new U-Boot binary.

The question of how to get the default environment when generating a FIT image doesn't make sense; generating a FIT image of something (kernel, initrd, DTB?) is entirely unrelated to the environment content that U-Boot uses when running.

Quoted 11 lines · Stephen Warren

Quoted 2 lines

How can someone 'overwrite' the default environment from system or when generating a FIT image?

If U-Boot is running, you can get back to the default environment by running exactly the commands you wrote below.

If you're flashing U-Boot, you could force it to use the default environment when it boots by erasing/corrupting the copy of the environment that's stored in flash (or wherever ENV_IS points) at the same time that you flash the new U-Boot binary.

Quoted 4 lines

The question of how to get the default environment when generating a FIT image doesn't make sense; generating a FIT image of something (kernel, initrd, DTB?) is entirely unrelated to the environment content that U-Boot uses when running.

Ok but when I do env -f -d -a it uses the built-in environment as default. How can I 'change' this default without rebuilding U-Boot binary?

Quoted 12 lines · Otavio Salvador

Quoted 11 lines · Stephen Warren

Quoted 2 lines

How can someone 'overwrite' the default environment from system or when generating a FIT image?

If U-Boot is running, you can get back to the default environment by running exactly the commands you wrote below.

If you're flashing U-Boot, you could force it to use the default environment when it boots by erasing/corrupting the copy of the environment that's stored in flash (or wherever ENV_IS points) at the same time that you flash the new U-Boot binary.

Quoted 8 lines

Quoted 4 lines

The question of how to get the default environment when generating a FIT image doesn't make sense; generating a FIT image of something (kernel, initrd, DTB?) is entirely unrelated to the environment content that U-Boot uses when running.

Ok but when I do env -f -d -a it uses the built-in environment as default. How can I 'change' this default without rebuilding U-Boot binary?

I don't believe you can. Why would you want to? It's the default environment that makes sense for that board, and that's defined by the person creating U-Boot.

If you want the user to be able to switch between different environments, just have them save/load from a disk file that they create. I think there's a command for that?

Quoted 11 lines · Stephen Warren

Quoted 2 lines

How can someone 'overwrite' the default environment from system or when generating a FIT image?

If U-Boot is running, you can get back to the default environment by running exactly the commands you wrote below.

If you're flashing U-Boot, you could force it to use the default environment when it boots by erasing/corrupting the copy of the environment that's stored in flash (or wherever ENV_IS points) at the same time that you flash the new U-Boot binary.

Quoted 4 lines

The question of how to get the default environment when generating a FIT image doesn't make sense; generating a FIT image of something (kernel, initrd, DTB?) is entirely unrelated to the environment content that U-Boot uses when running.

Ok but when I do env -f -d -a it uses the built-in environment as default. How can I 'change' this default without rebuilding U-Boot binary?

Quoted 12 lines · Otavio Salvador

Quoted 11 lines · Stephen Warren

Quoted 2 lines

How can someone 'overwrite' the default environment from system or when generating a FIT image?

If U-Boot is running, you can get back to the default environment by running exactly the commands you wrote below.

If you're flashing U-Boot, you could force it to use the default environment when it boots by erasing/corrupting the copy of the environment that's stored in flash (or wherever ENV_IS points) at the same time that you flash the new U-Boot binary.

Quoted 8 lines

Quoted 4 lines

The question of how to get the default environment when generating a FIT image doesn't make sense; generating a FIT image of something (kernel, initrd, DTB?) is entirely unrelated to the environment content that U-Boot uses when running.

Ok but when I do env -f -d -a it uses the built-in environment as default. How can I 'change' this default without rebuilding U-Boot binary?

What you want (and I'm not saying this works today) would be:
load ... $addr otavios-sane-env.txt
env import -t --reset-to $addr

Where --reset-to cleared the current environment and set it to only the valid env found at $addr.

Quoted 12 lines · Otavio Salvador

Quoted 11 lines · Stephen Warren

Quoted 2 lines

How can someone 'overwrite' the default environment from system or when generating a FIT image?

If U-Boot is running, you can get back to the default environment by running exactly the commands you wrote below.

If you're flashing U-Boot, you could force it to use the default environment when it boots by erasing/corrupting the copy of the environment that's stored in flash (or wherever ENV_IS points) at the same time that you flash the new U-Boot binary.

Quoted 8 lines

Quoted 4 lines

The question of how to get the default environment when generating a FIT image doesn't make sense; generating a FIT image of something (kernel, initrd, DTB?) is entirely unrelated to the environment content that U-Boot uses when running.

Ok but when I do env -f -d -a it uses the built-in environment as default. How can I 'change' this default without rebuilding U-Boot binary?

What you want (and I'm not saying this works today) would be:
load ... $addr otavios-sane-env.txt
env import -t --reset-to $addr

Where --reset-to cleared the current environment and set it to only the valid env found at $addr.

Dear Rob Herring,

In message <CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com>

Quoted 5 lines · you

Quoted 4 lines

Why would you ever want to compile this into U-Boot at all? Then any changes you need to make mean compiling and installing a new U-Boot, which is something you normally don't want to do.

Quoted 2 lines

You may want to have factory default and "user" settings. Building in the factory settings would be one way to accomplish that.

No. Handling these independently, outside of the compiled U-Boot image is as easy, and much more flexible.

Quoted 10 lines

Quoted 4 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

In my case, I don't want to compile the environment into u-boot. But some people do as I copied my scripts from Tegra which has them built-in. Since built-in is C and standalone is text file, sharing is impossible. That is the main thing I'd like to see changed. Whether we support merging builtin and standalone envs is secondary.

Who says "impossible" here? When using a file system with write support, you can use "env export -t" to create a text representation and write it out to the file system (or store it in some reserved area on some storage device).

My issue with this is, we produce a unified image, it could be an installer image or a installed disk image. it has a unified kernel in it and can run on any number of soc's but we also need to provide tooling that will setup the u-boot image so that it can be loaded by different boards. be it copying files into place or dding the binary into some offset. it kills the portability. i can't pull a sdcard from one board with one type of soc and plug it into another and have it just boot.

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

U-Boot is perfectly able to import such settings from text files (or text blobs stored somewhere, even attached to the U-Boot image, if you want), so just use the text files separately, instead of hard compiling them into the code.

In my case, I don't want to compile the environment into u-boot. But some people do as I copied my scripts from Tegra which has them built-in. Since built-in is C and standalone is text file, sharing is impossible. That is the main thing I'd like to see changed. Whether we support merging builtin and standalone envs is secondary.

Quoted 4 lines

Who says "impossible" here? When using a file system with write support, you can use "env export -t" to create a text representation and write it out to the file system (or store it in some reserved area on some storage device).

Exactly what i want to avoid. I really do want it compiled into the binary. because then I only have to put one file into place. on those systems needing it.

another solution for me would be a unified u-boot that runs on all soc's and all boards. Everytime we have to do something different for a board or soc family is a step away from having something truly universal and portable.

some variables that would need to be compiled in

fdt_addr
fdt_addr_r
kernel_addr_r
ramdisk_addr_r

pxefile_addr_r
scr_addr_r
uenv_addr_r

The only way I could see having us write a file to disk with the environment working is if all boards implement standard variable to define the memory locations and that is compiled into the u-boot binary.

some variables that would need to be compiled in

fdt_addr
fdt_addr_r

kernel_addr_r
ramdisk_addr_r
pxefile_addr_r
scr_addr_r
uenv_addr_r

this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux

On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:

[snip]

Quoted 5 lines

The only way I could see having us write a file to disk with the environment working is if all boards implement standard variable to define the memory locations and that is compiled into the u-boot binary.

Quoted 4 lines

some variables that would need to be compiled in

fdt_addr
fdt_addr_r

Why two?

Quoted 8 lines

kernel_addr_r
ramdisk_addr_r
pxefile_addr_r
scr_addr_r
uenv_addr_r

this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux

This is what I think we need to work towards. A board opting into this standard must set CONFIG_CMD_A/B/C (or maybe we add a CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the fallback files, whatever) and provide the following variables PLUS a, and this needs some thinking I think, auto-boot tries to load said file from ... ?

We cannot provide a built-in environment that works for every distro and case, we want the distro to tell us things it knows, and we'll tell it what it can't easily know.

Quoted 8 lines · On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini <[email protected]> wrote:

On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:

[snip]

Quoted 5 lines

The only way I could see having us write a file to disk with the environment working is if all boards implement standard variable to define the memory locations and that is compiled into the u-boot binary.

Quoted 6 lines

Quoted 4 lines

some variables that would need to be compiled in

fdt_addr
fdt_addr_r

Why two?

from cmd_pxe.c

u-boot by default would load a dtb to fdt_addr but a user could at least in the pxe/extlinux case load their own dtb if the want/need to.

the only way a dtb would be optional is if fdtfile is not set

Quoted 16 lines

Quoted 8 lines

kernel_addr_r
ramdisk_addr_r
pxefile_addr_r
scr_addr_r
uenv_addr_r

this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux

This is what I think we need to work towards. A board opting into this standard must set CONFIG_CMD_A/B/C (or maybe we add a CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the fallback files, whatever) and provide the following variables PLUS a, and this needs some thinking I think, auto-boot tries to load said file from ... ?

Quoted 3 lines

We cannot provide a built-in environment that works for every distro and case, we want the distro to tell us things it knows, and we'll tell it what it can't easily know.

we absolutely can, I would like for u-boot to load a dtb before doing anything. u-boot should know what devices can be booted from and likely an order of preference. i.e. removable media through to fixed, and finally pxe.

i would like for u-boot to first try to
load /boot/extlinux/extlinux.conf then /extlinux/extlinux.conf failing that try to load a /boot/uEnv.txt then /uEnv.txt and import that running with what is in it, then falling back to a /boot/boot.scr then /boot.scr then finally running dhcp, pxe get, and pxe boot.

Quoted 18 lines · Dennis Gilmore

Quoted 8 lines · On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini <[email protected]> wrote:

On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:

[snip]

Quoted 5 lines

The only way I could see having us write a file to disk with the environment working is if all boards implement standard variable to define the memory locations and that is compiled into the u-boot binary.

Quoted 6 lines

Quoted 4 lines

some variables that would need to be compiled in

fdt_addr
fdt_addr_r

Why two?

from cmd_pxe.c

[snip]

Quoted 5 lines

u-boot by default would load a dtb to fdt_addr but a user could at least in the pxe/extlinux case load their own dtb if the want/need to.

the only way a dtb would be optional is if fdtfile is not set

OK, so fdt_addr is for a memory-mapped location of the DT existing somewhere already, basically.

Quoted 16 lines

Quoted 16 lines

Quoted 8 lines

kernel_addr_r
ramdisk_addr_r
pxefile_addr_r
scr_addr_r
uenv_addr_r

this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux

This is what I think we need to work towards. A board opting into this standard must set CONFIG_CMD_A/B/C (or maybe we add a CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the fallback files, whatever) and provide the following variables PLUS a, and this needs some thinking I think, auto-boot tries to load said file from ... ?

Quoted 8 lines

Quoted 3 lines

We cannot provide a built-in environment that works for every distro and case, we want the distro to tell us things it knows, and we'll tell it what it can't easily know.

we absolutely can, I would like for u-boot to load a dtb before doing anything. u-boot should know what devices can be booted from and likely an order of preference. i.e. removable media through to fixed, and finally pxe.

Looking at a couple of device trees, no, we can't. I don't see any useful information like "this is an SD controller" for example (and all of the mmc bindings that might provide a reliable clue are optional ones). So, at the high level, if U-Boot relied on DTs in every driver, we might be able to do what you're talking about. But we don't do that today, and probably won't for a long time, if ever.

But we will know what devices are likely to exist and be bootable, at build time. What we can do is try and load a file from everywhere we expect might be someplace with this file in it. We could even set some standard variables based on having found and loaded this file, so it can assume that everything else exists in this same place (or the file we have loaded knows better).

Quoted 6 lines

i would like for u-boot to first try to
load /boot/extlinux/extlinux.conf then /extlinux/extlinux.conf failing that try to load a /boot/uEnv.txt then /uEnv.txt and import that running with what is in it, then falling back to
a /boot/boot.scr then /boot.scr then finally running dhcp, pxe get, and pxe boot.

I'd like to see most of that logic held in the file we load (so that when something replaces extlinux.conf as the preferred method, it just works still, or whatever) and run a command from. And fall back to dhcp+pxe for the install case.

Quoted 5 lines · On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini <[email protected]> wrote:

Quoted 4 lines · Dennis Gilmore

Quoted 1 line · On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini <[email protected]> wrote:

On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:

Quoted 32 lines

Quoted 16 lines

Quoted 16 lines

Quoted 8 lines

kernel_addr_r
ramdisk_addr_r
pxefile_addr_r
scr_addr_r
uenv_addr_r

this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux

This is what I think we need to work towards. A board opting into this standard must set CONFIG_CMD_A/B/C (or maybe we add a CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the fallback files, whatever) and provide the following variables PLUS a, and this needs some thinking I think, auto-boot tries to load said file from ... ?

Quoted 8 lines

Quoted 3 lines

We cannot provide a built-in environment that works for every distro and case, we want the distro to tell us things it knows, and we'll tell it what it can't easily know.

we absolutely can, I would like for u-boot to load a dtb before doing anything. u-boot should know what devices can be booted from and likely an order of preference. i.e. removable media through to fixed, and finally pxe.

Looking at a couple of device trees, no, we can't. I don't see any useful information like "this is an SD controller" for example (and all of the mmc bindings that might provide a reliable clue are optional ones). So, at the high level, if U-Boot relied on DTs in every driver, we might be able to do what you're talking about. But we don't do that today, and probably won't for a long time, if ever.

Quoted 6 lines

But we will know what devices are likely to exist and be bootable, at build time. What we can do is try and load a file from everywhere we expect might be someplace with this file in it. We could even set some standard variables based on having found and loaded this file, so it can assume that everything else exists in this same place (or the file we have loaded knows better).

I was thinking more along the lines of us knowing what is likely to be there than pulling it from the DT and basically doing something like you mentioned here.

Quoted 7 lines

Quoted 6 lines

i would like for u-boot to first try to
load /boot/extlinux/extlinux.conf then /extlinux/extlinux.conf failing that try to load a /boot/uEnv.txt then /uEnv.txt and import that running with what is in it, then falling back to
a /boot/boot.scr then /boot.scr then finally running dhcp, pxe get, and pxe boot.

Quoted 4 lines

I'd like to see most of that logic held in the file we load (so that when something replaces extlinux.conf as the preferred method, it just works still, or whatever) and run a command from. And fall back to dhcp+pxe for the install case.

where should the file we load come from? i would think when something comes along to replace extlinux.conf its likely going to need an updated u-boot to add some new functionality

Quoted 9 lines · Dennis Gilmore

Quoted 6 lines · On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini <[email protected]> wrote:

Quoted 5 lines · Dennis Gilmore

Quoted 2 lines · On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini <[email protected]> wrote:

On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:

[snip]

Quoted 41 lines

Quoted 33 lines

Quoted 16 lines

Quoted 16 lines

Quoted 8 lines

kernel_addr_r
ramdisk_addr_r
pxefile_addr_r
scr_addr_r
uenv_addr_r

this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux

This is what I think we need to work towards. A board opting into this standard must set CONFIG_CMD_A/B/C (or maybe we add a CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the fallback files, whatever) and provide the following variables PLUS a, and this needs some thinking I think, auto-boot tries to load said file from ... ?

Quoted 8 lines

Quoted 3 lines

We cannot provide a built-in environment that works for every distro and case, we want the distro to tell us things it knows, and we'll tell it what it can't easily know.

we absolutely can, I would like for u-boot to load a dtb before doing anything. u-boot should know what devices can be booted from and likely an order of preference. i.e. removable media through to fixed, and finally pxe.

Looking at a couple of device trees, no, we can't. I don't see any useful information like "this is an SD controller" for example (and all of the mmc bindings that might provide a reliable clue are optional ones). So, at the high level, if U-Boot relied on DTs in every driver, we might be able to do what you're talking about. But we don't do that today, and probably won't for a long time, if ever.

Quoted 7 lines

But we will know what devices are likely to exist and be bootable, at build time. What we can do is try and load a file from everywhere we expect might be someplace with this file in it. We could even set some standard variables based on having found and loaded this file, so it can assume that everything else exists in this same place (or the file we have loaded knows better).

Quoted 3 lines

I was thinking more along the lines of us knowing what is likely to be there than pulling it from the DT and basically doing something like you mentioned here.

Right. For clarity, the problem is that DTs aren't useful like that. They describe the hardware, but in non-generic terms.

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

i would like for u-boot to first try to
load /boot/extlinux/extlinux.conf then /extlinux/extlinux.conf failing that try to load a /boot/uEnv.txt then /uEnv.txt and import that running with what is in it, then falling back to a /boot/boot.scr then /boot.scr then finally running dhcp, pxe get, and pxe boot.

Quoted 8 lines

Quoted 4 lines

I'd like to see most of that logic held in the file we load (so that when something replaces extlinux.conf as the preferred method, it just works still, or whatever) and run a command from. And fall back to dhcp+pxe for the install case.

where should the file we load come from? i would think when something comes along to replace extlinux.conf its likely going to need an updated u-boot to add some new functionality

I'd like to see the file come from the distro. And given that another option here is 'go'ing to a copy of GRUB, I think we've got at least a good chance of future expansion being handled OK with this method. We try and load something from the distro that is generic, and make the hand-off there. (In the GRUB example, we just need to make sure we have a standard name for the standalone app load address).

Quoted 75 lines · On Thu, 8 Aug 2013 11:26:37 -0400 Tom Rini <[email protected]> wrote:

Quoted 9 lines · Dennis Gilmore

Quoted 6 lines · On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini <[email protected]> wrote:

Quoted 5 lines · Dennis Gilmore

Quoted 2 lines · On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini <[email protected]> wrote:

On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:

[snip]

Quoted 41 lines

Quoted 33 lines

Quoted 16 lines

Quoted 16 lines

Quoted 8 lines

kernel_addr_r
ramdisk_addr_r
pxefile_addr_r
scr_addr_r
uenv_addr_r

this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux

This is what I think we need to work towards. A board opting into this standard must set CONFIG_CMD_A/B/C (or maybe we add a CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the fallback files, whatever) and provide the following variables PLUS a, and this needs some thinking I think, auto-boot tries to load said file from ... ?

Quoted 8 lines

Quoted 3 lines

We cannot provide a built-in environment that works for every distro and case, we want the distro to tell us things it knows, and we'll tell it what it can't easily know.

we absolutely can, I would like for u-boot to load a dtb before doing anything. u-boot should know what devices can be booted from and likely an order of preference. i.e. removable media through to fixed, and finally pxe.

Looking at a couple of device trees, no, we can't. I don't see any useful information like "this is an SD controller" for example (and all of the mmc bindings that might provide a reliable clue are optional ones). So, at the high level, if U-Boot relied on DTs in every driver, we might be able to do what you're talking about. But we don't do that today, and probably won't for a long time, if ever.

Quoted 7 lines

But we will know what devices are likely to exist and be bootable, at build time. What we can do is try and load a file from everywhere we expect might be someplace with this file in it. We could even set some standard variables based on having found and loaded this file, so it can assume that everything else exists in this same place (or the file we have loaded knows better).

Quoted 3 lines

I was thinking more along the lines of us knowing what is likely to be there than pulling it from the DT and basically doing something like you mentioned here.

Right. For clarity, the problem is that DTs aren't useful like that. They describe the hardware, but in non-generic terms.

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

i would like for u-boot to first try to
load /boot/extlinux/extlinux.conf then /extlinux/extlinux.conf failing that try to load a /boot/uEnv.txt then /uEnv.txt and import that running with what is in it, then falling back to a /boot/boot.scr then /boot.scr then finally running dhcp, pxe get, and pxe boot.

Quoted 8 lines

Quoted 4 lines

I'd like to see most of that logic held in the file we load (so that when something replaces extlinux.conf as the preferred method, it just works still, or whatever) and run a command from. And fall back to dhcp+pxe for the install case.

where should the file we load come from? i would think when something comes along to replace extlinux.conf its likely going to need an updated u-boot to add some new functionality

Quoted 6 lines

I'd like to see the file come from the distro. And given that another option here is 'go'ing to a copy of GRUB, I think we've got at least a good chance of future expansion being handled OK with this method. We try and load something from the distro that is generic, and make the hand-off there. (In the GRUB example, we just need to make sure we have a standard name for the standalone app load address).

I really don't want to ship environment files. If we need to we need one of a few things. either u-boot needs to ship them and they are in a directory with a name matching the dtb, or we need to have a bunch of variables provided that enable us to load everything supported by the u-boot binaries.

We as distros have no business needing to deal with memory locations. it really is one of the biggest pain points with u-boot.

Quoted 3 lines · Stefano Babic

Hi Dennis,

On 01/08/2013 01:27, Robert Nelson wrote:

Quoted 8 lines

Quoted 8 lines

#define CONFIG_BOOTCOMMAND \
	"mmc dev ${mmcdev};" \
	"if mmc rescan; then " \
		"echo SD/MMC found on device ${mmcdev};" \
		"if run loadbootenv; then " \
			"run importbootenv;" \
		"fi;" \
		"if test -n $uenvcmd; then " \

Quoted 8 lines

Quoted 8 lines

			"echo Running uenvcmd ...;" \
			"run uenvcmd;" \
		"fi;" \
		"if run loadsomefailsafedefault; then " \
			"run mmcboot;" \
		"fi;" \
	"fi;"

#endif

That really works great on boards that don't have SD...

Quoted 10 lines

Quoted 2 lines

Right - the meaning of CONFIG_EXTRA_ENV_SETTINGS is to have a minimal default environment, allowing the user to extend it to a full blown adding whatever he wants. However, in the last times I see that the meaning is moving to *the environment*. There is something wrong, also because, as Robert says, each small change require to patch u-boot. But then, why do you need the environment at all ?

Quoted 2 lines

And the setup is then suitable for a strict range of applications, but not all.

You both are missing the point. This patch doesn't address the problem, but does highlight it. The distros want to get out of having to know the u-boot environment details for every single board and need some level of standardization across platforms. The distros should only have to specify "boot the kernel at path/name X on device Y." They should not need to know what address to load the kernel to, but only that $kernel_addr_r is already setup. Variables are the first step. The second step is standardizing the boot commands.