diff mbox

[U-Boot] wandboard: add pxe support, set default boot command like highbank

Message ID 1374786812-32303-1-git-send-email-dgilmore@fedoraproject.org
State Rejected
Delegated to: Stefano Babic
Headers show

Commit Message

Dennis Gilmore July 25, 2013, 9:13 p.m. UTC 
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(-)

Comments

Otavio Salvador July 26, 2013, 1:52 p.m. UTC | #1 
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
Otavio Salvador July 29, 2013, 6:47 p.m. UTC | #2 
On Fri, Jul 26, 2013 at 9:20 PM, Dennis Gilmore
<dgilmore@fedoraproject.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, 26 Jul 2013 10:52:04 -0300
> Otavio Salvador <otavio@ossystems.com.br> wrote:
>
>> On Thu, Jul 25, 2013 at 6:13 PM,  <dgilmore@fedoraproject.org> wrote:
>> > From: Dennis Gilmore <dennis@ausil.us>
>>
>> highbank? what does this means?
> calxeda highbank. the overall goal of this patch set is to simplify
> things for distros to support the wandboard

So this should be explained in commit log. I didn't know what Calxeda
Highbank was until I searched Google but this is not important to be
in commit log but it is important to be explained the goal of patch
and why.

>> > 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.
> the cmd_pxe.c code requires the _r versions

So rework the other variables and avoid duplicating those.

>> >         "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.
>
> it provides a simple way to setup different boot orders.

I understand what it does but it can be simplified using a single
bootcmd_base or so and this to use an extra var to choose
bootcmd_<foo>.

The 0, 1, 2 and 15 suffix are due any reason?

>> > +       "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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAlHzEkIACgkQkSxm47BaWffDUACfcM4dsdVWpTNaCgOqgKlJeQ5w
> tIsAoJaLesZhxQ1kBZQrpR45uriHiWzD
> =l+Dc
> -----END PGP SIGNATURE-----



--
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
Rob Herring July 31, 2013, 11:01 p.m. UTC | #3 
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
Robert Nelson July 31, 2013, 11:27 p.m. UTC | #4 
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,
Stefano Babic Aug. 1, 2013, 8:53 a.m. UTC | #5 
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
Dennis Gilmore Aug. 1, 2013, 5:06 p.m. UTC | #6 
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
> 
>
Rob Herring Aug. 1, 2013, 5:19 p.m. UTC | #7 
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
Stefano Babic Aug. 2, 2013, 9:14 a.m. UTC | #8 
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
Stefano Babic Aug. 2, 2013, 9:25 a.m. UTC | #9 
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
Wolfgang Denk Aug. 4, 2013, 7:53 p.m. UTC | #10 
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
Wolfgang Denk Aug. 4, 2013, 8 p.m. UTC | #11 
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
Tom Rini Aug. 4, 2013, 8:14 p.m. UTC | #12 
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.
Tom Rini Aug. 4, 2013, 8:27 p.m. UTC | #13 
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.
Tom Rini Aug. 4, 2013, 8:32 p.m. UTC | #14 
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).
Wolfgang Denk Aug. 4, 2013, 9:03 p.m. UTC | #15 
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
Tom Rini Aug. 4, 2013, 9:47 p.m. UTC | #16 
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.
Wolfgang Denk Aug. 4, 2013, 10:11 p.m. UTC | #17 
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 is
> that distros should provide an environment file to import (and if
> applicable, saveenv'ing after).  But what I mean is that we have a half
> dozen (it feels like) semi-flexible environments different boards/socs
> compile in, and it's not easy to share those.  One of the requests is a
> "sane" default boot command, and we do have a number of boards out there
> without a savable environment.

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

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

> > 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
Wolfgang Denk Aug. 4, 2013, 10:26 p.m. UTC | #18 
Dear Dennis,

In message <20130804163442.31dca315@adria.ausil.us> 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.
> It should be possible for those systems that want a generic linux
> distro to run on them. ...

Agreed.  But then, all you need is a root file system image
(eventually just exported from a NFS server), and a Linux kernel
image plus a DT blob (ideally combined into a FIT image).  Put the FIT
image on a TFTP server, and use DHCP, and you're up and running in a
few minutes.

Netbooting is even older than Linux...

>                    ... 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.

Sorry, I can't parse that.  The Wandboard has SDcard support.  Where
exactly is your problem?  You can put all files on a SDcard image, or
copy them into a file system on SDcard.

> > 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.

Sorry, but I cannot answer your question.  You only state what you
want to do, and in an already predetermined manner (use pxe, use
extlinux.conf, ...).  I have no idea what "the same thing" actually
is.  You never defined it.

I may be naive, but for me booting Linux on a system only requires a
kernel image (with DTB, say as a FIT image) and a root file system.
If you need to do fancy stuff, we have all kinds of ways to run
commands or define environment settings.  For example, you could add
environment settings (to be activated using "env import") as one part
of a FIT image, and all kinds of scripts as another part.  Then no
changes are needed at all to the U-Boot code, you have it all under
your own control, and all necessary information is included in a
single file (the FIT image), so booting over the network works the
same as booting from a real disk drive.

Best regards,

Wolfgang Denk
Dennis Gilmore Aug. 4, 2013, 11:06 p.m. UTC | #19 
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
Rob Herring Aug. 5, 2013, 2:21 a.m. UTC | #20 
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
Wolfgang Denk Aug. 5, 2013, 5:29 a.m. UTC | #21 
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
Tom Rini Aug. 5, 2013, 3:33 p.m. UTC | #22 
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 is
> > that distros should provide an environment file to import (and if
> > applicable, saveenv'ing after).  But what I mean is that we have a half
> > dozen (it feels like) semi-flexible environments different boards/socs
> > compile in, and it's not easy to share those.  One of the requests is a
> > "sane" default boot command, and we do have a number of boards out there
> > without a savable environment.
> 
> Requests for a "sane" environment are comprehensible.  However, it
> will be difficult to reach an agreement what exactly "sane" means
> here.  For example, I have never been able to get accustomed to all
> the uEnv.txt, user.txt etc. scripts used with a number of boards; for
> me, all this seems way too complicated and inflexible, and I always
> try to get rid of this stuff.  I'm aware that other people like the
> approach.  OK - I see no problems with that: TIMTOWTDI.
> 
> I would only have a problem (and a serious one) if such an approach
> became standard, or even mandatory.  Not to mention a large number of
> projects I know of.

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.
Tom Rini Aug. 5, 2013, 4:07 p.m. UTC | #23 
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.
Otavio Salvador Aug. 5, 2013, 4:29 p.m. UTC | #24 
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.
Tom Rini Aug. 5, 2013, 7:09 p.m. UTC | #25 
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.
Wolfgang Denk Aug. 5, 2013, 8:28 p.m. UTC | #26 
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
Wolfgang Denk Aug. 5, 2013, 8:36 p.m. UTC | #27 
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
Tom Rini Aug. 5, 2013, 8:42 p.m. UTC | #28 
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.
Tom Rini Aug. 5, 2013, 8:44 p.m. UTC | #29 
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.
Rob Herring Aug. 5, 2013, 10:16 p.m. UTC | #30 
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
Wolfgang Denk Aug. 6, 2013, 11:37 a.m. UTC | #31 
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
Stephen Warren Aug. 6, 2013, 3:50 p.m. UTC | #32 
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.
Otavio Salvador Aug. 6, 2013, 4:18 p.m. UTC | #33 
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
Dennis Gilmore Aug. 6, 2013, 4:22 p.m. UTC | #34 
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
Otavio Salvador Aug. 6, 2013, 4:29 p.m. UTC | #35 
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,
Stephen Warren Aug. 6, 2013, 4:54 p.m. UTC | #36 
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
Otavio Salvador Aug. 6, 2013, 4:58 p.m. UTC | #37 
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?
Stephen Warren Aug. 6, 2013, 5:12 p.m. UTC | #38 
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?
Otavio Salvador Aug. 6, 2013, 5:17 p.m. UTC | #39 
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.
Stephen Warren Aug. 6, 2013, 8:05 p.m. UTC | #40 
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.
Tom Rini Aug. 6, 2013, 9:37 p.m. UTC | #41 
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.
Tom Rini Aug. 6, 2013, 9:42 p.m. UTC | #42 
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.
Otavio Salvador Aug. 6, 2013, 9:44 p.m. UTC | #43 
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.
Otavio Salvador Aug. 6, 2013, 9:45 p.m. UTC | #44 
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.
Dennis Gilmore Aug. 6, 2013, 11:11 p.m. UTC | #45 
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
Tom Rini Aug. 7, 2013, 1:19 p.m. UTC | #46 
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.
Dennis Gilmore Aug. 7, 2013, 11:04 p.m. UTC | #47 
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
Tom Rini Aug. 8, 2013, 3:26 p.m. UTC | #48 
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).
Dennis Gilmore Aug. 10, 2013, 8:50 p.m. UTC | #49 
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
Tom Rini Aug. 12, 2013, 1:49 p.m. UTC | #50 
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.
diff mbox

Patch

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 " \