[U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank
From: Dennis Gilmore dennis@ausil.us
Signed-off-by: Dennis Gilmore dennis@ausil.us --- include/configs/wandboard.h | 42 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index ee6bf21..a5052c5 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -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" \ + "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" \ + "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" \ + "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 " \
On Thu, Jul 25, 2013 at 6:13 PM, dgilmore@fedoraproject.org wrote:
From: Dennis Gilmore dennis@ausil.us
highbank? what does this means?
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/wandboard.h | 42 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index ee6bf21..a5052c5 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -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
Please use a single empty line.
/* 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.
"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" \"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" \
This all is need? We could have a way to make this extendable and don't have it all duplicated.
"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@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
Dennis,
On Thu, Jul 25, 2013 at 4:13 PM, dgilmore@fedoraproject.org wrote:
From: Dennis Gilmore dennis@ausil.us
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/wandboard.h | 42 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index ee6bf21..a5052c5 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -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" \"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}}; syslinux_boot=echo Trying syslinux boot menu...; sysboot ${devtype} ${devnum} ${fs} ${script_addr} ${prefix}extlinux/extlinux.conf scan_disk=echo Scanning ${devtype} ${devnum}...; for fs in ${boot_fstypes}; do for mode in ${boot_modes}; do for prefix in ${boot_prefixes}; do run ${mode}_boot; done; done; done; boot_targets=scsi pxe boot_fstypes=ext2 boot_prefixes=/ /boot/ boot_scripts=boot.scr.uimg boot.scr boot_modes=syslinux env script kernel init_scsi=scsi scan; setenv devtype scsi bootcmd_scsi=run scan_disk init_pxe=setenv bootfile "" bootcmd_pxe=dhcp; pxe get; pxe boot boot_iter=for target in ${boot_targets}; do run init_${target} && run bootcmd_${target}; done bootcmd0=run boot_iter bootcmd1=setenv boot_targets pxe; run boot_iter bootcmd2=setenv boot_targets scsi; run boot_iter bootcmd15=run bootcmd_setup; run bootcmd_mmc localcmd=run bootcmd2 devnum=0:auto bootargs=console=ttyAMA0 root=LABEL=rootfs nosplash bootdelay=2 bootretry=90 bootstopkey=s bootdelaykey=d netretry=once fdt_addr=0x1000 fdt_high=0xffffffff pxefile_addr_r=0x700000 kernel_addr_r=0x800000 ramdisk_addr_r=0x01000000 script_addr=0x100000 initrd_high=0xffffffff
"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" \
These are pretty much highbank specific. The number is based on IPMI bootdev numbering.
Rob
On Wed, Jul 31, 2013 at 6:01 PM, Rob Herring robherring2@gmail.com wrote:
Dennis,
On Thu, Jul 25, 2013 at 4:13 PM, dgilmore@fedoraproject.org wrote:
From: Dennis Gilmore dennis@ausil.us
Signed-off-by: Dennis Gilmore dennis@ausil.us
include/configs/wandboard.h | 42 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h index ee6bf21..a5052c5 100644 --- a/include/configs/wandboard.h +++ b/include/configs/wandboard.h @@ -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" \"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}};
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
where:
"loadbootenv=load mmc ${mmcdev}:${mmcpart} ${loadaddr} uEnv.txt\0" \ "importbootenv=echo Importing environment from mmc (uEnv.txt)...; " \ "env import -t ${loadaddr} ${filesize}\0" \
Regards,
Hi Dennis,
On 01/08/2013 01:27, Robert Nelson wrote:
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
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
On Thu, 01 Aug 2013 10:53:49 +0200 Stefano Babic sbabic@denx.de wrote:
Hi Dennis,
On 01/08/2013 01:27, Robert Nelson wrote:
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. ;)
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.
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
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.
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
Hi Dennis,
On 01/08/2013 19:06, Dennis Gilmore 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.
Let's go away from the concrete scripts u-boot.scr and env.txt. What I find sick is that even the smallest change in a variable requires a new u-boot image, while the environment itself is thought from the beginning to be independent from the code.
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
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.
This is already an example where the dafult environment is perfectly suitable for someone but not for everybody. And of course, there are a wide range of storage device where scripts are stored: not all boards have MMC. I am thinking if we can have in the CONFIG_EXTRA_ENV_SETTINGS a general command to load the whole environment, letting the whole logic with scripts outside of the code.
Best regards, Stefano Babic
Dear Dennis,
In message 20130801120603.1683f7a6@adria.ausil.us 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.
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.
Best regards,
Wolfgang Denk
On Sun, Aug 04, 2013 at 10:00:04PM +0200, Wolfgang Denk wrote:
Dear Dennis,
In message 20130801120603.1683f7a6@adria.ausil.us 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.
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.
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."
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.
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,
In message 20130804202746.GH5164@bill-the-cat you wrote:
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.
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?
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.
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 ?
Best regards,
Wolfgang Denk
On Sun, Aug 04, 2013 at 11:03:53PM +0200, Wolfgang Denk wrote:
Dear Tom Rini,
In message 20130804202746.GH5164@bill-the-cat you wrote:
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.
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.
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?
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.
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.
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,
In message 20130804214743.GJ5164@bill-the-cat you wrote:
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. ...
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.
... I hadn't thought about saying part of the solution isthat 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.
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?
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.
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.
Of course, I agree here. But as I meantioned before, we should not try to solve all problems inside U-Boot only. The ARM kernel itself is still undergoing a lot of changes, and a number of issus could be solved in this environment, too. It's a real pity that distro makes appear to have much more influence there than any of the many embedded vendors.
Best regards,
Wolfgang Denk
On Mon, Aug 05, 2013 at 12:11:47AM +0200, Wolfgang Denk wrote:
Dear Tom,
In message 20130804214743.GJ5164@bill-the-cat you wrote:
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. ...
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.
But not long enough in some cases. But a good point for a general solution going forward.
... I hadn't thought about saying part of the solution isthat 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.
Right. This would be an agreement between us and the generic Linux distros that want in about what "sane" means, in terms of enabling users to get up and running. We want the advanced users to be able to drop in and do what they want to do in U-Boot but let the new users get to their comfort ground (generic linux distro) without going crazy either.
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?
It's debatable, yes. As part of this, I'd like to leave the door open so that for example the default experience is that whatever kernel the user chose as the main kernel gets booted via falcon mode (so quick boot) and on pressing c (or whatever) they get full U-Boot that would (in this case of a generic linux distro, find all that is required to) show up a menu for them to pick from (as they didn't interrupt the autoboot command that would do all of this).
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.
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.
On Mon, Aug 5, 2013 at 12:33 PM, Tom Rini trini@ti.com wrote:
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.
On Mon, Aug 05, 2013 at 01:29:20PM -0300, Otavio Salvador wrote:
On Mon, Aug 5, 2013 at 12:33 PM, Tom Rini trini@ti.com wrote:
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.
Well, all distros can do whatever is needed, it's about making what's needed as easy / low maintenance as possible.
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.
Exactly.
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.
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.
Right. And well documented enough so that product developers can tell what they do and don't need, and what might be helpful if they avail themselves of it.
Dear Tom,
In message 20130805190949.GS5164@bill-the-cat you wrote:
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.
"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.
Best regards,
Wolfgang Denk
On Mon, Aug 05, 2013 at 10:36:09PM +0200, Wolfgang Denk wrote:
Dear Tom,
In message 20130805190949.GS5164@bill-the-cat you wrote:
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.
"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.
Right. I need to look at Simon's patches again.
Resending unsigned
Hi Wolfgang,
On Sun, 04 Aug 2013 22:00:04 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Dennis,
In message 20130801120603.1683f7a6@adria.ausil.us 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.
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.
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."
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.
I didn't take out the features we do not want because I understand that not everyone wants things to be the same, that other ways to do things is perfectly valid.
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.
and those systems are free to continue as they do today. they are likely systems where a generic linux distro just wont run even if you really try.
Dennis
On 08/01/2013 03:53 AM, Stefano Babic wrote:
Hi Dennis,
On 01/08/2013 01:27, Robert Nelson wrote:
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
That really works great on boards that don't have SD...
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.
Rob
Hi Rob, Dennis,
On 01/08/2013 19:19, Rob Herring wrote:
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.
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 ?
Best regards, Stefano Babic
Dear Stefano,
In message 51FB786E.4010908@denx.de you wrote:
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 ?
There is a ton of options, all way better than hardcoding any such settings into the common default environment - "env import" allows to easily import variable settings in a number of formats (including plain text), so you can just dedicate some storage speace, either on a raw device (like an address / offset range in NOR / NAND flash, or some sectors on a block device, or a file in a file system, or whatever.
We never should extend the default environment into such a pile of stuff.
Best regards,
Wolfgang Denk
On Fri, Aug 02, 2013 at 11:14:22AM +0200, Stefano Babic wrote:
Hi Rob, Dennis,
On 01/08/2013 19:19, Rob Herring wrote:
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.
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 ?
Distros generally hate the thought of having the user update U-Boot. Part of why I asked Dennis to post his patches here is that we need to start the conversation at least, and come up with a way that boards are likely to ship out of the box in a way that can be worked from, consistently at least across different vendor same arch SoCs. This would require some opt-in per board, certainly.
On Fri, Aug 2, 2013 at 4:14 AM, Stefano Babic sbabic@denx.de wrote:
Hi Rob, Dennis,
On 01/08/2013 19:19, Rob Herring wrote:
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.
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 ?
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.
I would like to be able to simply say to enable distro support, add a config-distro.h to your board config, include a common set of environment commands to search boot devices for a kernel, and set a TBD list of env variables to board specific values. If there is a common set of files geared toward distro support, then it is easy for distros to submit patches against them and for board maintainers to know what the requirements are for distro support.
Rob
Dear Rob Herring,
In message CAL_JsqK++KbAajYtp9UnJuHWd=f8pjHSK0x3hzf73PCHdL_M6A@mail.gmail.com you wrote:
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.
Best regards,
Wolfgang Denk
On Mon, Aug 05, 2013 at 07:29:33AM +0200, Wolfgang Denk wrote:
Dear Rob Herring,
In message CAL_JsqK++KbAajYtp9UnJuHWd=f8pjHSK0x3hzf73PCHdL_M6A@mail.gmail.com you wrote:
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.
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,
In message 20130805160747.GP5164@bill-the-cat you wrote:
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.
Agreed, nbut that should be a very minimal set of setting that is common to most use cases.
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.
a controlable file is what started all of the boot.scr or uEnv.txt stuff.
Yes, I am aware of this.
Best regards,
Wolfgang Denk
On Mon, Aug 05, 2013 at 10:28:15PM +0200, Wolfgang Denk wrote:
Dear Tom,
In message 20130805160747.GP5164@bill-the-cat you wrote:
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.
Agreed, nbut that should be a very minimal set of setting that is common to most use cases.
I wouldn't say minimal, I would say not complicated. Your TV (since we've had someone in #u-boot in recent days getting help putting custom u-boot on their TV) isn't going to ship with all of this enabled / tested, but your community board / evm / similar can because it's broadly aimed.
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.
Well, my hope is that we can agree that so long as certain variables are set within certain bounds, and certain commands (and other settings if needed) are set, it will boil down to if load_distro_env; then env import -t $distro_env run load_distro fi
Much like how uEnv.txt / uenvcmd work. The complex bits need to be in the not built-in override part.
On Mon, Aug 5, 2013 at 12:29 AM, Wolfgang Denk wd@denx.de wrote:
Dear Rob Herring,
In message CAL_JsqK++KbAajYtp9UnJuHWd=f8pjHSK0x3hzf73PCHdL_M6A@mail.gmail.com you wrote:
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.
You may want to have factory default and "user" settings. Building in the factory settings would be one way to accomplish that.
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.
Rob
Dear Rob Herring,
In message CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com you wrote:
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.
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).
Best regards,
Wolfgang Denk
On 08/06/2013 05:37 AM, Wolfgang Denk wrote:
Dear Rob Herring,
In message CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com you wrote:
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.
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.
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.
On Tue, Aug 6, 2013 at 12:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/06/2013 05:37 AM, Wolfgang Denk wrote:
Dear Rob Herring,
In message CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com you wrote:
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.
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.
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
On 08/06/2013 10:18 AM, Otavio Salvador wrote:
On Tue, Aug 6, 2013 at 12:50 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/06/2013 05:37 AM, Wolfgang Denk wrote:
Dear Rob Herring,
In message CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com you wrote:
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.
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.
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?
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.
I am interested in let my customers to revert back to a sane default running:
env -f -d -a saveenv
On Tue, Aug 6, 2013 at 1:54 PM, Stephen Warren swarren@wwwdotorg.org wrote:
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.
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?
On 08/06/2013 10:58 AM, Otavio Salvador wrote:
On Tue, Aug 6, 2013 at 1:54 PM, Stephen Warren swarren@wwwdotorg.org wrote:
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.
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?
On Tue, Aug 6, 2013 at 2:12 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/06/2013 10:58 AM, Otavio Salvador wrote:
On Tue, Aug 6, 2013 at 1:54 PM, Stephen Warren swarren@wwwdotorg.org wrote:
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.
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?
So that's the real goal to change it inside of code. This does make sense to have a way to set it from outside.
On Tue, Aug 06, 2013 at 01:58:22PM -0300, Otavio Salvador wrote:
On Tue, Aug 6, 2013 at 1:54 PM, Stephen Warren swarren@wwwdotorg.org wrote:
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.
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.
On Tue, Aug 6, 2013 at 6:37 PM, Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 01:58:22PM -0300, Otavio Salvador wrote:
On Tue, Aug 6, 2013 at 1:54 PM, Stephen Warren swarren@wwwdotorg.org wrote:
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.
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.
On Tue, Aug 6, 2013 at 6:37 PM, Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 01:58:22PM -0300, Otavio Salvador wrote:
On Tue, Aug 6, 2013 at 1:54 PM, Stephen Warren swarren@wwwdotorg.org wrote:
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.
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.
and a way to do it from build host (OE, for example) without from runtime.
On Tue, 06 Aug 2013 13:37:51 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Rob Herring,
In message CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@mail.gmail.com you wrote:
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.
How exactly should it be handled outside of the compiled u-boot image. with my distro hat on, I honesty do not want to deal with u-boot at all. The limit of my dealing with u-boot will be to run a script that installs the u-boot binary onto disk for those systems that don't have it in nand/nor/spi etc flash storage.
In my mind you are talking about some file I need to write to disk that gets loaded at boot time. the problem with this is its not flexible nor portable. I honestly think one of the worst thing hardware vendors ever did was to ship hardware that doesn't have anywhere built into it to load and run u-boot from.
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.
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).
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.
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
Dennis
On Tue, Aug 6, 2013 at 1:22 PM, Dennis Gilmore dennis@ausil.us wrote: ...
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.
U-Boot is the hardest part of whole chain to make it cross SoC (and cross Vendor SoC is even harder) as it needs to set pins and registers which vary from one to another. So even using DeviceTree there I am not aware of a way to make it to work for i.MX6 and Allwinner SoCs without using different binaries. You can certainly share the binary among different boards of same SoC (or SoC family) but across them I am not aware of it being possible.
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).
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.
What Wolfgang is saying here is it will still be a single file but made in two steps. One U-Boot binary, another cluing the environment to it. ...
Regards,
On 08/06/2013 10:22 AM, Dennis Gilmore wrote: ...
some variables that would need to be compiled in
fdt_addr fdt_addr_r kernel_addr_r ramdisk_addr_r
Those all look standard, and are documented in U-Boot's README.
pxefile_addr_r scr_addr_r uenv_addr_r
But none of those are, the first only appears in one config file in the U-Boot source tree, and the second two not at all.
I assume scr_addr_r is where boot.scr/... should be loaded? Some config files appear to use script_addr/script_addr2/scriptaddr for that.
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
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
Why two?
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.
On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
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
Why two?
from cmd_pxe.c /* * fdt usage is optional: * It handles the following scenarios. All scenarios are exclusive * * Scenario 1: If fdt_addr_r specified and "fdt" label is defined in * pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm, * and adjust argc appropriately. * * Scenario 2: If there is an fdt_addr specified, pass it along to * bootm, and adjust argc appropriately. * * Scenario 3: fdt blob is not available. */
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
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.
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.
its then up to the distro to provide one of the 3 configs to boot. or the system falls back to pxe and a network boot/install is done.
Dennis
On Tue, Aug 06, 2013 at 06:11:25PM -0500, Dennis Gilmore wrote:
On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
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
Why two?
from cmd_pxe.c
[snip]
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.
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.
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).
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.
On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 06:11:25PM -0500, Dennis Gilmore wrote:
On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
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
Why two?
from cmd_pxe.c
[snip]
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.
right, how that gets there would be up to the vendor. but distros should put dtbs in a known place so that they can pulled from there.
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.
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).
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.
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.
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
Dennis
On Wed, Aug 07, 2013 at 06:04:23PM -0500, Dennis Gilmore wrote:
On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 06:11:25PM -0500, Dennis Gilmore wrote:
On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
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.
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).
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.
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.
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).
On Thu, 8 Aug 2013 11:26:37 -0400 Tom Rini trini@ti.com wrote:
On Wed, Aug 07, 2013 at 06:04:23PM -0500, Dennis Gilmore wrote:
On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 06:11:25PM -0500, Dennis Gilmore wrote:
On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
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.
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).
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.
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.
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).
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.
Dennis
On Sat, Aug 10, 2013 at 03:50:45PM -0500, Dennis Gilmore wrote:
On Thu, 8 Aug 2013 11:26:37 -0400 Tom Rini trini@ti.com wrote:
On Wed, Aug 07, 2013 at 06:04:23PM -0500, Dennis Gilmore wrote:
On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 06:11:25PM -0500, Dennis Gilmore wrote:
On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
> 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.
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).
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.
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.
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).
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.
Don't think of them as environment files then. Think of them like the glue you need to spit out on x86 to get your stuff loaded, like with any other loader. And yes, I agree, we'll provide consistent variables that you can rely on, well, like we do today for the whole PXE menu thing to work. But you're putting more of a constraint on U-Boot than you do on x86 (unless you're going to make everyone boot directly from uefi shells, rather than gummiboot moving forward :)) so you'll need to provide a bit more, to future-proof things.
On Thu, Aug 01, 2013 at 12:19:13PM -0500, Rob Herring wrote:
On 08/01/2013 03:53 AM, Stefano Babic wrote:
Hi Dennis,
On 01/08/2013 01:27, Robert Nelson wrote:
[snip]
#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
That really works great on boards that don't have SD...
Don't lose the forest for the trees. A "try and import stuff from easy/prominent storage" is true for most boards, be it SD or SATA or NAND or ...
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.
At the high level, right. But I think we need to know what the distros need / what, and come up with an opt-in setup that works for both parts (if a board follows the rules, it should easily work with whatever distros provide feedback, if it doesn't then it might not, and boards that care can opt-in and those that won't, can stay out).
participants (9)
-
Dennis Gilmore -
dgilmore＠fedoraproject.org -
Otavio Salvador -
Rob Herring -
Robert Nelson -
Stefano Babic -
Stephen Warren -
Tom Rini -
Wolfgang Denk