[U-Boot] RFC unified boot environment

[U-Boot] RFC unified boot environment

[Dennis Gilmore]

Hi All,

The attached patches build on the work for generic distro config, as well as
Stephen Warrens implementation for tegra.

I have added a header to be included that will allow all boards to boot in the
same way and I have ported over two boards to use it. One thought I have had
is to move the environment into the same header as the generic config. 

I am also working on writing a README.distro file to document everything that
needs to be set for everything to just work. Along with information on how to
best choose memory locations. 

Dennis

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dennis Gilmore]

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 172 insertions(+)
 create mode 100644 include/config_distro_bootcmd.h

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
new file mode 100644
index 0000000..d32dc12
--- /dev/null
+++ b/include/config_distro_bootcmd.h
@@ -0,0 +1,172 @@
+/*
+ * (C) Copyright 2014
+ * NVIDIA Corporation <www.nvidia.com>
+ *  
+ * Copyright 2014 Red Hat, Inc.
+ *
+ * SPDX-License-Identifier:     GPL-2.0+
+ */
+
+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
+#define _CONFIG_CMD_DISTRO_BOOTCMD_H
+
+
+#ifdef CONFIG_CMD_MMC
+#define BOOTCMDS_MMC \
+	"mmc_boot=" \
+		"setenv devtype mmc; " \
+		"if mmc dev ${devnum}; then " \
+			"run scan_boot; " \
+		"fi\0" \
+	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
+	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
+#define BOOT_TARGETS_MMC "mmc1 mmc0"
+#else
+#define BOOTCMDS_MMC ""
+#define BOOT_TARGETS_MMC ""
+#endif
+
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB "run usb_init; "
+#define BOOTCMDS_USB \
+	"usb_init=" \
+		"if ${usb_need_init}; then " \
+			"set usb_need_init false; " \
+			"usb start 0; " \
+		"fi\0" \
+	\
+	"usb_boot=" \
+		"setenv devtype usb; " \
+		BOOTCMD_INIT_USB \
+		"if usb dev ${devnum}; then " \
+			"run scan_boot; " \
+		"fi\0" \
+	\
+	"bootcmd_usb0=setenv devnum 0; run usb_boot;\0"
+#define BOOT_TARGETS_USB "usb0"
+#else
+#define BOOTCMD_INIT_USB ""
+#define BOOTCMDS_USB ""
+#define BOOT_TARGETS_USB ""
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define BOOTCMDS_SATA \
+	"sata_boot=" \
+		"setenv devtype sata; " \
+		"if sata dev ${devnum}; then " \
+			"run scan_boot; " \
+		"fi\0" \
+	\
+	"bootcmd_sata0=setenv devnum 0; run sata_boot;\0"
+	"bootcmd_sata1=setenv devnum 1; run sata_boot;\0"
+#define BOOT_TARGETS_USB "sata0 sata1"
+#else
+#define BOOTCMDS_SATA ""
+#define BOOT_TARGETS_SATA ""
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define BOOTCMDS_DHCP \
+	"bootcmd_dhcp=" \
+		BOOTCMD_INIT_USB \
+		"if dhcp ${scriptaddr} boot.scr.uimg; then "\
+			"source ${scriptaddr}; " \
+		"fi\0"
+#define BOOT_TARGETS_DHCP "dhcp"
+#else
+#define BOOTCMDS_DHCP ""
+#define BOOT_TARGETS_DHCP ""
+#endif
+
+#if defined(CONFIG_CMD_DHCP) && defined(CONFIG_CMD_PXE)
+#define BOOTCMDS_PXE \
+	"bootcmd_pxe=" \
+		BOOTCMD_INIT_USB \
+		"dhcp; " \
+		"if pxe get; then " \
+			"pxe boot; " \
+		"fi\0"
+#define BOOT_TARGETS_PXE "pxe"
+#else
+#define BOOTCMDS_PXE ""
+#define BOOT_TARGETS_PXE ""
+#endif
+
+#define BOOTCMDS_COMMON \
+	"rootpart=1\0" \
+	\
+	"do_envimport="                                                   \
+		"load ${devtype} ${devnum}:${rootpart} ${loadaddr} "      \
+			"${environment}\0"                                \
+		"env import -t ${loadaddr} $filesize\0"                   \
+	\
+	"envimport="                                                      \
+		"for environment in ${boot_envs}; do "                    \
+			"if test -e ${devtype} ${devnum}:${rootpart} "    \
+					"${prefix}${environment}; then "  \
+				"echo Found U-Boot environment "          \
+					"${prefix}${environment}; "       \
+				"run do_envimport;"                       \
+				"echo Import FAILED; continuing...; "     \
+			"fi; "                                            \
+		"done\0"                                                  \
+	\
+	"do_script_boot="                                                 \
+		"load ${devtype} ${devnum}:${rootpart} "                  \
+			"${scriptaddr} ${prefix}${script}; "              \
+		"source ${scriptaddr}\0"                                  \
+	\
+	"script_boot="                                                    \
+		"for script in ${boot_scripts}; do "                      \
+			"if test -e ${devtype} ${devnum}:${rootpart} "    \
+					"${prefix}${script}; then "       \
+				"echo Found U-Boot script "               \
+					"${prefix}${script}; "            \
+				"run do_script_boot;"                     \
+				"echo SCRIPT FAILED; continuing...; "     \
+			"fi; "                                            \
+		"done\0"                                                  \
+	\
+	"do_sysboot_boot="                                                \
+		"sysboot ${devtype} ${devnum}:${rootpart} any "           \
+			"${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \
+	\
+	"sysboot_boot="                                                   \
+		"if test -e ${devtype} ${devnum}:${rootpart} "            \
+				"${prefix}extlinux/extlinux.conf; then "  \
+			"echo Found extlinux config "                     \
+				"${prefix}extlinux/extlinux.conf; "       \
+			"run do_sysboot_boot;"                            \
+			"echo SYSBOOT FAILED; continuing...; "            \
+		"fi\0"                                                    \
+	\
+	"scan_boot="                                                      \
+		"echo Scanning ${devtype} ${devnum}...; "                 \
+		"for prefix in ${boot_prefixes}; do "                     \
+			"run sysboot_boot; "                              \
+			"run envimport; "                                 \
+			"run script_boot; "                               \
+		"done\0"                                                  \
+	\
+	"boot_targets=" \
+		BOOT_TARGETS_MMC " "  \
+		BOOT_TARGETS_USB " "  \
+		BOOT_TARGETS_SATA " " \
+		BOOT_TARGETS_PXE " "  \
+		BOOT_TARGETS_DHCP " " \
+		"\0" \
+	\
+	"boot_prefixes=/ /boot/\0" \
+	\
+	"boot_scripts=boot.scr.uimg boot.scr\0" \
+	\
+	"boot_envs=uEnv.txt\0" \
+	\
+	BOOTCMDS_MMC \
+	BOOTCMDS_USB \
+	BOOTCMDS_SATA \
+	BOOTCMDS_DHCP \
+	BOOTCMDS_PXE
+
+#endif  /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
-- 
1.8.5.3

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Mon, Feb 17, 2014 at 11:56:36AM -0600, Dennis Gilmore wrote:

> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
[snip]
> +		"if ${usb_need_init}; then " \
> +			"set usb_need_init false; " \
> +			"usb start 0; " \

Checking common/cmd_usb.c, 'start' doesn't take arguments.

> +#ifdef CONFIG_CMD_SATA
> +#define BOOTCMDS_SATA \
> +	"sata_boot=" \
> +		"setenv devtype sata; " \
> +		"if sata dev ${devnum}; then " \
> +			"run scan_boot; " \
> +		"fi\0" \
> +	\
> +	"bootcmd_sata0=setenv devnum 0; run sata_boot;\0"
> +	"bootcmd_sata1=setenv devnum 1; run sata_boot;\0"
> +#define BOOT_TARGETS_USB "sata0 sata1"

Typo, s/USB/SATA/

> +#ifdef CONFIG_CMD_DHCP
> +#define BOOTCMDS_DHCP \
> +	"bootcmd_dhcp=" \
> +		BOOTCMD_INIT_USB \

Why BOOTCMD_INIT_USB here?  For USB based networking?  If so, add some
comments please.

> +		"if dhcp ${scriptaddr} boot.scr.uimg; then "\
> +			"source ${scriptaddr}; " \
> +		"fi\0"

This relies on autoload being true, so we should set that.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/94d8d906/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dennis Gilmore]

On Wed, 19 Feb 2014 08:42:57 -0500
Tom Rini <trini@ti.com> wrote:

> On Mon, Feb 17, 2014 at 11:56:36AM -0600, Dennis Gilmore wrote:
> 
> > Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> [snip]
> > +		"if ${usb_need_init}; then " \
> > +			"set usb_need_init false; " \
> > +			"usb start 0; " \
> 
> Checking common/cmd_usb.c, 'start' doesn't take arguments.

Copied from tegra-common-post.h as is, will fix it up

> > +#ifdef CONFIG_CMD_SATA
> > +#define BOOTCMDS_SATA \
> > +	"sata_boot=" \
> > +		"setenv devtype sata; " \
> > +		"if sata dev ${devnum}; then " \
> > +			"run scan_boot; " \
> > +		"fi\0" \
> > +	\
> > +	"bootcmd_sata0=setenv devnum 0; run sata_boot;\0"
> > +	"bootcmd_sata1=setenv devnum 1; run sata_boot;\0"
> > +#define BOOT_TARGETS_USB "sata0 sata1"
> 
> Typo, s/USB/SATA/

will fix

> > +#ifdef CONFIG_CMD_DHCP
> > +#define BOOTCMDS_DHCP \
> > +	"bootcmd_dhcp=" \
> > +		BOOTCMD_INIT_USB \
> 
> Why BOOTCMD_INIT_USB here?  For USB based networking?  If so, add some
> comments please.
It was Copied from tegra-common-post.h im assuming that it to support
booting from a usb attached nic

> > +		"if dhcp ${scriptaddr} boot.scr.uimg; then "\
> > +			"source ${scriptaddr}; " \
> > +		"fi\0"
> 
> This relies on autoload being true, so we should set that.
okay, will fix it up.

Thanks

Dennis

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Marek Vasut]

On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote:
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
>  include/config_distro_bootcmd.h | 172
> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+)
>  create mode 100644 include/config_distro_bootcmd.h
> 
> diff --git a/include/config_distro_bootcmd.h
> b/include/config_distro_bootcmd.h new file mode 100644
> index 0000000..d32dc12
> --- /dev/null
> +++ b/include/config_distro_bootcmd.h
> @@ -0,0 +1,172 @@
> +/*
> + * (C) Copyright 2014
> + * NVIDIA Corporation <www.nvidia.com>
> + *
> + * Copyright 2014 Red Hat, Inc.
> + *
> + * SPDX-License-Identifier:     GPL-2.0+
> + */
> +
> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> +
> +
> +#ifdef CONFIG_CMD_MMC
> +#define BOOTCMDS_MMC \

You might want to #undef all this temporary stuff so it's not propagated into 
the U-Boot further.

Best regards,
Marek Vasut

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 08:54 AM, Marek Vasut wrote:
> On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote:
>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>> ---
>>  include/config_distro_bootcmd.h | 172
>> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172 insertions(+)
>>  create mode 100644 include/config_distro_bootcmd.h
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h new file mode 100644
>> index 0000000..d32dc12
>> --- /dev/null
>> +++ b/include/config_distro_bootcmd.h
>> @@ -0,0 +1,172 @@
>> +/*
>> + * (C) Copyright 2014
>> + * NVIDIA Corporation <www.nvidia.com>
>> + *
>> + * Copyright 2014 Red Hat, Inc.
>> + *
>> + * SPDX-License-Identifier:     GPL-2.0+
>> + */
>> +
>> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
>> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
>> +
>> +
>> +#ifdef CONFIG_CMD_MMC
>> +#define BOOTCMDS_MMC \
> 
> You might want to #undef all this temporary stuff so it's not propagated into 
> the U-Boot further.

I don't understand. What temporary stuff are you referring to?

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Marek Vasut]

On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote:
> On 02/19/2014 08:54 AM, Marek Vasut wrote:
> > On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote:
> >> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> >> ---
> >> 
> >>  include/config_distro_bootcmd.h | 172
> >> 
> >> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172
> >> insertions(+)
> >> 
> >>  create mode 100644 include/config_distro_bootcmd.h
> >> 
> >> diff --git a/include/config_distro_bootcmd.h
> >> b/include/config_distro_bootcmd.h new file mode 100644
> >> index 0000000..d32dc12
> >> --- /dev/null
> >> +++ b/include/config_distro_bootcmd.h
> >> @@ -0,0 +1,172 @@
> >> +/*
> >> + * (C) Copyright 2014
> >> + * NVIDIA Corporation <www.nvidia.com>
> >> + *
> >> + * Copyright 2014 Red Hat, Inc.
> >> + *
> >> + * SPDX-License-Identifier:     GPL-2.0+
> >> + */
> >> +
> >> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> >> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> >> +
> >> +
> >> +#ifdef CONFIG_CMD_MMC
> >> +#define BOOTCMDS_MMC \
> > 
> > You might want to #undef all this temporary stuff so it's not propagated
> > into the U-Boot further.
> 
> I don't understand. What temporary stuff are you referring to?

BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest 
of the U-Boot build, does it ?

Best regards,
Marek Vasut

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 10:30 AM, Marek Vasut wrote:
> On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote:
>> On 02/19/2014 08:54 AM, Marek Vasut wrote:
>>> On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote:
>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>> ---
>>>>
>>>>  include/config_distro_bootcmd.h | 172
>>>>
>>>> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172
>>>> insertions(+)
>>>>
>>>>  create mode 100644 include/config_distro_bootcmd.h
>>>>
>>>> diff --git a/include/config_distro_bootcmd.h
>>>> b/include/config_distro_bootcmd.h new file mode 100644
>>>> index 0000000..d32dc12
>>>> --- /dev/null
>>>> +++ b/include/config_distro_bootcmd.h
>>>> @@ -0,0 +1,172 @@
>>>> +/*
>>>> + * (C) Copyright 2014
>>>> + * NVIDIA Corporation <www.nvidia.com>
>>>> + *
>>>> + * Copyright 2014 Red Hat, Inc.
>>>> + *
>>>> + * SPDX-License-Identifier:     GPL-2.0+
>>>> + */
>>>> +
>>>> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
>>>> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
>>>> +
>>>> +
>>>> +#ifdef CONFIG_CMD_MMC
>>>> +#define BOOTCMDS_MMC \
>>>
>>> You might want to #undef all this temporary stuff so it's not propagated
>>> into the U-Boot further.
>>
>> I don't understand. What temporary stuff are you referring to?
> 
> BOOTCMDS_MMC for example. This certainly doesn't need to propagate into the rest 
> of the U-Boot build, does it ?

Oh, you mean #undef it at the end of the file? That would probably work.
I thought you meant something else, although I wasn't sure what.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Marek Vasut]

On Wednesday, February 19, 2014 at 06:41:17 PM, Stephen Warren wrote:
> On 02/19/2014 10:30 AM, Marek Vasut wrote:
> > On Wednesday, February 19, 2014 at 06:28:39 PM, Stephen Warren wrote:
> >> On 02/19/2014 08:54 AM, Marek Vasut wrote:
> >>> On Monday, February 17, 2014 at 06:56:36 PM, Dennis Gilmore wrote:
> >>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> >>>> ---
> >>>> 
> >>>>  include/config_distro_bootcmd.h | 172
> >>>> 
> >>>> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 172
> >>>> insertions(+)
> >>>> 
> >>>>  create mode 100644 include/config_distro_bootcmd.h
> >>>> 
> >>>> diff --git a/include/config_distro_bootcmd.h
> >>>> b/include/config_distro_bootcmd.h new file mode 100644
> >>>> index 0000000..d32dc12
> >>>> --- /dev/null
> >>>> +++ b/include/config_distro_bootcmd.h
> >>>> @@ -0,0 +1,172 @@
> >>>> +/*
> >>>> + * (C) Copyright 2014
> >>>> + * NVIDIA Corporation <www.nvidia.com>
> >>>> + *
> >>>> + * Copyright 2014 Red Hat, Inc.
> >>>> + *
> >>>> + * SPDX-License-Identifier:     GPL-2.0+
> >>>> + */
> >>>> +
> >>>> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> >>>> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> >>>> +
> >>>> +
> >>>> +#ifdef CONFIG_CMD_MMC
> >>>> +#define BOOTCMDS_MMC \
> >>> 
> >>> You might want to #undef all this temporary stuff so it's not
> >>> propagated into the U-Boot further.
> >> 
> >> I don't understand. What temporary stuff are you referring to?
> > 
> > BOOTCMDS_MMC for example. This certainly doesn't need to propagate into
> > the rest of the U-Boot build, does it ?
> 
> Oh, you mean #undef it at the end of the file? That would probably work.
> I thought you meant something else, although I wasn't sure what.

That's what I meant, sorry.

Best regards,
Marek Vasut

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>

Patch description?

> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h

> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> +
> +

Is there a need for 2 blank lines there?

> +#define BOOTCMDS_COMMON \
> +	"rootpart=1\0" \

We should really stop hard-coding that. I meant to (but evidently never
got around to) re-write the commands so that they could automatically
determine which partition to use, based on the MBR bootable flag or GPT
partition flags.

Still, we can probably make that enhancement separately later.

> +#define BOOT_TARGETS_MMC "mmc1 mmc0"

We really ought to make the order of multiple MMC devices in
BOOT_TARGETS configurable. For example, we may have 2 boards that both
want to boot from SD card if present, else fall back to internal eMMC,
yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On
Tegra, we're just lucky that hasn't been an issue yet. Equally, not all
boards have 2 eMMC devices.

> +	"scan_boot="                                                      \
> +		"echo Scanning ${devtype} ${devnum}...; "                 \
> +		"for prefix in ${boot_prefixes}; do "                     \
> +			"run sysboot_boot; "                              \
> +			"run envimport; "                                 \
> +			"run script_boot; "                               \

This isn't quite right for the Raspberry Pi at least.

What I wanted was for uEnv.txt to *always* be loaded from SD card before
any other boot activity. The SD card is known to exist on this platform,
since it's the only place the SoC's boot ROM can load the initial binary
firmware from.

The idea is that since the Pi has nowhere to store any environment, and
the default environment's boot_targets is hard-coded in the U-Boot
binary, we need some way for the user to configure the value of
boot_targets to e.g. force network or USB boot. We want to do this
before executing bootcmd, so that bootcmd looks at the user's desired
boot_targets, rather than part way through executing bootcmd, which is
far too late.

Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still
work even with the "run envimport" as above. However, I think we want to
make the "run envimport" within scan_boot optional, so it doesn't get
repeated.

I wouldn't be surprised if other platforms ought to be working in the
exact same way?

> +	"boot_targets=" \
> +		BOOT_TARGETS_MMC " "  \
> +		BOOT_TARGETS_USB " "  \
> +		BOOT_TARGETS_SATA " " \
> +		BOOT_TARGETS_PXE " "  \
> +		BOOT_TARGETS_DHCP " " \
> +		"\0" \

I'd be tempted to require the board-specific config to set boot_targets,
so that appropriate customization can be applied?

> +	"boot_envs=uEnv.txt\0" \

I wonder if boards want to customize that for backwards-compatibility?

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dennis Gilmore]

On Wed, 19 Feb 2014 10:40:15 -0700
Stephen Warren <swarren@wwwdotorg.org> wrote:

> On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
> > Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> 
> Patch description?
I failed in my rush to get it out for feedback.
 
> > diff --git a/include/config_distro_bootcmd.h
> > b/include/config_distro_bootcmd.h
> 
> > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> > +
> > +
> 
> Is there a need for 2 blank lines there?
no, will clean it up
 
> > +#define BOOTCMDS_COMMON \
> > +	"rootpart=1\0" \
> 
> We should really stop hard-coding that. I meant to (but evidently
> never got around to) re-write the commands so that they could
> automatically determine which partition to use, based on the MBR
> bootable flag or GPT partition flags.
> 
> Still, we can probably make that enhancement separately later.

I fully agree, we should be able to work it out later. I also renamed
it to bootpart since it is where we will boot from, which may or may
not be the root filesystem
 
> > +#define BOOT_TARGETS_MMC "mmc1 mmc0"
> 
> We really ought to make the order of multiple MMC devices in
> BOOT_TARGETS configurable. For example, we may have 2 boards that both
> want to boot from SD card if present, else fall back to internal eMMC,
> yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On
> Tegra, we're just lucky that hasn't been an issue yet. Equally, not
> all boards have 2 eMMC devices.

I did wonder if that was better being left out here and something that
the board set.
 
> > +	"scan_boot="
> > \
> > +		"echo Scanning ${devtype} ${devnum}...;
> > "                 \
> > +		"for prefix in ${boot_prefixes}; do
> > "                     \
> > +			"run sysboot_boot;
> > "                              \
> > +			"run envimport;
> > "                                 \
> > +			"run script_boot;
> > "                               \
> 
> This isn't quite right for the Raspberry Pi at least.
>
> What I wanted was for uEnv.txt to *always* be loaded from SD card
> before any other boot activity. The SD card is known to exist on this
> platform, since it's the only place the SoC's boot ROM can load the
> initial binary firmware from.

I know some distros use commands in uEnv.txt to boot, or at the least
they set variables and load a boot.scr I was trying to make sure we
cover those people. The definition of what uEnv.txt is and how it
should be used is pretty murky to me. I have seen it used in a few
different ways. I know some people really want them. So probably best
to work out a better way to support it.
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript
for instance specifies all the boot commands in uEnv.txt really I would
rather people just use a extlinux.conf file, I just do not want to take
away the option to use something people see as valuable.
 
> The idea is that since the Pi has nowhere to store any environment,
> and the default environment's boot_targets is hard-coded in the U-Boot
> binary, we need some way for the user to configure the value of
> boot_targets to e.g. force network or USB boot. We want to do this
> before executing bootcmd, so that bootcmd looks at the user's desired
> boot_targets, rather than part way through executing bootcmd, which is
> far too late.
> 
> Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still
> work even with the "run envimport" as above. However, I think we want
> to make the "run envimport" within scan_boot optional, so it doesn't
> get repeated.
> 
> I wouldn't be surprised if other platforms ought to be working in the
> exact same way?
> 
> > +	"boot_targets=" \
> > +		BOOT_TARGETS_MMC " "  \
> > +		BOOT_TARGETS_USB " "  \
> > +		BOOT_TARGETS_SATA " " \
> > +		BOOT_TARGETS_PXE " "  \
> > +		BOOT_TARGETS_DHCP " " \
> > +		"\0" \
> 
> I'd be tempted to require the board-specific config to set
> boot_targets, so that appropriate customization can be applied?
sure, Ideally its something that can be changed on the fly and we just
ship a suggested ordering. That is probably something for down the road
though. 
 
> > +	"boot_envs=uEnv.txt\0" \
> 
> I wonder if boards want to customize that for backwards-compatibility?
Perhaps.

Might need to redo some of this. I've since added SCSI and IDE and they
are things I have seen in the wild also. Maybe we can simplify things
somehow so that adding new hardware types is really simple.


Dennis

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/22/2014 01:20 AM, Dennis Gilmore wrote:
> On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 02/17/2014 10:56 AM, Dennis Gilmore wrote:

>>> diff --git a/include/config_distro_bootcmd.h

>>> +#define BOOTCMDS_COMMON \
>>> +	"rootpart=1\0" \
>>
>> We should really stop hard-coding that. I meant to (but evidently
>> never got around to) re-write the commands so that they could
>> automatically determine which partition to use, based on the MBR
>> bootable flag or GPT partition flags.
>>
>> Still, we can probably make that enhancement separately later.
> 
> I fully agree, we should be able to work it out later. I also renamed
> it to bootpart since it is where we will boot from, which may or may
> not be the root filesystem

Just as some history, when I first wrote these boot scripts for Tegra, I
was actually using that variable both inside the environment scripts to
find/load boot.scr, and within boot.scr to set the kernel root=
command-line option. More recently, I've moved to using root=PARTUUID=
or root=UUID= on the kernel command-line, so rootpart has become less
relevant, and indeed renaming it bootpart does make a lot more sense, as
you say.

>>> +	"scan_boot="
>>> \
>>> +		"echo Scanning ${devtype} ${devnum}...;
>>> "                 \
>>> +		"for prefix in ${boot_prefixes}; do
>>> "                     \
>>> +			"run sysboot_boot;
>>> "                              \
>>> +			"run envimport;
>>> "                                 \
>>> +			"run script_boot;
>>> "                               \
>>
>> This isn't quite right for the Raspberry Pi at least.
>>
>> What I wanted was for uEnv.txt to *always* be loaded from SD card
>> before any other boot activity. The SD card is known to exist on this
>> platform, since it's the only place the SoC's boot ROM can load the
>> initial binary firmware from.
> 
> I know some distros use commands in uEnv.txt to boot, or at the least
> they set variables and load a boot.scr I was trying to make sure we
> cover those people. The definition of what uEnv.txt is and how it
> should be used is pretty murky to me. I have seen it used in a few
> different ways. I know some people really want them. So probably best
> to work out a better way to support it.
> http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript
> for instance specifies all the boot commands in uEnv.txt really I would
> rather people just use a extlinux.conf file, I just do not want to take
> away the option to use something people see as valuable.

I'd suggest not touching uEnv.txt in config_distro_bootcmd.h, since it's
really not a part of the new standard we want to create. Instead, have
each board define CONFIG_PREBOOT to load it if they want it. I assume
that a very small number of boards will need uEnv.txt once we've
switched to this new scheme; just those that have nowhere to store a
persistent environment.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Mon, Feb 24, 2014 at 11:40:02AM -0700, Stephen Warren wrote:
> On 02/22/2014 01:20 AM, Dennis Gilmore wrote:
[snip]
> > I fully agree, we should be able to work it out later. I also renamed
> > it to bootpart since it is where we will boot from, which may or may
> > not be the root filesystem
> 
> Just as some history, when I first wrote these boot scripts for Tegra, I
> was actually using that variable both inside the environment scripts to
> find/load boot.scr, and within boot.scr to set the kernel root=
> command-line option. More recently, I've moved to using root=PARTUUID=
> or root=UUID= on the kernel command-line, so rootpart has become less
> relevant, and indeed renaming it bootpart does make a lot more sense, as
> you say.

For distro, this, oh my yes, this, is pretty nearly a must.  This
dislodged something in my brain which reminded me of a pain point we
have on some TI parts, which is which MMC device will the kernel have as
mmc0 vs mmc1 as because of regulartors, deferred probing and all of
that, it's board design dependent.  But passing in root=UUID= like
commodity distros have done for ages makes this irrelevant.  We need to
do this such that either can be used, probably as root= being something
that's given to us, rather than assumed by us.  But I would be sad if
everyone stopped using root=UUID= and started using /dev/mmcblk* names
in the commodity distro area.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140224/a255a03f/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
>  include/config_distro_bootcmd.h | 172 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 172 insertions(+)
>  create mode 100644 include/config_distro_bootcmd.h
>
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> new file mode 100644
> index 0000000..d32dc12
> --- /dev/null
> +++ b/include/config_distro_bootcmd.h
> @@ -0,0 +1,172 @@
> +/*
> + * (C) Copyright 2014
> + * NVIDIA Corporation <www.nvidia.com>
> + *  
> + * Copyright 2014 Red Hat, Inc.
> + *
> + * SPDX-License-Identifier:     GPL-2.0+
> + */
> +
> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> +
> +
> +#ifdef CONFIG_CMD_MMC
> +#define BOOTCMDS_MMC \
> +	"mmc_boot=" \
> +		"setenv devtype mmc; " \
> +		"if mmc dev ${devnum}; then " \
> +			"run scan_boot; " \
> +		"fi\0" \
> +	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
> +	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
> +#define BOOT_TARGETS_MMC "mmc1 mmc0"
> +#else
> +#define BOOTCMDS_MMC ""
> +#define BOOT_TARGETS_MMC ""
> +#endif
> +
> +#ifdef CONFIG_CMD_USB
> +#define BOOTCMD_INIT_USB "run usb_init; "
> +#define BOOTCMDS_USB \
> +	"usb_init=" \
> +		"if ${usb_need_init}; then " \
> +			"set usb_need_init false; " \
> +			"usb start 0; " \
> +		"fi\0" \
> +	\
> +	"usb_boot=" \
> +		"setenv devtype usb; " \
> +		BOOTCMD_INIT_USB \
> +		"if usb dev ${devnum}; then " \

This may have already been highlighted but I don't see where the kernel command line arguments can be set.
If you have the file system on the USB stick won't you need to direct the root to the stick?

Maybe I don't want to have a uEnv.txt file.

This is what I had to do when I did the similar implementation on the TI common file

http://patchwork.ozlabs.org/patch/292851/

> +			"run scan_boot; " \
> +		"fi\0" \
> +	\
> +	"bootcmd_usb0=setenv devnum 0; run usb_boot;\0"
> +#define BOOT_TARGETS_USB "usb0"
> +#else
> +#define BOOTCMD_INIT_USB ""
> +#define BOOTCMDS_USB ""
> +#define BOOT_TARGETS_USB ""
> +#endif
> +
> +#ifdef CONFIG_CMD_SATA
> +#define BOOTCMDS_SATA \
> +	"sata_boot=" \
> +		"setenv devtype sata; " \
> +		"if sata dev ${devnum}; then " \
> +			"run scan_boot; " \

Same as above

> +		"fi\0" \
> +	\
> +	"bootcmd_sata0=setenv devnum 0; run sata_boot;\0"
> +	"bootcmd_sata1=setenv devnum 1; run sata_boot;\0"
> +#define BOOT_TARGETS_USB "sata0 sata1"
> +#else
> +#define BOOTCMDS_SATA ""
> +#define BOOT_TARGETS_SATA ""
> +#endif
> +
> +#ifdef CONFIG_CMD_DHCP
> +#define BOOTCMDS_DHCP \
> +	"bootcmd_dhcp=" \
> +		BOOTCMD_INIT_USB \
> +		"if dhcp ${scriptaddr} boot.scr.uimg; then "\
> +			"source ${scriptaddr}; " \
> +		"fi\0"
> +#define BOOT_TARGETS_DHCP "dhcp"
> +#else
> +#define BOOTCMDS_DHCP ""
> +#define BOOT_TARGETS_DHCP ""
> +#endif
> +
> +#if defined(CONFIG_CMD_DHCP) && defined(CONFIG_CMD_PXE)
> +#define BOOTCMDS_PXE \
> +	"bootcmd_pxe=" \
> +		BOOTCMD_INIT_USB \
> +		"dhcp; " \
> +		"if pxe get; then " \
> +			"pxe boot; " \
> +		"fi\0"
> +#define BOOT_TARGETS_PXE "pxe"
> +#else
> +#define BOOTCMDS_PXE ""
> +#define BOOT_TARGETS_PXE ""
> +#endif
> +
>


-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 11:44 AM, Dan Murphy wrote:
> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>

>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h

>> +#ifdef CONFIG_CMD_USB
>> +#define BOOTCMD_INIT_USB "run usb_init; "
>> +#define BOOTCMDS_USB \
>> +	"usb_init=" \
>> +		"if ${usb_need_init}; then " \
>> +			"set usb_need_init false; " \
>> +			"usb start 0; " \
>> +		"fi\0" \
>> +	\
>> +	"usb_boot=" \
>> +		"setenv devtype usb; " \
>> +		BOOTCMD_INIT_USB \
>> +		"if usb dev ${devnum}; then " \
> 
> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
> If you have the file system on the USB stick won't you need to direct the root to the stick?

They would be set in boot.scr or extlinux.cfg on the disk that the
system boots from; the kernel cmdline is part of the OS that's installed
there, not part of U-Boot. This is why these boot scripts load a
script/config-file from the disk which in turn defines which
kernel/DTB/cmdline to use, rather than directly loading a kernel and
DTB. This approach should even be suitable for booting a non-Linux-OS,
with suitable commands in boot.scr.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

On 02/19/2014 12:48 PM, Stephen Warren wrote:
> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>> +#ifdef CONFIG_CMD_USB
>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>> +#define BOOTCMDS_USB \
>>> +	"usb_init=" \
>>> +		"if ${usb_need_init}; then " \
>>> +			"set usb_need_init false; " \
>>> +			"usb start 0; " \
>>> +		"fi\0" \
>>> +	\
>>> +	"usb_boot=" \
>>> +		"setenv devtype usb; " \
>>> +		BOOTCMD_INIT_USB \
>>> +		"if usb dev ${devnum}; then " \
>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>> If you have the file system on the USB stick won't you need to direct the root to the stick?
> They would be set in boot.scr or extlinux.cfg on the disk that the
> system boots from; the kernel cmdline is part of the OS that's installed
> there, not part of U-Boot. This is why these boot scripts load a
> script/config-file from the disk which in turn defines which
> kernel/DTB/cmdline to use, rather than directly loading a kernel and
> DTB. This approach should even be suitable for booting a non-Linux-OS,
> with suitable commands in boot.scr.

But shouldn't the config file just be an override?

I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.

If no config file exists should we not try to default to a known good default tested case?

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 11:52 AM, Dan Murphy wrote:
> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>> +#ifdef CONFIG_CMD_USB
>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>> +#define BOOTCMDS_USB \
>>>> +	"usb_init=" \
>>>> +		"if ${usb_need_init}; then " \
>>>> +			"set usb_need_init false; " \
>>>> +			"usb start 0; " \
>>>> +		"fi\0" \
>>>> +	\
>>>> +	"usb_boot=" \
>>>> +		"setenv devtype usb; " \
>>>> +		BOOTCMD_INIT_USB \
>>>> +		"if usb dev ${devnum}; then " \
>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>> They would be set in boot.scr or extlinux.cfg on the disk that the
>> system boots from; the kernel cmdline is part of the OS that's installed
>> there, not part of U-Boot. This is why these boot scripts load a
>> script/config-file from the disk which in turn defines which
>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>> with suitable commands in boot.scr.
> 
> But shouldn't the config file just be an override?
> 
> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
> 
> If no config file exists should we not try to default to a known good default tested case?

I believe always loading a script/config-file is the simplest and most
flexible approach, for a *distro* *oriented* boot process.

Now, specific U-Boot board configs can always add extra stuff on the end
(or start?) of bootcmd in order to do some custom fallbacks or
backwards-compatibility if they want, but I'm certainly not planning on
doing anything like that for Tegra or Raspberry Pi, for example.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

On 02/19/2014 12:57 PM, Stephen Warren wrote:
> On 02/19/2014 11:52 AM, Dan Murphy wrote:
>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>>> +#ifdef CONFIG_CMD_USB
>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>>> +#define BOOTCMDS_USB \
>>>>> +	"usb_init=" \
>>>>> +		"if ${usb_need_init}; then " \
>>>>> +			"set usb_need_init false; " \
>>>>> +			"usb start 0; " \
>>>>> +		"fi\0" \
>>>>> +	\
>>>>> +	"usb_boot=" \
>>>>> +		"setenv devtype usb; " \
>>>>> +		BOOTCMD_INIT_USB \
>>>>> +		"if usb dev ${devnum}; then " \
>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>>> They would be set in boot.scr or extlinux.cfg on the disk that the
>>> system boots from; the kernel cmdline is part of the OS that's installed
>>> there, not part of U-Boot. This is why these boot scripts load a
>>> script/config-file from the disk which in turn defines which
>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>>> with suitable commands in boot.scr.
>> But shouldn't the config file just be an override?
>>
>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
>>
>> If no config file exists should we not try to default to a known good default tested case?
> I believe always loading a script/config-file is the simplest and most
> flexible approach, for a *distro* *oriented* boot process.
>
> Now, specific U-Boot board configs can always add extra stuff on the end
> (or start?) of bootcmd in order to do some custom fallbacks or
> backwards-compatibility if they want, but I'm certainly not planning on
> doing anything like that for Tegra or Raspberry Pi, for example.

Yeah I am not seeing how the board config can do that if there is no provisions in the common file.

On another note there is no support in here for NAND.  Was there a plan to pull that in as well?

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 11:59 AM, Dan Murphy wrote:
> On 02/19/2014 12:57 PM, Stephen Warren wrote:
>> On 02/19/2014 11:52 AM, Dan Murphy wrote:
>>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>>>> +#ifdef CONFIG_CMD_USB
>>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>>>> +#define BOOTCMDS_USB \
>>>>>> +	"usb_init=" \
>>>>>> +		"if ${usb_need_init}; then " \
>>>>>> +			"set usb_need_init false; " \
>>>>>> +			"usb start 0; " \
>>>>>> +		"fi\0" \
>>>>>> +	\
>>>>>> +	"usb_boot=" \
>>>>>> +		"setenv devtype usb; " \
>>>>>> +		BOOTCMD_INIT_USB \
>>>>>> +		"if usb dev ${devnum}; then " \
>>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>>>> They would be set in boot.scr or extlinux.cfg on the disk that the
>>>> system boots from; the kernel cmdline is part of the OS that's installed
>>>> there, not part of U-Boot. This is why these boot scripts load a
>>>> script/config-file from the disk which in turn defines which
>>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>>>> with suitable commands in boot.scr.
>>> But shouldn't the config file just be an override?
>>>
>>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
>>>
>>> If no config file exists should we not try to default to a known good default tested case?
>> I believe always loading a script/config-file is the simplest and most
>> flexible approach, for a *distro* *oriented* boot process.
>>
>> Now, specific U-Boot board configs can always add extra stuff on the end
>> (or start?) of bootcmd in order to do some custom fallbacks or
>> backwards-compatibility if they want, but I'm certainly not planning on
>> doing anything like that for Tegra or Raspberry Pi, for example.
> 
> Yeah I am not seeing how the board config can do that if there is no provisions in the common file.

Presumably all it needs is an extra hook/variable that is added to the
start/end of bootcmd. Should be pretty easy to add in a future patch
rev, or followon patch.

> On another note there is no support in here for NAND.  Was there a plan to pull that in as well?

A generic Linux distro wouldn't be installing a kernel to NAND, but
would rather put it into the /boot filesystem. NAND boot is something
that'd be best supported by the custom hook we discussed above.

The commit description for this commit should have set the scene that
this series is all about providing a way for a generic Linux distro to
create a generic installable media set that boots the same way across n
different boards with U-Boot, and similarly also to set up the installed
distro filesystem in a single generic way that can boot on any board it
gets installed to. It's all about avoiding board-specific boot options
such as NAND, and hence may well not be applicable to boards that
primarily/only boot from NAND; they would still need custom distro
install media and hooks to set up the installed filesystem.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Wed, Feb 19, 2014 at 12:04:12PM -0700, Stephen Warren wrote:
> On 02/19/2014 11:59 AM, Dan Murphy wrote:
> > On 02/19/2014 12:57 PM, Stephen Warren wrote:
> >> On 02/19/2014 11:52 AM, Dan Murphy wrote:
> >>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
> >>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
> >>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
> >>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> >>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> >>>>>> +#ifdef CONFIG_CMD_USB
> >>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
> >>>>>> +#define BOOTCMDS_USB \
> >>>>>> +	"usb_init=" \
> >>>>>> +		"if ${usb_need_init}; then " \
> >>>>>> +			"set usb_need_init false; " \
> >>>>>> +			"usb start 0; " \
> >>>>>> +		"fi\0" \
> >>>>>> +	\
> >>>>>> +	"usb_boot=" \
> >>>>>> +		"setenv devtype usb; " \
> >>>>>> +		BOOTCMD_INIT_USB \
> >>>>>> +		"if usb dev ${devnum}; then " \
> >>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
> >>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
> >>>> They would be set in boot.scr or extlinux.cfg on the disk that the
> >>>> system boots from; the kernel cmdline is part of the OS that's installed
> >>>> there, not part of U-Boot. This is why these boot scripts load a
> >>>> script/config-file from the disk which in turn defines which
> >>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
> >>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
> >>>> with suitable commands in boot.scr.
> >>> But shouldn't the config file just be an override?
> >>>
> >>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
> >>>
> >>> If no config file exists should we not try to default to a known good default tested case?
> >> I believe always loading a script/config-file is the simplest and most
> >> flexible approach, for a *distro* *oriented* boot process.
> >>
> >> Now, specific U-Boot board configs can always add extra stuff on the end
> >> (or start?) of bootcmd in order to do some custom fallbacks or
> >> backwards-compatibility if they want, but I'm certainly not planning on
> >> doing anything like that for Tegra or Raspberry Pi, for example.
> > 
> > Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
> 
> Presumably all it needs is an extra hook/variable that is added to the
> start/end of bootcmd. Should be pretty easy to add in a future patch
> rev, or followon patch.
> 
> > On another note there is no support in here for NAND.  Was there a plan to pull that in as well?
> 
> A generic Linux distro wouldn't be installing a kernel to NAND, but
> would rather put it into the /boot filesystem. NAND boot is something
> that'd be best supported by the custom hook we discussed above.

Wait, why would a generic Linux distro be installing to eMMC but not to
NAND ?  Not that this series needs to be the final point in the
discussion and all.

> The commit description for this commit should have set the scene that
> this series is all about providing a way for a generic Linux distro to
> create a generic installable media set that boots the same way across n
> different boards with U-Boot, and similarly also to set up the installed
> distro filesystem in a single generic way that can boot on any board it
> gets installed to. It's all about avoiding board-specific boot options
> such as NAND, and hence may well not be applicable to boards that
> primarily/only boot from NAND; they would still need custom distro
> install media and hooks to set up the installed filesystem.

Why is NAND special but SATA not, other than desktops often have SATA
exposed but not NAND?  Even more so when you consider that from the
Linux side of things, dealing with NAND is dealing with NAND and it's
not board specific.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/7cc59b49/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 12:10 PM, Tom Rini wrote:
...
>> A generic Linux distro wouldn't be installing a kernel to NAND, but
>> would rather put it into the /boot filesystem. NAND boot is something
>> that'd be best supported by the custom hook we discussed above.
> 
> Wait, why would a generic Linux distro be installing to eMMC but not to
> NAND ?  Not that this series needs to be the final point in the
> discussion and all.

I should point out that I was talking about raw NAND MTD partitions
rather than a NAND device with a regular partition table and normal
filesystems within it.

If the NAND is exposed as a regular block device with a regular
filesystem, then it'd look just like any other block device to a generic
distro installer, and hence it could put /boot there, and this patch (or
future enhancement) could certainly usefully contain a generic
bootcmd_nand that used it.

However, if the NAND has hard-coded MTD partitions, and/or the
partitions have no filesystem but rather contain e.g. a raw
zImage/uImage, then that would require board-/SoC-specific support in
the distro kernel and installer, and hence we wouldn't be talking about
a *generic* installer/distro, and *generic* installers/distros are what
this patch series is all about.

>> The commit description for this commit should have set the scene that
>> this series is all about providing a way for a generic Linux distro to
>> create a generic installable media set that boots the same way across n
>> different boards with U-Boot, and similarly also to set up the installed
>> distro filesystem in a single generic way that can boot on any board it
>> gets installed to. It's all about avoiding board-specific boot options
>> such as NAND, and hence may well not be applicable to boards that
>> primarily/only boot from NAND; they would still need custom distro
>> install media and hooks to set up the installed filesystem.
> 
> Why is NAND special but SATA not, other than desktops often have SATA
> exposed but not NAND?  Even more so when you consider that from the
> Linux side of things, dealing with NAND is dealing with NAND and it's
> not board specific.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Wed, Feb 19, 2014 at 12:16:13PM -0700, Stephen Warren wrote:
> On 02/19/2014 12:10 PM, Tom Rini wrote:
> ...
> >> A generic Linux distro wouldn't be installing a kernel to NAND, but
> >> would rather put it into the /boot filesystem. NAND boot is something
> >> that'd be best supported by the custom hook we discussed above.
> > 
> > Wait, why would a generic Linux distro be installing to eMMC but not to
> > NAND ?  Not that this series needs to be the final point in the
> > discussion and all.
> 
> I should point out that I was talking about raw NAND MTD partitions
> rather than a NAND device with a regular partition table and normal
> filesystems within it.
> 
> If the NAND is exposed as a regular block device with a regular
> filesystem, then it'd look just like any other block device to a generic
> distro installer, and hence it could put /boot there, and this patch (or
> future enhancement) could certainly usefully contain a generic
> bootcmd_nand that used it.
> 
> However, if the NAND has hard-coded MTD partitions, and/or the
> partitions have no filesystem but rather contain e.g. a raw
> zImage/uImage, then that would require board-/SoC-specific support in
> the distro kernel and installer, and hence we wouldn't be talking about
> a *generic* installer/distro, and *generic* installers/distros are what
> this patch series is all about.

I would put a generic distro knowing how to deal, genericially at least,
with NAND on par with knowing how to deal with HW RAID or other not too
uncommon desktop features.  If /dev/mtdblockN then offer UBI or a few
other choices, else if /dev/sd* then offer ext* or btrfs or a few other
choices.  But I think that's also getting off-topic for us at least (and
yes, am335x is doing raw kernel storage today, fixing that is on my
list).

One thing this series does have to cope with, some way or another, is to
be able to say "Oh, you have other boot devices too, we must handle them
somehow".  With my TI custodian hat on, it would be quite handy for
Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's
going to make me quite grumpy if I can't also easily support AM335x GP
EVM and its NAND and I start to worry if QSPI, which I have a feeling is
going to take off like eMMC did, is going to just get ignored and when
Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI
on-board we don't start kicking ourselves again.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/e806f0e7/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 12:36 PM, Tom Rini wrote:
...
> I would put a generic distro knowing how to deal, genericially at least,
> with NAND on par with knowing how to deal with HW RAID or other not too
> uncommon desktop features.  If /dev/mtdblockN then offer UBI or a few
> other choices, else if /dev/sd* then offer ext* or btrfs or a few other

But how do /dev/mtdblockN get into existence? MTD partitions have
historically been defined on the kernel command-line haven't they, and
hence it'd require a board-specific cmdline to support that. Hmmm.
Perhaps they can be specified in DT nowadays? If so, then NAND should
indeed be pretty easy to deal with.

> One thing this series does have to cope with, some way or another, is to
> be able to say "Oh, you have other boot devices too, we must handle them
> somehow".  With my TI custodian hat on, it would be quite handy for
> Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's
> going to make me quite grumpy if I can't also easily support AM335x GP
> EVM and its NAND and I start to worry if QSPI, which I have a feeling is
> going to take off like eMMC did, is going to just get ignored and when
> Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI
> on-board we don't start kicking ourselves again.

I assume QSPI would be just the system boot flash, and not for
filesystem storage? As a general rule, I assert that distros shouldn't
have to know anything about installing/updating bootloaders; that should
be something that happens before you attempt to use a distro installer,
and most likely uses board-/SoC-specific tools. If QSPI is filesystem
storage, then assuming it shows up like any other block device, it
should work out just like NAND as we discussed above.

Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards
which require the firmware in a partition on the SD card, since there's
no other storage device. Still, hopefully that's as simple as detecting
the specific board based on DT compatible value, and installing a
particular extra package for it.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Wed, Feb 19, 2014 at 12:43:49PM -0700, Stephen Warren wrote:
> On 02/19/2014 12:36 PM, Tom Rini wrote:
> ...
> > I would put a generic distro knowing how to deal, genericially at least,
> > with NAND on par with knowing how to deal with HW RAID or other not too
> > uncommon desktop features.  If /dev/mtdblockN then offer UBI or a few
> > other choices, else if /dev/sd* then offer ext* or btrfs or a few other
> 
> But how do /dev/mtdblockN get into existence? MTD partitions have
> historically been defined on the kernel command-line haven't they, and
> hence it'd require a board-specific cmdline to support that. Hmmm.
> Perhaps they can be specified in DT nowadays? If so, then NAND should
> indeed be pretty easy to deal with.

They've been in the device tree since before ARM started converting :)

> > One thing this series does have to cope with, some way or another, is to
> > be able to say "Oh, you have other boot devices too, we must handle them
> > somehow".  With my TI custodian hat on, it would be quite handy for
> > Beaglebone to use this and have Fedora/SuSE/etc/etc "just work" but it's
> > going to make me quite grumpy if I can't also easily support AM335x GP
> > EVM and its NAND and I start to worry if QSPI, which I have a feeling is
> > going to take off like eMMC did, is going to just get ignored and when
> > Rasberry Cream Pi or Beaglebone Metalic Purple comes out with QSPI
> > on-board we don't start kicking ourselves again.
> 
> I assume QSPI would be just the system boot flash, and not for
> filesystem storage? As a general rule, I assert that distros shouldn't
> have to know anything about installing/updating bootloaders; that should
> be something that happens before you attempt to use a distro installer,
> and most likely uses board-/SoC-specific tools. If QSPI is filesystem
> storage, then assuming it shows up like any other block device, it
> should work out just like NAND as we discussed above.

QSPI is another MTD block device, and can be of "reasonable" size.

My point being that we don't want to say that the only use cases for
"generic distro" are SD/SATA/"network".  If we say from the outset that
we won't even try and expose $FOO because it's not something they deal
with today, people certainly won't.

> Exceptions might be e.g. the Raspberry Pi and some of the Beagle* boards
> which require the firmware in a partition on the SD card, since there's
> no other storage device. Still, hopefully that's as simple as detecting
> the specific board based on DT compatible value, and installing a
> particular extra package for it.

What I'm saying is that while Beaglebone Black ships with eMMC today
(and oh, hey, duh, Beagleboard not-xM ships with NAND), tomorrows hot
commodity board quite well include a different on-baord storage, but one
we can worry about a bit today.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/c71ba159/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dennis Gilmore]

On Wed, 19 Feb 2014 12:43:49 -0700
Stephen Warren <swarren@wwwdotorg.org> wrote:

> On 02/19/2014 12:36 PM, Tom Rini wrote:
> ...
> > I would put a generic distro knowing how to deal, genericially at
> > least, with NAND on par with knowing how to deal with HW RAID or
> > other not too uncommon desktop features.  If /dev/mtdblockN then
> > offer UBI or a few other choices, else if /dev/sd* then offer ext*
> > or btrfs or a few other
> 
> But how do /dev/mtdblockN get into existence? MTD partitions have
> historically been defined on the kernel command-line haven't they, and
> hence it'd require a board-specific cmdline to support that. Hmmm.
> Perhaps they can be specified in DT nowadays? If so, then NAND should
> indeed be pretty easy to deal with.
> 
> > One thing this series does have to cope with, some way or another,
> > is to be able to say "Oh, you have other boot devices too, we must
> > handle them somehow".  With my TI custodian hat on, it would be
> > quite handy for Beaglebone to use this and have Fedora/SuSE/etc/etc
> > "just work" but it's going to make me quite grumpy if I can't also
> > easily support AM335x GP EVM and its NAND and I start to worry if
> > QSPI, which I have a feeling is going to take off like eMMC did, is
> > going to just get ignored and when Rasberry Cream Pi or Beaglebone
> > Metalic Purple comes out with QSPI on-board we don't start kicking
> > ourselves again.
> 
> I assume QSPI would be just the system boot flash, and not for
> filesystem storage? As a general rule, I assert that distros shouldn't
> have to know anything about installing/updating bootloaders; that
> should be something that happens before you attempt to use a distro
> installer, and most likely uses board-/SoC-specific tools. If QSPI is
> filesystem storage, then assuming it shows up like any other block
> device, it should work out just like NAND as we discussed above.
> 
> Exceptions might be e.g. the Raspberry Pi and some of the Beagle*
> boards which require the firmware in a partition on the SD card,
> since there's no other storage device. Still, hopefully that's as
> simple as detecting the specific board based on DT compatible value,
> and installing a particular extra package for it.

I'm actually going to use raw space for the MLO and u-boot.img, in
Fedora 21, its easier and doesn't require special partitioning. I
assume that when a device with QSPI comes along we will write things in
a way that it can easily be extended to support and boards will ship
day one with working support.  That is assuming that there is QSPI
chips with enough size to be useful are readily available.

Dennis

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

On 02/19/2014 01:04 PM, Stephen Warren wrote:
> On 02/19/2014 11:59 AM, Dan Murphy wrote:
>> On 02/19/2014 12:57 PM, Stephen Warren wrote:
>>> On 02/19/2014 11:52 AM, Dan Murphy wrote:
>>>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>>>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>>>>> +#ifdef CONFIG_CMD_USB
>>>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>>>>> +#define BOOTCMDS_USB \
>>>>>>> +	"usb_init=" \
>>>>>>> +		"if ${usb_need_init}; then " \
>>>>>>> +			"set usb_need_init false; " \
>>>>>>> +			"usb start 0; " \
>>>>>>> +		"fi\0" \
>>>>>>> +	\
>>>>>>> +	"usb_boot=" \
>>>>>>> +		"setenv devtype usb; " \
>>>>>>> +		BOOTCMD_INIT_USB \
>>>>>>> +		"if usb dev ${devnum}; then " \
>>>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>>>>> They would be set in boot.scr or extlinux.cfg on the disk that the
>>>>> system boots from; the kernel cmdline is part of the OS that's installed
>>>>> there, not part of U-Boot. This is why these boot scripts load a
>>>>> script/config-file from the disk which in turn defines which
>>>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>>>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>>>>> with suitable commands in boot.scr.
>>>> But shouldn't the config file just be an override?
>>>>
>>>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
>>>>
>>>> If no config file exists should we not try to default to a known good default tested case?
>>> I believe always loading a script/config-file is the simplest and most
>>> flexible approach, for a *distro* *oriented* boot process.
>>>
>>> Now, specific U-Boot board configs can always add extra stuff on the end
>>> (or start?) of bootcmd in order to do some custom fallbacks or
>>> backwards-compatibility if they want, but I'm certainly not planning on
>>> doing anything like that for Tegra or Raspberry Pi, for example.
>> Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
> Presumably all it needs is an extra hook/variable that is added to the
> start/end of bootcmd. Should be pretty easy to add in a future patch
> rev, or followon patch.
<snip>

I am not sure it is that simple.  Once you are in the BOOTCMD macro's if you end up back at the board file macros
you kinda have to repeat the load steps again just to get the args or specifics set.

When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as

"run board_cfg"  Which can be a fall back to a board file specific configuration macro for whatever you want.

If you don't need it then it is NULL

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 12:32 PM, Dan Murphy wrote:
> On 02/19/2014 01:04 PM, Stephen Warren wrote:
>> On 02/19/2014 11:59 AM, Dan Murphy wrote:
>>> On 02/19/2014 12:57 PM, Stephen Warren wrote:
>>>> On 02/19/2014 11:52 AM, Dan Murphy wrote:
...
>>>>> If no config file exists should we not try to default to a known good default tested case?
>>>>
>>>> I believe always loading a script/config-file is the simplest and most
>>>> flexible approach, for a *distro* *oriented* boot process.
>>>>
>>>> Now, specific U-Boot board configs can always add extra stuff on the end
>>>> (or start?) of bootcmd in order to do some custom fallbacks or
>>>> backwards-compatibility if they want, but I'm certainly not planning on
>>>> doing anything like that for Tegra or Raspberry Pi, for example.
>>>
>>> Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
>>
>> Presumably all it needs is an extra hook/variable that is added to the
>> start/end of bootcmd. Should be pretty easy to add in a future patch
>> rev, or followon patch.
> <snip>
> 
> I am not sure it is that simple.  Once you are in the BOOTCMD macro's if you end up back at the board file macros
> you kinda have to repeat the load steps again just to get the args or specifics set.
> 
> When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as
> 
> "run board_cfg"  Which can be a fall back to a board file specific configuration macro for whatever you want.
> 
> If you don't need it then it is NULL

If the value of bootcmd was customizable, then you could easily add e.g.
"nand_custom" as the last entry in it, and that could do whatever was
appropriate (it would translate to run bootcmd_nand_custom, which the
board would define). That'd work very consistently with all the other
options.

Eventually, I'd love to have a BIOS-like (runtime) config menu, where
any variable named bootcmd_* would show up in the list, and provide an
interactive way to re-order and enable/disable all the options, i.e. an
interactive menu-driven editor for the value of $bootcmd. If custom
options get implemented the same way as the standard options, then the
custom options would integrate very well into that scheme.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

On 02/19/2014 01:38 PM, Stephen Warren wrote:
> On 02/19/2014 12:32 PM, Dan Murphy wrote:
>> On 02/19/2014 01:04 PM, Stephen Warren wrote:
>>> On 02/19/2014 11:59 AM, Dan Murphy wrote:
>>>> On 02/19/2014 12:57 PM, Stephen Warren wrote:
>>>>> On 02/19/2014 11:52 AM, Dan Murphy wrote:
> ...
>>>>>> If no config file exists should we not try to default to a known good default tested case?
>>>>> I believe always loading a script/config-file is the simplest and most
>>>>> flexible approach, for a *distro* *oriented* boot process.
>>>>>
>>>>> Now, specific U-Boot board configs can always add extra stuff on the end
>>>>> (or start?) of bootcmd in order to do some custom fallbacks or
>>>>> backwards-compatibility if they want, but I'm certainly not planning on
>>>>> doing anything like that for Tegra or Raspberry Pi, for example.
>>>> Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
>>> Presumably all it needs is an extra hook/variable that is added to the
>>> start/end of bootcmd. Should be pretty easy to add in a future patch
>>> rev, or followon patch.
>> <snip>
>>
>> I am not sure it is that simple.  Once you are in the BOOTCMD macro's if you end up back at the board file macros
>> you kinda have to repeat the load steps again just to get the args or specifics set.
>>
>> When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as
>>
>> "run board_cfg"  Which can be a fall back to a board file specific configuration macro for whatever you want.
>>
>> If you don't need it then it is NULL
> If the value of bootcmd was customizable, then you could easily add e.g.
> "nand_custom" as the last entry in it, and that could do whatever was
> appropriate (it would translate to run bootcmd_nand_custom, which the
> board would define). That'd work very consistently with all the other
> options.

Well is this not what the BB patch does is calls upon the common boot_cmd and if that
fails then comes back to the board config to run nand_boot?

This does not really solve any of my issue of not having (or realizing I need) a script for boot on the boot partition.
No default case here to rely on as an in tree solution.

Dan

> Eventually, I'd love to have a BIOS-like (runtime) config menu, where
> any variable named bootcmd_* would show up in the list, and provide an
> interactive way to re-order and enable/disable all the options, i.e. an
> interactive menu-driven editor for the value of $bootcmd. If custom
> options get implemented the same way as the standard options, then the
> custom options would integrate very well into that scheme.


-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Eric Nelson]

On 02/19/2014 11:57 AM, Stephen Warren wrote:
> On 02/19/2014 11:52 AM, Dan Murphy wrote:
>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>>> +#ifdef CONFIG_CMD_USB
>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>>> +#define BOOTCMDS_USB \
>>>>> +	"usb_init=" \
>>>>> +		"if ${usb_need_init}; then " \
>>>>> +			"set usb_need_init false; " \
>>>>> +			"usb start 0; " \
>>>>> +		"fi\0" \
>>>>> +	\
>>>>> +	"usb_boot=" \
>>>>> +		"setenv devtype usb; " \
>>>>> +		BOOTCMD_INIT_USB \
>>>>> +		"if usb dev ${devnum}; then " \
>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>>> They would be set in boot.scr or extlinux.cfg on the disk that the
>>> system boots from; the kernel cmdline is part of the OS that's installed
>>> there, not part of U-Boot. This is why these boot scripts load a
>>> script/config-file from the disk which in turn defines which
>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>>> with suitable commands in boot.scr.
>>
>> But shouldn't the config file just be an override?
>>
>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
>>
>> If no config file exists should we not try to default to a known good default tested case?
>
> I believe always loading a script/config-file is the simplest and most
> flexible approach, for a *distro* *oriented* boot process.

+1

Scripts have the benefit of putting everything into a relatively
easy-to-read form that only uses documented U-Boot commands, not
board-specific constructs.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

On 02/19/2014 01:02 PM, Eric Nelson wrote:
> On 02/19/2014 11:57 AM, Stephen Warren wrote:
>> On 02/19/2014 11:52 AM, Dan Murphy wrote:
>>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>>>> +#ifdef CONFIG_CMD_USB
>>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>>>> +#define BOOTCMDS_USB \
>>>>>> +    "usb_init=" \
>>>>>> +        "if ${usb_need_init}; then " \
>>>>>> +            "set usb_need_init false; " \
>>>>>> +            "usb start 0; " \
>>>>>> +        "fi\0" \
>>>>>> +    \
>>>>>> +    "usb_boot=" \
>>>>>> +        "setenv devtype usb; " \
>>>>>> +        BOOTCMD_INIT_USB \
>>>>>> +        "if usb dev ${devnum}; then " \
>>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>>>> They would be set in boot.scr or extlinux.cfg on the disk that the
>>>> system boots from; the kernel cmdline is part of the OS that's installed
>>>> there, not part of U-Boot. This is why these boot scripts load a
>>>> script/config-file from the disk which in turn defines which
>>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>>>> with suitable commands in boot.scr.
>>>
>>> But shouldn't the config file just be an override?
>>>
>>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
>>>
>>> If no config file exists should we not try to default to a known good default tested case?
>>
>> I believe always loading a script/config-file is the simplest and most
>> flexible approach, for a *distro* *oriented* boot process.
>
> +1
>
> Scripts have the benefit of putting everything into a relatively
> easy-to-read form that only uses documented U-Boot commands, not
> board-specific constructs.
>

Oh don't get me wrong I agree with having the scripts.

Just sayin we should not rely on the scripts being there and mandating their usage.
We may want to have a fall back to a known good tested configuration.

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Wed, Feb 19, 2014 at 01:05:15PM -0600, Dan Murphy wrote:
> On 02/19/2014 01:02 PM, Eric Nelson wrote:
> > On 02/19/2014 11:57 AM, Stephen Warren wrote:
> >> On 02/19/2014 11:52 AM, Dan Murphy wrote:
> >>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
> >>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
> >>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
> >>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> >>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> >>>>>> +#ifdef CONFIG_CMD_USB
> >>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
> >>>>>> +#define BOOTCMDS_USB \
> >>>>>> +    "usb_init=" \
> >>>>>> +        "if ${usb_need_init}; then " \
> >>>>>> +            "set usb_need_init false; " \
> >>>>>> +            "usb start 0; " \
> >>>>>> +        "fi\0" \
> >>>>>> +    \
> >>>>>> +    "usb_boot=" \
> >>>>>> +        "setenv devtype usb; " \
> >>>>>> +        BOOTCMD_INIT_USB \
> >>>>>> +        "if usb dev ${devnum}; then " \
> >>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
> >>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
> >>>> They would be set in boot.scr or extlinux.cfg on the disk that the
> >>>> system boots from; the kernel cmdline is part of the OS that's installed
> >>>> there, not part of U-Boot. This is why these boot scripts load a
> >>>> script/config-file from the disk which in turn defines which
> >>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
> >>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
> >>>> with suitable commands in boot.scr.
> >>>
> >>> But shouldn't the config file just be an override?
> >>>
> >>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
> >>>
> >>> If no config file exists should we not try to default to a known good default tested case?
> >>
> >> I believe always loading a script/config-file is the simplest and most
> >> flexible approach, for a *distro* *oriented* boot process.
> >
> > +1
> >
> > Scripts have the benefit of putting everything into a relatively
> > easy-to-read form that only uses documented U-Boot commands, not
> > board-specific constructs.
> >
> 
> Oh don't get me wrong I agree with having the scripts.
> 
> Just sayin we should not rely on the scripts being there and mandating
> their usage.
> We may want to have a fall back to a known good tested configuration.

I think I see where you're coming from, but it's already expected that
you're passing in a good device tree too, so it would be making sure
that you also have a useful env file to get loaded in the DHCP or PXE
case.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/0661c2bd/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

On 02/19/2014 01:16 PM, Tom Rini wrote:
> On Wed, Feb 19, 2014 at 01:05:15PM -0600, Dan Murphy wrote:
>> On 02/19/2014 01:02 PM, Eric Nelson wrote:
>>> On 02/19/2014 11:57 AM, Stephen Warren wrote:
>>>> On 02/19/2014 11:52 AM, Dan Murphy wrote:
>>>>> On 02/19/2014 12:48 PM, Stephen Warren wrote:
>>>>>> On 02/19/2014 11:44 AM, Dan Murphy wrote:
>>>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>>>>>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>>>>>>>> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
>>>>>>>> +#ifdef CONFIG_CMD_USB
>>>>>>>> +#define BOOTCMD_INIT_USB "run usb_init; "
>>>>>>>> +#define BOOTCMDS_USB \
>>>>>>>> +    "usb_init=" \
>>>>>>>> +        "if ${usb_need_init}; then " \
>>>>>>>> +            "set usb_need_init false; " \
>>>>>>>> +            "usb start 0; " \
>>>>>>>> +        "fi\0" \
>>>>>>>> +    \
>>>>>>>> +    "usb_boot=" \
>>>>>>>> +        "setenv devtype usb; " \
>>>>>>>> +        BOOTCMD_INIT_USB \
>>>>>>>> +        "if usb dev ${devnum}; then " \
>>>>>>> This may have already been highlighted but I don't see where the kernel command line arguments can be set.
>>>>>>> If you have the file system on the USB stick won't you need to direct the root to the stick?
>>>>>> They would be set in boot.scr or extlinux.cfg on the disk that the
>>>>>> system boots from; the kernel cmdline is part of the OS that's installed
>>>>>> there, not part of U-Boot. This is why these boot scripts load a
>>>>>> script/config-file from the disk which in turn defines which
>>>>>> kernel/DTB/cmdline to use, rather than directly loading a kernel and
>>>>>> DTB. This approach should even be suitable for booting a non-Linux-OS,
>>>>>> with suitable commands in boot.scr.
>>>>> But shouldn't the config file just be an override?
>>>>>
>>>>> I don't know if we should be having to need to load a boot.scr or any config file just to get the kernel to boot.
>>>>>
>>>>> If no config file exists should we not try to default to a known good default tested case?
>>>> I believe always loading a script/config-file is the simplest and most
>>>> flexible approach, for a *distro* *oriented* boot process.
>>> +1
>>>
>>> Scripts have the benefit of putting everything into a relatively
>>> easy-to-read form that only uses documented U-Boot commands, not
>>> board-specific constructs.
>>>
>> Oh don't get me wrong I agree with having the scripts.
>>
>> Just sayin we should not rely on the scripts being there and mandating
>> their usage.
>> We may want to have a fall back to a known good tested configuration.
> I think I see where you're coming from, but it's already expected that
> you're passing in a good device tree too, so it would be making sure
> that you also have a useful env file to get loaded in the DHCP or PXE
> case.
>

Do we have a directory where default scripts exist for each board?  Or at least samples for each board?

I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory

Maybe this would be something that helps defined the known good config that the community can base their changes on.

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/19/2014 12:24 PM, Dan Murphy wrote:
...
> Do we have a directory where default scripts exist for each board?  Or at least samples for each board?
> 
> I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
> 
> Maybe this would be something that helps defined the known good config that the community can base their changes on.

For Tegra, I have created:

https://github.com/NVIDIA/tegra-uboot-scripts

I imagine those scripts would work on most boards that use the U-Boot
config in this patch series. I've certainly used almost identical
scripts on the Raspberry Pi.

I should perhaps put an example extlinux.conf into that repo too.

I imagine (well, it's pretty much the whole point) that distro
installers (e.g. Anaconda) will soon (or already do) support spitting
out extlinux.conf that'll work on ARM U-Boot too.

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dan Murphy]

Stephen

On 02/19/2014 01:29 PM, Stephen Warren wrote:
> On 02/19/2014 12:24 PM, Dan Murphy wrote:
> ...
>> Do we have a directory where default scripts exist for each board?  Or at least samples for each board?
>>
>> I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
>>
>> Maybe this would be something that helps defined the known good config that the community can base their changes on.
> For Tegra, I have created:
>
> https://github.com/NVIDIA/tegra-uboot-scripts
>
> I imagine those scripts would work on most boards that use the U-Boot
> config in this patch series. I've certainly used almost identical
> scripts on the Raspberry Pi.
>
> I should perhaps put an example extlinux.conf into that repo too.
>
> I imagine (well, it's pretty much the whole point) that distro
> installers (e.g. Anaconda) will soon (or already do) support spitting
> out extlinux.conf that'll work on ARM U-Boot too.

That's nice!  Real time script building if you can find the repo you pointed to.

But I was looking for something that was in tree though as a default.  Then maybe overridden by a board uEnv.txt file.

Just something that can be used to get a basic boot from whatever the board manufacturer wants to make their default
storage.

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Wed, Feb 19, 2014 at 01:37:24PM -0600, Dan Murphy wrote:
> Stephen
> 
> On 02/19/2014 01:29 PM, Stephen Warren wrote:
> > On 02/19/2014 12:24 PM, Dan Murphy wrote:
> > ...
> >> Do we have a directory where default scripts exist for each board?  Or at least samples for each board?
> >>
> >> I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
> >>
> >> Maybe this would be something that helps defined the known good config that the community can base their changes on.
> > For Tegra, I have created:
> >
> > https://github.com/NVIDIA/tegra-uboot-scripts
> >
> > I imagine those scripts would work on most boards that use the U-Boot
> > config in this patch series. I've certainly used almost identical
> > scripts on the Raspberry Pi.
> >
> > I should perhaps put an example extlinux.conf into that repo too.
> >
> > I imagine (well, it's pretty much the whole point) that distro
> > installers (e.g. Anaconda) will soon (or already do) support spitting
> > out extlinux.conf that'll work on ARM U-Boot too.
> 
> That's nice!  Real time script building if you can find the repo you pointed to.
> 
> But I was looking for something that was in tree though as a default.  Then maybe overridden by a board uEnv.txt file.
> 
> Just something that can be used to get a basic boot from whatever the board manufacturer wants to make their default
> storage.

Yes, for the next go-round we need examples too perhaps, either directly
or at least mentioned in board/.../README

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/0d917d7c/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote:
> On 02/19/2014 12:24 PM, Dan Murphy wrote:
> ...
> > Do we have a directory where default scripts exist for each board?  Or at least samples for each board?
> > 
> > I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
> > 
> > Maybe this would be something that helps defined the known good config that the community can base their changes on.
> 
> For Tegra, I have created:
> 
> https://github.com/NVIDIA/tegra-uboot-scripts
> 
> I imagine those scripts would work on most boards that use the U-Boot
> config in this patch series. I've certainly used almost identical
> scripts on the Raspberry Pi.
> 
> I should perhaps put an example extlinux.conf into that repo too.
> 
> I imagine (well, it's pretty much the whole point) that distro
> installers (e.g. Anaconda) will soon (or already do) support spitting
> out extlinux.conf that'll work on ARM U-Boot too.

Hey Otavio, is OpenEmbedded doing this yet?  I know there's
syslinux.conf support in since ages ago...

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/220c9565/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Denys Dmytriyenko]

On Wed, Feb 19, 2014 at 02:41:31PM -0500, Tom Rini wrote:
> On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote:
> > On 02/19/2014 12:24 PM, Dan Murphy wrote:
> > ...
> > > Do we have a directory where default scripts exist for each board?  Or 
> > > at least samples for each board?
> > > 
> > > I could not find them.  If they don't exist then we should probably put 
> > > them in the board dirs and cp them to the respective out directory
> > > 
> > > Maybe this would be something that helps defined the known good config 
> > > that the community can base their changes on.
> > 
> > For Tegra, I have created:
> > 
> > https://github.com/NVIDIA/tegra-uboot-scripts
> > 
> > I imagine those scripts would work on most boards that use the U-Boot
> > config in this patch series. I've certainly used almost identical
> > scripts on the Raspberry Pi.
> > 
> > I should perhaps put an example extlinux.conf into that repo too.
> > 
> > I imagine (well, it's pretty much the whole point) that distro
> > installers (e.g. Anaconda) will soon (or already do) support spitting
> > out extlinux.conf that'll work on ARM U-Boot too.
> 
> Hey Otavio, is OpenEmbedded doing this yet?  I know there's
> syslinux.conf support in since ages ago...

It certainly is possible to do the same in OE. The process wasn't unified 
enough across the platforms in order to do that, though...

-- 
Denys

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Otavio Salvador]

Hello Tom,

On Wed, Feb 19, 2014 at 4:41 PM, Tom Rini <trini@ti.com> wrote:
> On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote:
>> On 02/19/2014 12:24 PM, Dan Murphy wrote:
>> ...
>> > Do we have a directory where default scripts exist for each board?  Or at least samples for each board?
>> >
>> > I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
>> >
>> > Maybe this would be something that helps defined the known good config that the community can base their changes on.
>>
>> For Tegra, I have created:
>>
>> https://github.com/NVIDIA/tegra-uboot-scripts
>>
>> I imagine those scripts would work on most boards that use the U-Boot
>> config in this patch series. I've certainly used almost identical
>> scripts on the Raspberry Pi.
>>
>> I should perhaps put an example extlinux.conf into that repo too.
>>
>> I imagine (well, it's pretty much the whole point) that distro
>> installers (e.g. Anaconda) will soon (or already do) support spitting
>> out extlinux.conf that'll work on ARM U-Boot too.
>
> Hey Otavio, is OpenEmbedded doing this yet?  I know there's
> syslinux.conf support in since ages ago...

As Denys said it is not yet supported but should be easily doable. :-)

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

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Tom Rini]

On Thu, Feb 20, 2014 at 09:31:36AM -0300, Otavio Salvador wrote:
> Hello Tom,
> 
> On Wed, Feb 19, 2014 at 4:41 PM, Tom Rini <trini@ti.com> wrote:
> > On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote:
> >> On 02/19/2014 12:24 PM, Dan Murphy wrote:
> >> ...
> >> > Do we have a directory where default scripts exist for each board?  Or at least samples for each board?
> >> >
> >> > I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
> >> >
> >> > Maybe this would be something that helps defined the known good config that the community can base their changes on.
> >>
> >> For Tegra, I have created:
> >>
> >> https://github.com/NVIDIA/tegra-uboot-scripts
> >>
> >> I imagine those scripts would work on most boards that use the U-Boot
> >> config in this patch series. I've certainly used almost identical
> >> scripts on the Raspberry Pi.
> >>
> >> I should perhaps put an example extlinux.conf into that repo too.
> >>
> >> I imagine (well, it's pretty much the whole point) that distro
> >> installers (e.g. Anaconda) will soon (or already do) support spitting
> >> out extlinux.conf that'll work on ARM U-Boot too.
> >
> > Hey Otavio, is OpenEmbedded doing this yet?  I know there's
> > syslinux.conf support in since ages ago...
> 
> As Denys said it is not yet supported but should be easily doable. :-)

Well, can I suggest / beg that we get started? :)  I'd love to see OE be
ready when this is out in the next release.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140220/d7995586/attachment.pgp>

[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Otavio Salvador]

Hello Tom,

On Thu, Feb 20, 2014 at 10:46 AM, Tom Rini <trini@ti.com> wrote:
> On Thu, Feb 20, 2014 at 09:31:36AM -0300, Otavio Salvador wrote:
>> Hello Tom,
>>
>> On Wed, Feb 19, 2014 at 4:41 PM, Tom Rini <trini@ti.com> wrote:
>> > On Wed, Feb 19, 2014 at 12:29:19PM -0700, Stephen Warren wrote:
>> >> On 02/19/2014 12:24 PM, Dan Murphy wrote:
>> >> ...
>> >> > Do we have a directory where default scripts exist for each board?  Or at least samples for each board?
>> >> >
>> >> > I could not find them.  If they don't exist then we should probably put them in the board dirs and cp them to the respective out directory
>> >> >
>> >> > Maybe this would be something that helps defined the known good config that the community can base their changes on.
>> >>
>> >> For Tegra, I have created:
>> >>
>> >> https://github.com/NVIDIA/tegra-uboot-scripts
>> >>
>> >> I imagine those scripts would work on most boards that use the U-Boot
>> >> config in this patch series. I've certainly used almost identical
>> >> scripts on the Raspberry Pi.
>> >>
>> >> I should perhaps put an example extlinux.conf into that repo too.
>> >>
>> >> I imagine (well, it's pretty much the whole point) that distro
>> >> installers (e.g. Anaconda) will soon (or already do) support spitting
>> >> out extlinux.conf that'll work on ARM U-Boot too.
>> >
>> > Hey Otavio, is OpenEmbedded doing this yet?  I know there's
>> > syslinux.conf support in since ages ago...
>>
>> As Denys said it is not yet supported but should be easily doable. :-)
>
> Well, can I suggest / beg that we get started? :)  I'd love to see OE be
> ready when this is out in the next release.

Yes; I will start looking how to integrate it.

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

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Dennis Gilmore]

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 include/configs/am335x_evm.h      | 109 ++++----------------------------------
 include/configs/ti_armv7_common.h |  28 ++--------
 2 files changed, 16 insertions(+), 121 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 73a9adb..b7dcb42 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -43,9 +43,9 @@
 	"nandrootfstype=ubifs rootwait=1\0" \
 	"nandboot=echo Booting from nand ...; " \
 		"run nandargs; " \
-		"nand read ${fdtaddr} u-boot-spl-os; " \
+		"nand read ${fdt_addr} u-boot-spl-os; " \
 		"nand read ${loadaddr} kernel; " \
-		"bootz ${loadaddr} - ${fdtaddr}\0"
+		"bootz ${loadaddr} - ${fdt_addr}\0"
 #else
 #define NANDARGS ""
 #endif
@@ -55,98 +55,13 @@
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	"loadaddr=0x80200000\0" \
-	"fdtaddr=0x80F80000\0" \
+	"fdt_addr=0x80F80000\0" \
+	"fdt_addr_r=0x80F80000\0" \
 	"fdt_high=0xffffffff\0" \
-	"boot_fdt=try\0" \
-	"rdaddr=0x81000000\0" \
-	"bootpart=0:2\0" \
-	"bootdir=/boot\0" \
-	"bootfile=zImage\0" \
-	"fdtfile=undefined\0" \
-	"console=ttyO0,115200n8\0" \
-	"optargs=\0" \
-	"mmcdev=0\0" \
-	"mmcroot=/dev/mmcblk0p2 ro\0" \
-	"mmcrootfstype=ext4 rootwait\0" \
-	"rootpath=/export/rootfs\0" \
-	"nfsopts=nolock\0" \
-	"static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \
-		"::off\0" \
-	"ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \
-	"ramrootfstype=ext2\0" \
-	"mmcargs=setenv bootargs console=${console} " \
-		"${optargs} " \
-		"root=${mmcroot} " \
-		"rootfstype=${mmcrootfstype}\0" \
-	"spiroot=/dev/mtdblock4 rw\0" \
-	"spirootfstype=jffs2\0" \
-	"spisrcaddr=0xe0000\0" \
-	"spiimgsize=0x362000\0" \
-	"spibusno=0\0" \
-	"spiargs=setenv bootargs console=${console} " \
-		"${optargs} " \
-		"root=${spiroot} " \
-		"rootfstype=${spirootfstype}\0" \
-	"netargs=setenv bootargs console=${console} " \
-		"${optargs} " \
-		"root=/dev/nfs " \
-		"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \
-		"ip=dhcp\0" \
-	"bootenv=uEnv.txt\0" \
-	"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
-	"importbootenv=echo Importing environment from mmc ...; " \
-		"env import -t $loadaddr $filesize\0" \
-	"ramargs=setenv bootargs console=${console} " \
-		"${optargs} " \
-		"root=${ramroot} " \
-		"rootfstype=${ramrootfstype}\0" \
-	"loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
-	"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
-	"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
-	"mmcloados=run mmcargs; " \
-		"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-			"if run loadfdt; then " \
-				"bootz ${loadaddr} - ${fdtaddr}; " \
-			"else " \
-				"if test ${boot_fdt} = try; then " \
-					"bootz; " \
-				"else " \
-					"echo WARN: Cannot load the DT; " \
-				"fi; " \
-			"fi; " \
-		"else " \
-			"bootz; " \
-		"fi;\0" \
-	"mmcboot=mmc dev ${mmcdev}; " \
-		"if mmc rescan; then " \
-			"echo SD/MMC found on device ${mmcdev};" \
-			"if run loadbootenv; then " \
-				"echo Loaded environment from ${bootenv};" \
-				"run importbootenv;" \
-			"fi;" \
-			"if test -n $uenvcmd; then " \
-				"echo Running uenvcmd ...;" \
-				"run uenvcmd;" \
-			"fi;" \
-			"if run loadimage; then " \
-				"run mmcloados;" \
-			"fi;" \
-		"fi;\0" \
-	"spiboot=echo Booting from spi ...; " \
-		"run spiargs; " \
-		"sf probe ${spibusno}:0; " \
-		"sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \
-		"bootz ${loadaddr}\0" \
-	"netboot=echo Booting from network ...; " \
-		"setenv autoload no; " \
-		"dhcp; " \
-		"tftp ${loadaddr} ${bootfile}; " \
-		"tftp ${fdtaddr} ${fdtfile}; " \
-		"run netargs; " \
-		"bootz ${loadaddr} - ${fdtaddr}\0" \
-	"ramboot=echo Booting from ramdisk ...; " \
-		"run ramargs; " \
-		"bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \
+	"ramdisk_addr_r=0x81000000\0" \
+	"kernel_addr_r=0x80200000\0" \
+	"pxe_addr_r=0x80000000\0" \
+	"scriptaddr=0x80000000\0" \
 	"findfdt="\
 		"if test $board_name = A335BONE; then " \
 			"setenv fdtfile am335x-bone.dtb; fi; " \
@@ -159,15 +74,13 @@
 		"if test $fdtfile = undefined; then " \
 			"echo WARNING: Could not determine device tree to use; fi; \0" \
 	NANDARGS \
-	DFUARGS
+	DFUARGS \
+	BOOTCMDS_COMMON
 #endif
 
 #define CONFIG_BOOTCOMMAND \
 	"run findfdt; " \
-	"run mmcboot;" \
-	"setenv mmcdev 1; " \
-	"setenv bootpart 1:2; " \
-	"run mmcboot;" \
+	"for target in ${boot_targets}; do run bootcmd_${target}; done" \
 	"run nandboot;"
 
 /* NS16550 Configuration */
diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
index 99b60fc..016966a 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -28,7 +28,6 @@
 #define CONFIG_SYS_NO_FLASH
 
 /* Support both device trees and ATAGs. */
-#define CONFIG_OF_LIBFDT
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
@@ -40,11 +39,6 @@
 #define CONFIG_SYS_LOAD_ADDR		0x80000000
 
 /*
- * Default to a quick boot delay.
- */
-#define CONFIG_BOOTDELAY		1
-
-/*
  * DDR information.  We say (for simplicity) that we have 1 bank,
  * always, even when we have more.  We always start at 0x80000000,
  * and we place the initial stack pointer in our SRAM.
@@ -101,19 +95,12 @@
  * console baudrate of 115200 and use the default baud rate table.
  */
 #define CONFIG_SYS_MALLOC_LEN		(1024 << 10)
-#define CONFIG_SYS_HUSH_PARSER
 #define CONFIG_SYS_PROMPT		"U-Boot# "
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
 #define CONFIG_BAUDRATE			115200
 #define CONFIG_ENV_VARS_UBOOT_CONFIG	/* Strongly encouraged */
 #define CONFIG_ENV_OVERWRITE		/* Overwrite ethaddr / serial# */
 
-/* As stated above, the following choices are optional. */
-#define CONFIG_SYS_LONGHELP
-#define CONFIG_AUTO_COMPLETE
-#define CONFIG_CMDLINE_EDITING
-#define CONFIG_VERSION_VARIABLE
-
 /* We set the max number of command args high to avoid HUSH bugs. */
 #define CONFIG_SYS_MAXARGS		64
 
@@ -146,19 +133,14 @@
 #include <config_cmd_default.h>
 #define CONFIG_CMD_ASKENV
 #define CONFIG_CMD_ECHO
-#define CONFIG_CMD_BOOTZ
 
 /*
- * Common filesystems support.  When we have removable storage we
- * enabled a number of useful commands and support.
+ * Include the generic config options and boot environment when not
+ * building our SPL
  */
-#if defined(CONFIG_MMC) || defined(CONFIG_USB_STORAGE)
-#define CONFIG_DOS_PARTITION
-#define CONFIG_CMD_FAT
-#define CONFIG_FAT_WRITE
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_EXT4
-#define CONFIG_CMD_FS_GENERIC
+#ifndef CONFIG_SPL_BUILD
+#include <config_distro_defaults.h>
+#include <config_distro_bootcmd.h>
 #endif
 
 /*
-- 
1.8.5.3

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Tom Rini]

On Mon, Feb 17, 2014 at 11:56:37AM -0600, Dennis Gilmore wrote:

[snip]
> -		"nand read ${fdtaddr} u-boot-spl-os; " \
> +		"nand read ${fdt_addr} u-boot-spl-os; " \
>  		"nand read ${loadaddr} kernel; " \
> -		"bootz ${loadaddr} - ${fdtaddr}\0"
> +		"bootz ${loadaddr} - ${fdt_addr}\0"

In all of these conversions you should switch loadaddr to kernel_addr_r
too.

[snip]
> -	"fdtfile=undefined\0" \

That's a problem.  Need this for 'findfdt' to work.

> -	"rootpath=/export/rootfs\0" \
> -	"nfsopts=nolock\0" \
> -	"static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \
> -		"::off\0" \
[snip]
> -	"spiroot=/dev/mtdblock4 rw\0" \
> -	"spirootfstype=jffs2\0" \
> -	"spisrcaddr=0xe0000\0" \
> -	"spiimgsize=0x362000\0" \
> -	"spibusno=0\0" \
> -	"spiargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=${spiroot} " \
> -		"rootfstype=${spirootfstype}\0" \
> -	"netargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=/dev/nfs " \
> -		"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \
> -		"ip=dhcp\0" \
[snip]
> -	"spiboot=echo Booting from spi ...; " \
> -		"run spiargs; " \
> -		"sf probe ${spibusno}:0; " \
> -		"sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \
> -		"bootz ${loadaddr}\0" \
> -	"netboot=echo Booting from network ...; " \
> -		"setenv autoload no; " \
> -		"dhcp; " \
> -		"tftp ${loadaddr} ${bootfile}; " \
> -		"tftp ${fdtaddr} ${fdtfile}; " \
> -		"run netargs; " \
> -		"bootz ${loadaddr} - ${fdtaddr}\0" \
> -	"ramboot=echo Booting from ramdisk ...; " \
> -		"run ramargs; " \
> -		"bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \

And this is functionality I don't see in the generic distro config that
we still need.

[snip]
>  /*
> - * Common filesystems support.  When we have removable storage we
> - * enabled a number of useful commands and support.
> + * Include the generic config options and boot environment when not
> + * building our SPL
>   */
> -#if defined(CONFIG_MMC) || defined(CONFIG_USB_STORAGE)
> -#define CONFIG_DOS_PARTITION
> -#define CONFIG_CMD_FAT
> -#define CONFIG_FAT_WRITE
> -#define CONFIG_CMD_EXT2
> -#define CONFIG_CMD_EXT4
> -#define CONFIG_CMD_FS_GENERIC
> +#ifndef CONFIG_SPL_BUILD
> +#include <config_distro_defaults.h>
> +#include <config_distro_bootcmd.h>
>  #endif

This is fine, for now, but I'll have to shuffle things around later as
some of the good feedback I'd gotten off-list about ti_armv7_common.h is
that it's not as useful for non-Linux targets, so I need to adjust the
contents a bit more.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/f3188ae9/attachment.pgp>

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Stephen Warren]

On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>

Patch description?

> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h

>  #define CONFIG_EXTRA_ENV_SETTINGS \
>  	"loadaddr=0x80200000\0" \
> -	"fdtaddr=0x80F80000\0" \
> +	"fdt_addr=0x80F80000\0" \
> +	"fdt_addr_r=0x80F80000\0" \

Why set both? Surely only fdt_addr_r is required/useful?

> -	"mmcroot=/dev/mmcblk0p2 ro\0" \

That implies that rootpart=1 in config_distro_bootcmd.h isn't correct
for this board?

> -	"rootpath=/export/rootfs\0" \
> -	"nfsopts=nolock\0" \
> -	"static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \
> -		"::off\0" \
> -	"ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \
> -	"ramrootfstype=ext2\0" \
> -	"mmcargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=${mmcroot} " \
> -		"rootfstype=${mmcrootfstype}\0" \
> -	"spiroot=/dev/mtdblock4 rw\0" \
> -	"spirootfstype=jffs2\0" \
> -	"spisrcaddr=0xe0000\0" \
> -	"spiimgsize=0x362000\0" \
> -	"spibusno=0\0" \
> -	"spiargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=${spiroot} " \
> -		"rootfstype=${spirootfstype}\0" \
> -	"netargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=/dev/nfs " \
> -		"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \
> -		"ip=dhcp\0" \

I'm not at all familiar with this board, but this seems to be removing
NFS and SPI boot capabilities, maybe others too?

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Dan Murphy]

On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
>  include/configs/am335x_evm.h      | 109 ++++----------------------------------
>  include/configs/ti_armv7_common.h |  28 ++--------
>  2 files changed, 16 insertions(+), 121 deletions(-)
>
> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> index 73a9adb..b7dcb42 100644
> --- a/include/configs/am335x_evm.h
> +++ b/include/configs/am335x_evm.h
> @@ -43,9 +43,9 @@
>  	"nandrootfstype=ubifs rootwait=1\0" \
>  	"nandboot=echo Booting from nand ...; " \
>  		"run nandargs; " \
> -		"nand read ${fdtaddr} u-boot-spl-os; " \
> +		"nand read ${fdt_addr} u-boot-spl-os; " \
>  		"nand read ${loadaddr} kernel; " \
> -		"bootz ${loadaddr} - ${fdtaddr}\0"
> +		"bootz ${loadaddr} - ${fdt_addr}\0"
>  #else
>  #define NANDARGS ""
>  #endif
> @@ -55,98 +55,13 @@
>  #ifndef CONFIG_SPL_BUILD
>  #define CONFIG_EXTRA_ENV_SETTINGS \
>  	"loadaddr=0x80200000\0" \
> -	"fdtaddr=0x80F80000\0" \
> +	"fdt_addr=0x80F80000\0" \
> +	"fdt_addr_r=0x80F80000\0" \
>  	"fdt_high=0xffffffff\0" \
> -	"boot_fdt=try\0" \
> -	"rdaddr=0x81000000\0" \
> -	"bootpart=0:2\0" \
> -	"bootdir=/boot\0" \
> -	"bootfile=zImage\0" \
> -	"fdtfile=undefined\0" \
> -	"console=ttyO0,115200n8\0" \
> -	"optargs=\0" \
> -	"mmcdev=0\0" \
> -	"mmcroot=/dev/mmcblk0p2 ro\0" \
> -	"mmcrootfstype=ext4 rootwait\0" \
> -	"rootpath=/export/rootfs\0" \
> -	"nfsopts=nolock\0" \
> -	"static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}" \
> -		"::off\0" \
> -	"ramroot=/dev/ram0 rw ramdisk_size=65536 initrd=${rdaddr},64M\0" \
> -	"ramrootfstype=ext2\0" \
> -	"mmcargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=${mmcroot} " \
> -		"rootfstype=${mmcrootfstype}\0" \
> -	"spiroot=/dev/mtdblock4 rw\0" \
> -	"spirootfstype=jffs2\0" \
> -	"spisrcaddr=0xe0000\0" \
> -	"spiimgsize=0x362000\0" \
> -	"spibusno=0\0" \
> -	"spiargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=${spiroot} " \
> -		"rootfstype=${spirootfstype}\0" \
> -	"netargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=/dev/nfs " \
> -		"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \
> -		"ip=dhcp\0" \
> -	"bootenv=uEnv.txt\0" \
> -	"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
> -	"importbootenv=echo Importing environment from mmc ...; " \
> -		"env import -t $loadaddr $filesize\0" \
> -	"ramargs=setenv bootargs console=${console} " \
> -		"${optargs} " \
> -		"root=${ramroot} " \
> -		"rootfstype=${ramrootfstype}\0" \
> -	"loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
> -	"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
> -	"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
> -	"mmcloados=run mmcargs; " \
> -		"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
> -			"if run loadfdt; then " \
> -				"bootz ${loadaddr} - ${fdtaddr}; " \
> -			"else " \
> -				"if test ${boot_fdt} = try; then " \
> -					"bootz; " \
> -				"else " \
> -					"echo WARN: Cannot load the DT; " \
> -				"fi; " \
> -			"fi; " \
> -		"else " \
> -			"bootz; " \
> -		"fi;\0" \
> -	"mmcboot=mmc dev ${mmcdev}; " \
> -		"if mmc rescan; then " \
> -			"echo SD/MMC found on device ${mmcdev};" \
> -			"if run loadbootenv; then " \
> -				"echo Loaded environment from ${bootenv};" \
> -				"run importbootenv;" \
> -			"fi;" \
> -			"if test -n $uenvcmd; then " \
> -				"echo Running uenvcmd ...;" \
> -				"run uenvcmd;" \
> -			"fi;" \
> -			"if run loadimage; then " \
> -				"run mmcloados;" \
> -			"fi;" \
> -		"fi;\0" \
> -	"spiboot=echo Booting from spi ...; " \
> -		"run spiargs; " \
> -		"sf probe ${spibusno}:0; " \
> -		"sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \
> -		"bootz ${loadaddr}\0" \
> -	"netboot=echo Booting from network ...; " \
> -		"setenv autoload no; " \
> -		"dhcp; " \
> -		"tftp ${loadaddr} ${bootfile}; " \
> -		"tftp ${fdtaddr} ${fdtfile}; " \
> -		"run netargs; " \
> -		"bootz ${loadaddr} - ${fdtaddr}\0" \
> -	"ramboot=echo Booting from ramdisk ...; " \
> -		"run ramargs; " \
> -		"bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \
> +	"ramdisk_addr_r=0x81000000\0" \
> +	"kernel_addr_r=0x80200000\0" \
> +	"pxe_addr_r=0x80000000\0" \
> +	"scriptaddr=0x80000000\0" \
>  	"findfdt="\
>  		"if test $board_name = A335BONE; then " \
>  			"setenv fdtfile am335x-bone.dtb; fi; " \
> @@ -159,15 +74,13 @@
>  		"if test $fdtfile = undefined; then " \
>  			"echo WARNING: Could not determine device tree to use; fi; \0" \
>  	NANDARGS \
> -	DFUARGS
> +	DFUARGS \
> +	BOOTCMDS_COMMON
>  #endif
>  
>  #define CONFIG_BOOTCOMMAND \
>  	"run findfdt; " \
> -	"run mmcboot;" \
> -	"setenv mmcdev 1; " \
> -	"setenv bootpart 1:2; " \
> -	"run mmcboot;" \
> +	"for target in ${boot_targets}; do run bootcmd_${target}; done" \
>  	"run nandboot;"
>  
>  /* NS16550 Configuration */
> diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
> index 99b60fc..016966a 100644
> --- a/include/configs/ti_armv7_common.h
> +++ b/include/configs/ti_armv7_common.h
> @@ -28,7 +28,6 @@
>  #define CONFIG_SYS_NO_FLASH
>  
>  /* Support both device trees and ATAGs. */
> -#define CONFIG_OF_LIBFDT
>  #define CONFIG_CMDLINE_TAG
>  #define CONFIG_SETUP_MEMORY_TAGS
>  #define CONFIG_INITRD_TAG
> @@ -40,11 +39,6 @@
>  #define CONFIG_SYS_LOAD_ADDR		0x80000000
>  
>  /*
> - * Default to a quick boot delay.
> - */
> -#define CONFIG_BOOTDELAY		1
> -
> -/*
>   * DDR information.  We say (for simplicity) that we have 1 bank,
>   * always, even when we have more.  We always start at 0x80000000,
>   * and we place the initial stack pointer in our SRAM.
> @@ -101,19 +95,12 @@
>   * console baudrate of 115200 and use the default baud rate table.
>   */
>  #define CONFIG_SYS_MALLOC_LEN		(1024 << 10)
> -#define CONFIG_SYS_HUSH_PARSER
>  #define CONFIG_SYS_PROMPT		"U-Boot# "
>  #define CONFIG_SYS_CONSOLE_INFO_QUIET
>  #define CONFIG_BAUDRATE			115200
>  #define CONFIG_ENV_VARS_UBOOT_CONFIG	/* Strongly encouraged */
>  #define CONFIG_ENV_OVERWRITE		/* Overwrite ethaddr / serial# */
>  
> -/* As stated above, the following choices are optional. */
> -#define CONFIG_SYS_LONGHELP
> -#define CONFIG_AUTO_COMPLETE
> -#define CONFIG_CMDLINE_EDITING
> -#define CONFIG_VERSION_VARIABLE
> -
>  /* We set the max number of command args high to avoid HUSH bugs. */
>  #define CONFIG_SYS_MAXARGS		64
>  
> @@ -146,19 +133,14 @@
>  #include <config_cmd_default.h>
>  #define CONFIG_CMD_ASKENV
>  #define CONFIG_CMD_ECHO
> -#define CONFIG_CMD_BOOTZ
>  
>  /*
> - * Common filesystems support.  When we have removable storage we
> - * enabled a number of useful commands and support.
> + * Include the generic config options and boot environment when not
> + * building our SPL
>   */
> -#if defined(CONFIG_MMC) || defined(CONFIG_USB_STORAGE)
> -#define CONFIG_DOS_PARTITION
> -#define CONFIG_CMD_FAT
> -#define CONFIG_FAT_WRITE
> -#define CONFIG_CMD_EXT2
> -#define CONFIG_CMD_EXT4
> -#define CONFIG_CMD_FS_GENERIC
> +#ifndef CONFIG_SPL_BUILD
> +#include <config_distro_defaults.h>

I did not see the patchset for this.

Should this header and the removal the extra configs be a different patch?
Or be part of the series that introduces the distro defaults

> +#include <config_distro_bootcmd.h>
>  #endif
>  
>  /*


-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Dan Murphy]

On 02/19/2014 01:57 PM, Dan Murphy wrote:
> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
Missing commit log as well

>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
>> ---
>>  include/configs/am335x_evm.h      | 109 ++++----------------------------------
>>  include/configs/ti_armv7_common.h |  28 ++--------
>>  2 files changed, 16 insertions(+), 121 deletions(-)
>>
<snip>

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Stephen Warren]

On 02/19/2014 12:57 PM, Dan Murphy wrote:
> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
...
>> +#ifndef CONFIG_SPL_BUILD
>> +#include <config_distro_defaults.h>
> 
> I did not see the patchset for this.
> 
> Should this header and the removal the extra configs be a different patch?
> Or be part of the series that introduces the distro defaults

The following is already in u-boot/master:
13a49c3a739b config: add config_distro_defaults.h

I've sent patches to convert Tegra and RPi to use it, although they
aren't applied yet.

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Dan Murphy]

On 02/19/2014 02:05 PM, Stephen Warren wrote:
> On 02/19/2014 12:57 PM, Dan Murphy wrote:
>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
> ...
>>> +#ifndef CONFIG_SPL_BUILD
>>> +#include <config_distro_defaults.h>
>> I did not see the patchset for this.
>>
>> Should this header and the removal the extra configs be a different patch?
>> Or be part of the series that introduces the distro defaults
> The following is already in u-boot/master:
> 13a49c3a739b config: add config_distro_defaults.h
>
> I've sent patches to convert Tegra and RPi to use it, although they
> aren't applied yet.

Great! So why did this change come in as part of the RFC and not a patch for review and merge?

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Stephen Warren]

On 02/19/2014 01:20 PM, Dan Murphy wrote:
> On 02/19/2014 02:05 PM, Stephen Warren wrote:
>> On 02/19/2014 12:57 PM, Dan Murphy wrote:
>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>> ...
>>>> +#ifndef CONFIG_SPL_BUILD
>>>> +#include <config_distro_defaults.h>
>>> I did not see the patchset for this.
>>>
>>> Should this header and the removal the extra configs be a different patch?
>>> Or be part of the series that introduces the distro defaults
>> The following is already in u-boot/master:
>> 13a49c3a739b config: add config_distro_defaults.h
>>
>> I've sent patches to convert Tegra and RPi to use it, although they
>> aren't applied yet.
> 
> Great! So why did this change come in as part of the RFC and not a patch for review and merge?

Because it needed discussion/comments from the owners of the affected
files perhaps?

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Dan Murphy]

On 02/19/2014 02:22 PM, Stephen Warren wrote:
> On 02/19/2014 01:20 PM, Dan Murphy wrote:
>> On 02/19/2014 02:05 PM, Stephen Warren wrote:
>>> On 02/19/2014 12:57 PM, Dan Murphy wrote:
>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>> ...
>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>> +#include <config_distro_defaults.h>
>>>> I did not see the patchset for this.
>>>>
>>>> Should this header and the removal the extra configs be a different patch?
>>>> Or be part of the series that introduces the distro defaults
>>> The following is already in u-boot/master:
>>> 13a49c3a739b config: add config_distro_defaults.h
>>>
>>> I've sent patches to convert Tegra and RPi to use it, although they
>>> aren't applied yet.
>> Great! So why did this change come in as part of the RFC and not a patch for review and merge?
> Because it needed discussion/comments from the owners of the affected
> files perhaps?

Agreed to the discussion/comments.  But this change is not relevant to converting to a common boot right?
And it is kinda buried in this patch and might be over looked.
I guess the same can be said for the wandboard patch.

IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.

Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Stephen Warren]

On 02/19/2014 01:31 PM, Dan Murphy wrote:
> On 02/19/2014 02:22 PM, Stephen Warren wrote:
>> On 02/19/2014 01:20 PM, Dan Murphy wrote:
>>> On 02/19/2014 02:05 PM, Stephen Warren wrote:
>>>> On 02/19/2014 12:57 PM, Dan Murphy wrote:
>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>> ...
>>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>>> +#include <config_distro_defaults.h>
>>>>> I did not see the patchset for this.
>>>>>
>>>>> Should this header and the removal the extra configs be a different patch?
>>>>> Or be part of the series that introduces the distro defaults
>>>> The following is already in u-boot/master:
>>>> 13a49c3a739b config: add config_distro_defaults.h
>>>>
>>>> I've sent patches to convert Tegra and RPi to use it, although they
>>>> aren't applied yet.
>>> Great! So why did this change come in as part of the RFC and not a patch for review and merge?
>> Because it needed discussion/comments from the owners of the affected
>> files perhaps?
> 
> Agreed to the discussion/comments.  But this change is not relevant to converting to a common boot right?
> And it is kinda buried in this patch and might be over looked.
> I guess the same can be said for the wandboard patch.
> 
> IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.

??? The whole point of this series is to convert the 2 boards to use the
two headers that define a standardized set of U-Boot options (the header
for which has already been merged) and a standardized set of U-Boot
scripts (the header for which is part of this patch series). Splitting
them up makes no sense at all.

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Dan Murphy]

On 02/19/2014 02:38 PM, Stephen Warren wrote:
> On 02/19/2014 01:31 PM, Dan Murphy wrote:
>> On 02/19/2014 02:22 PM, Stephen Warren wrote:
>>> On 02/19/2014 01:20 PM, Dan Murphy wrote:
>>>> On 02/19/2014 02:05 PM, Stephen Warren wrote:
>>>>> On 02/19/2014 12:57 PM, Dan Murphy wrote:
>>>>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
>>>>> ...
>>>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>>>> +#include <config_distro_defaults.h>
>>>>>> I did not see the patchset for this.
>>>>>>
>>>>>> Should this header and the removal the extra configs be a different patch?
>>>>>> Or be part of the series that introduces the distro defaults
>>>>> The following is already in u-boot/master:
>>>>> 13a49c3a739b config: add config_distro_defaults.h
>>>>>
>>>>> I've sent patches to convert Tegra and RPi to use it, although they
>>>>> aren't applied yet.
>>>> Great! So why did this change come in as part of the RFC and not a patch for review and merge?
>>> Because it needed discussion/comments from the owners of the affected
>>> files perhaps?
>> Agreed to the discussion/comments.  But this change is not relevant to converting to a common boot right?
>> And it is kinda buried in this patch and might be over looked.
>> I guess the same can be said for the wandboard patch.
>>
>> IMHO These changes should be broken out, reviewed then they can be merged quicker if not part of this RFC.
> ??? The whole point of this series is to convert the 2 boards to use the
> two headers that define a standardized set of U-Boot options (the header
> for which has already been merged) and a standardized set of U-Boot
> scripts (the header for which is part of this patch series). Splitting
> them up makes no sense at all.

Hey it was just my opinion. (I just like functional changes broken out for bissectability when debugging issues)

But that is ultimately up to the maintainer to decide in the end.
I will attempt to review it when it comes in as an official patchset.


Dan

-- 
------------------
Dan Murphy

[U-Boot] [RFC PATCH 2/3] move the beaglebones over to the generic configs

[Dennis Gilmore]

On Wed, 19 Feb 2014 14:31:42 -0600
Dan Murphy <dmurphy@ti.com> wrote:

> On 02/19/2014 02:22 PM, Stephen Warren wrote:
> > On 02/19/2014 01:20 PM, Dan Murphy wrote:
> >> On 02/19/2014 02:05 PM, Stephen Warren wrote:
> >>> On 02/19/2014 12:57 PM, Dan Murphy wrote:
> >>>> On 02/17/2014 11:56 AM, Dennis Gilmore wrote:
> >>> ...
> >>>>> +#ifndef CONFIG_SPL_BUILD
> >>>>> +#include <config_distro_defaults.h>
> >>>> I did not see the patchset for this.
> >>>>
> >>>> Should this header and the removal the extra configs be a
> >>>> different patch? Or be part of the series that introduces the
> >>>> distro defaults
> >>> The following is already in u-boot/master:
> >>> 13a49c3a739b config: add config_distro_defaults.h
> >>>
> >>> I've sent patches to convert Tegra and RPi to use it, although
> >>> they aren't applied yet.
> >> Great! So why did this change come in as part of the RFC and not a
> >> patch for review and merge?
> > Because it needed discussion/comments from the owners of the
> > affected files perhaps?
> 
> Agreed to the discussion/comments.  But this change is not relevant
> to converting to a common boot right? And it is kinda buried in this
> patch and might be over looked. I guess the same can be said for the
> wandboard patch.
> 
> IMHO These changes should be broken out, reviewed then they can be
> merged quicker if not part of this RFC.

The main point of them and why I sent them as a RFC is that I felt they
provided a solid basis and example of how we can share configs and boot
logic across soc families. there is a lot of room for improvement
still, putting soc family memory locations into their own files for
example. I wanted to judge the acceptance of the idea, There was a
thread looking to unify i.MX last week. I would like tegra to drop
some of the logic carried in configs/tegra-common-post.h and include
config_distro_bootcmd.h instead. I chose these two boards because I
have and can test them, I would like for all boards that would like a
generic distro to run on them to support a standard environment where
adding support for a new board is a much simpler process. 

I really like Stephen's idea of making boot ordering being bios like in
being able to re-order, enable disable, chose a one off boot target. I
would like to get to the point that the pxe/extlinux option shows a menu
where you select a kernel with up/down keys and can even edit the boot
args on the fly, rather than todays choose 1, 2, or 3, etc to pick the
kernel to boot.

Right now I am just trying to take small steps to make things simpler
for everyone. I would like to think that the chosen settings will work
for everyone, but if you're making a specialised product then you can
implement only the bits you need in order to make the boot more
streamlined.

Dennis

[U-Boot] [RFC PATCH 3/3] move wandboard over to use the generic distro configuratin and environment

[Dennis Gilmore]

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 include/configs/wandboard.h | 87 +++++++--------------------------------------
 1 file changed, 12 insertions(+), 75 deletions(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 3488472..bb7aadd 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -41,6 +41,11 @@
 #define CONFIG_CONS_INDEX		1
 #define CONFIG_BAUDRATE			115200
 
+#ifndef CONFIG_SPL_BUILD
+#include <config_distro_defaults.h>
+#include <config_distro_bootcmd.h>
+#endif
+
 /* Command definition */
 #include <config_cmd_default.h>
 
@@ -49,8 +54,6 @@
 #define CONFIG_CMD_BMODE
 #define CONFIG_CMD_SETEXPR
 
-#define CONFIG_BOOTDELAY		5
-
 #define CONFIG_SYS_MEMTEST_START	0x10000000
 #define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)
 #define CONFIG_LOADADDR			0x12000000
@@ -66,15 +69,8 @@
 #define CONFIG_CMD_MMC
 #define CONFIG_GENERIC_MMC
 #define CONFIG_BOUNCE_BUFFER
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_FAT
-#define CONFIG_DOS_PARTITION
 
 /* Ethernet Configuration */
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_MII
-#define CONFIG_CMD_NET
 #define CONFIG_FEC_MXC
 #define CONFIG_MII
 #define IMX_FEC_BASE			ENET_BASE_ADDR
@@ -114,8 +110,12 @@
 	"fdt_high=0xffffffff\0" \
 	"initrd_high=0xffffffff\0" \
 	"fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
-	"fdt_addr=0x18000000\0" \
+	"fdt_addr_r=0x18000000\0" \
 	"boot_fdt=try\0" \
+	"pxefile_addr_r=0x17e00000\0" \
+	"scriptaddr=0x17d00000\0" \
+	"kernel_addr_r=0x13000000\0" \
+	"ramdisk_addr_r=0x15000000\0" \
 	"ip_dyn=yes\0" \
 	"mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
 	"mmcpart=1\0" \
@@ -134,70 +134,12 @@
 				"mmc write ${loadaddr} 0x2 ${fw_sz}; " \
 			"fi; "	\
 		"fi\0" \
-	"mmcargs=setenv bootargs console=${console},${baudrate} " \
-		"root=${mmcroot}\0" \
-	"loadbootscript=" \
-		"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-	"bootscript=echo Running bootscript from mmc ...; " \
-		"source\0" \
-	"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-	"loadfdt=fatload 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 " \
-			"if run loadfdt; then " \
-				"bootz ${loadaddr} - ${fdt_addr}; " \
-			"else " \
-				"if test ${boot_fdt} = try; then " \
-					"bootz; " \
-				"else " \
-					"echo WARN: Cannot load the DT; " \
-				"fi; " \
-			"fi; " \
-		"else " \
-			"bootz; " \
-		"fi;\0" \
-	"netargs=setenv bootargs console=${console},${baudrate} " \
-		"root=/dev/nfs " \
-	"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-		"netboot=echo Booting from net ...; " \
-		"run netargs; " \
-		"if test ${ip_dyn} = yes; then " \
-			"setenv get_cmd dhcp; " \
-		"else " \
-			"setenv get_cmd tftp; " \
-		"fi; " \
-		"${get_cmd} ${image}; " \
-		"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-			"if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
-				"bootz ${loadaddr} - ${fdt_addr}; " \
-			"else " \
-				"if test ${boot_fdt} = try; then " \
-					"bootz; " \
-				"else " \
-					"echo WARN: Cannot load the DT; " \
-				"fi; " \
-			"fi; " \
-		"else " \
-			"bootz; " \
-		"fi;\0"
+	BOOTCMDS_COMMON
 
 #define CONFIG_BOOTCOMMAND \
-	   "mmc dev ${mmcdev}; if mmc rescan; then " \
-		   "if run loadbootscript; then " \
-			   "run bootscript; " \
-		   "else " \
-			   "if run loadimage; then " \
-				   "run mmcboot; " \
-			   "else run netboot; " \
-			   "fi; " \
-		   "fi; " \
-	   "else run netboot; fi"
+	"for target in ${boot_targets}; do run bootcmd_${target}; done"
 
 /* Miscellaneous configurable options */
-#define CONFIG_SYS_LONGHELP
-#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_AUTO_COMPLETE
 #define CONFIG_SYS_CBSIZE		256
 
 /* Print Buffer Size */
@@ -207,8 +149,6 @@
 
 #define CONFIG_SYS_LOAD_ADDR		CONFIG_LOADADDR
 
-#define CONFIG_CMDLINE_EDITING
-
 /* Physical Memory Map */
 #define CONFIG_NR_DRAM_BANKS		1
 #define PHYS_SDRAM			MMDC0_ARB_BASE_ADDR
@@ -231,9 +171,6 @@
 #define CONFIG_ENV_OFFSET		(6 * 64 * 1024)
 #define CONFIG_SYS_MMC_ENV_DEV		0
 
-#define CONFIG_OF_LIBFDT
-#define CONFIG_CMD_BOOTZ
-
 #ifndef CONFIG_SYS_DCACHE_OFF
 #define CONFIG_CMD_CACHE
 #endif
-- 
1.8.5.3

[U-Boot] [RFC PATCH 3/3] move wandboard over to use the generic distro configuratin and environment

[Otavio Salvador]

Hello Dennis,

the short log should use the standard for the commit logs.

On Mon, Feb 17, 2014 at 2:56 PM, Dennis Gilmore <dennis@ausil.us> wrote:
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
>  include/configs/wandboard.h | 87 +++++++--------------------------------------
>  1 file changed, 12 insertions(+), 75 deletions(-)
>
> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
> index 3488472..bb7aadd 100644
> --- a/include/configs/wandboard.h
> +++ b/include/configs/wandboard.h
> @@ -41,6 +41,11 @@
>  #define CONFIG_CONS_INDEX              1
>  #define CONFIG_BAUDRATE                        115200
>
> +#ifndef CONFIG_SPL_BUILD
> +#include <config_distro_defaults.h>
> +#include <config_distro_bootcmd.h>
> +#endif
> +
>  /* Command definition */
>  #include <config_cmd_default.h>
>
> @@ -49,8 +54,6 @@
>  #define CONFIG_CMD_BMODE
>  #define CONFIG_CMD_SETEXPR
>
> -#define CONFIG_BOOTDELAY               5
> -
>  #define CONFIG_SYS_MEMTEST_START       0x10000000
>  #define CONFIG_SYS_MEMTEST_END         (CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)
>  #define CONFIG_LOADADDR                        0x12000000
> @@ -66,15 +69,8 @@
>  #define CONFIG_CMD_MMC
>  #define CONFIG_GENERIC_MMC
>  #define CONFIG_BOUNCE_BUFFER
> -#define CONFIG_CMD_EXT2
> -#define CONFIG_CMD_FAT
> -#define CONFIG_DOS_PARTITION
>
>  /* Ethernet Configuration */
> -#define CONFIG_CMD_PING
> -#define CONFIG_CMD_DHCP
> -#define CONFIG_CMD_MII
> -#define CONFIG_CMD_NET
>  #define CONFIG_FEC_MXC
>  #define CONFIG_MII
>  #define IMX_FEC_BASE                   ENET_BASE_ADDR
> @@ -114,8 +110,12 @@
>         "fdt_high=0xffffffff\0" \
>         "initrd_high=0xffffffff\0" \
>         "fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
> -       "fdt_addr=0x18000000\0" \
> +       "fdt_addr_r=0x18000000\0" \
>         "boot_fdt=try\0" \
> +       "pxefile_addr_r=0x17e00000\0" \
> +       "scriptaddr=0x17d00000\0" \
> +       "kernel_addr_r=0x13000000\0" \
> +       "ramdisk_addr_r=0x15000000\0" \

At least the address that are common to SoCs shouldn't be duplicated
here, do it?

>         "ip_dyn=yes\0" \
>         "mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
>         "mmcpart=1\0" \
> @@ -134,70 +134,12 @@
>                                 "mmc write ${loadaddr} 0x2 ${fw_sz}; " \
>                         "fi; "  \
>                 "fi\0" \
> -       "mmcargs=setenv bootargs console=${console},${baudrate} " \
> -               "root=${mmcroot}\0" \
> -       "loadbootscript=" \
> -               "fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
> -       "bootscript=echo Running bootscript from mmc ...; " \
> -               "source\0" \
> -       "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
> -       "loadfdt=fatload 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 " \
> -                       "if run loadfdt; then " \
> -                               "bootz ${loadaddr} - ${fdt_addr}; " \
> -                       "else " \
> -                               "if test ${boot_fdt} = try; then " \
> -                                       "bootz; " \
> -                               "else " \
> -                                       "echo WARN: Cannot load the DT; " \
> -                               "fi; " \
> -                       "fi; " \
> -               "else " \
> -                       "bootz; " \
> -               "fi;\0" \
> -       "netargs=setenv bootargs console=${console},${baudrate} " \
> -               "root=/dev/nfs " \
> -       "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> -               "netboot=echo Booting from net ...; " \
> -               "run netargs; " \
> -               "if test ${ip_dyn} = yes; then " \
> -                       "setenv get_cmd dhcp; " \
> -               "else " \
> -                       "setenv get_cmd tftp; " \
> -               "fi; " \
> -               "${get_cmd} ${image}; " \
> -               "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
> -                       "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
> -                               "bootz ${loadaddr} - ${fdt_addr}; " \
> -                       "else " \
> -                               "if test ${boot_fdt} = try; then " \
> -                                       "bootz; " \
> -                               "else " \
> -                                       "echo WARN: Cannot load the DT; " \
> -                               "fi; " \
> -                       "fi; " \
> -               "else " \
> -                       "bootz; " \
> -               "fi;\0"
> +       BOOTCMDS_COMMON
>
>  #define CONFIG_BOOTCOMMAND \
> -          "mmc dev ${mmcdev}; if mmc rescan; then " \
> -                  "if run loadbootscript; then " \
> -                          "run bootscript; " \
> -                  "else " \
> -                          "if run loadimage; then " \
> -                                  "run mmcboot; " \
> -                          "else run netboot; " \
> -                          "fi; " \
> -                  "fi; " \
> -          "else run netboot; fi"
> +       "for target in ${boot_targets}; do run bootcmd_${target}; done"
>
>  /* Miscellaneous configurable options */
> -#define CONFIG_SYS_LONGHELP
> -#define CONFIG_SYS_HUSH_PARSER
> -#define CONFIG_AUTO_COMPLETE
>  #define CONFIG_SYS_CBSIZE              256
>
>  /* Print Buffer Size */
> @@ -207,8 +149,6 @@
>
>  #define CONFIG_SYS_LOAD_ADDR           CONFIG_LOADADDR
>
> -#define CONFIG_CMDLINE_EDITING
> -
>  /* Physical Memory Map */
>  #define CONFIG_NR_DRAM_BANKS           1
>  #define PHYS_SDRAM                     MMDC0_ARB_BASE_ADDR
> @@ -231,9 +171,6 @@
>  #define CONFIG_ENV_OFFSET              (6 * 64 * 1024)
>  #define CONFIG_SYS_MMC_ENV_DEV         0
>
> -#define CONFIG_OF_LIBFDT
> -#define CONFIG_CMD_BOOTZ
> -
>  #ifndef CONFIG_SYS_DCACHE_OFF
>  #define CONFIG_CMD_CACHE
>  #endif
> --
> 1.8.5.3
>



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

[U-Boot] [RFC PATCH 3/3] move wandboard over to use the generic distro configuratin and environment

[Stephen Warren]

On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>

> diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h

> -	"netargs=setenv bootargs console=${console},${baudrate} " \
> -		"root=/dev/nfs " \
> -	"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> -		"netboot=echo Booting from net ...; " \
> -		"run netargs; " \
> -		"if test ${ip_dyn} = yes; then " \
> -			"setenv get_cmd dhcp; " \
> -		"else " \
> -			"setenv get_cmd tftp; " \
...

This one also removes nfsroot stuff.

Admittedly I would personally argue that nfsroot setup belong in the
boot.scr that comes from some TFTP server, and I wrote the Tegra boot
scripts assuming that, but I probably got away with that for Tegra since
we never had any nfsroot setup in the default environment. People using
these boards might like to keep their working features:-) Perhaps we
could persuade people to adapt though?

[U-Boot] RFC unified boot environment

[Stefano Babic]

Hi Dennis,

On 17/02/2014 18:56, Dennis Gilmore wrote:
> Hi All,
> 
> The attached patches build on the work for generic distro config, as well as
> Stephen Warrens implementation for tegra.
> 

First, thanks to make order on this issue.

> I have added a header to be included that will allow all boards to boot in the
> same way and I have ported over two boards to use it. One thought I have had
> is to move the environment into the same header as the generic config. 

I think this is currently the best solution.

> 
> I am also working on writing a README.distro file to document everything that
> needs to be set for everything to just work. Along with information on how to
> best choose memory locations. 


Ok, let's see. This seems quite board-depending, I do not know if we
find a common solution. But we can find an agreement about a generic set
of variables/scripts, that all boards can reuse.

Regards,
Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] RFC unified boot environment

[Dennis Gilmore]

On Tue, 18 Feb 2014 11:18:22 +0100
Stefano Babic <sbabic@denx.de> wrote:

> Hi Dennis,
> 
> On 17/02/2014 18:56, Dennis Gilmore wrote:
> > Hi All,
> > 
> > The attached patches build on the work for generic distro config,
> > as well as Stephen Warrens implementation for tegra.
> > 
> 
> First, thanks to make order on this issue.
> 
> > I have added a header to be included that will allow all boards to
> > boot in the same way and I have ported over two boards to use it.
> > One thought I have had is to move the environment into the same
> > header as the generic config. 
> 
> I think this is currently the best solution.
> 
> > 
> > I am also working on writing a README.distro file to document
> > everything that needs to be set for everything to just work. Along
> > with information on how to best choose memory locations. 
> 
> 
> Ok, let's see. This seems quite board-depending, I do not know if we
> find a common solution. But we can find an agreement about a generic
> set of variables/scripts, that all boards can reuse.

There will always be some board specific things like memory locations
etc. None of the boot logic is board specific. Some features are
hardware specific, i.e. PXE boot support is only configured if the
hardware supports it same for SATA. 

I'm putting what I have for the documentation so far at the end of this
email. I think that soc families should have a common settings file,
each board should have its on file and then we have a common set of
configurations on how to boot. 

Dennis


/*
 * (C) Copyright 2014 Red Hat Inc.
 *
 * SPDX-License-Identifier:     GPL-2.0+
 */

Generic distro configuration



configuring
-----------
To configure a board to run the generic distro setup and enable generic distros
to easily support your board.


you will need to include a pair of headers to enable the boot environment and
configuration options needed. It is best to only include when not doing an
SPL build.

#ifndef CONFIG_SPL_BUILD
#include <config_distro_defaults.h>
#include <config_distro_bootcmd.h>
#endif

There is some memory addresses you will need to define in
CONFIG_EXTRA_ENV_SETTINGS
fdt_addr:
Optional, if specified a dtb to boot the system needs to be available at the
address.

fdt_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,
using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
config file. The location can be anywhere in ram it just needs to not overlap
with anything, allowing 1 megabyte seems to be a safe option.

ramdisk_addr_r:
Mandatory, This is the location where the sysboot/pxeboot with load the
initramfs to, using the initrd option in the pxe/extlinux config file, the
location of the initramfs does not matter, there needs to be enough room to be
able to store any image. Making the image the last item stored should allow for
any initramfs to fit and not overwrite anything else.

kernel_addr_r:
Mandatory, 

pxe_addr_r:
Mandatory, used by the PXE code to hold the pxelinux config file. The location
can be anywhere in ram it just needs to not overlap with anything, allowing 1 
megabyte seems to be a safe option.

scriptaddr:
Mandatory, 

suggested mapping:
16M 

make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS

booting your system
-------------------
in the most simplest form CONFIG_BOOTCOMMAND just needs one line

"for target in ${boot_targets}; do run bootcmd_${target}; done"

you can run any setup before going through the targets for example run a
command to set "fdtfile" variable for the dtb for your board.

Dennis

[U-Boot] RFC unified boot environment

[Tom Rini]

On Tue, Feb 18, 2014 at 10:09:10AM -0600, Dennis Gilmore wrote:

> I'm putting what I have for the documentation so far at the end of this
> email. I think that soc families should have a common settings file,
> each board should have its on file and then we have a common set of
> configurations on how to boot. 

For the next round, please put this into doc/ as part of the first
patch.  Thanks!

[snip]
> fdt_addr_r:
> Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,
> using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
> config file. The location can be anywhere in ram it just needs to not overlap
> with anything, allowing 1 megabyte seems to be a safe option.
> 
> ramdisk_addr_r:
> Mandatory, This is the location where the sysboot/pxeboot with load the
> initramfs to, using the initrd option in the pxe/extlinux config file, the
> location of the initramfs does not matter, there needs to be enough room to be
> able to store any image. Making the image the last item stored should allow for
> any initramfs to fit and not overwrite anything else.
> 
> kernel_addr_r:
> Mandatory, 
> 
> pxe_addr_r:
> Mandatory, used by the PXE code to hold the pxelinux config file. The location
> can be anywhere in ram it just needs to not overlap with anything, allowing 1 
> megabyte seems to be a safe option.
> 
> scriptaddr:
> Mandatory, 
> 
> suggested mapping:
> 16M 

We need to talk much more about the suggested mapping as there's a few
hard requirements that must be obeyed.  The device tree _must_ be placed
within kernel accessible low mem and not overwritten by zImage
decompression.  A reference to Documentation/arm/Booting in the kernel
would also be helpful and then summarize saying kernel_addr_r should be
above 32MiB and below 128MiB from the base of system ram.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140219/bae05376/attachment.pgp>

[U-Boot] [PATCH 0/6] unified boot environment

[Dennis Gilmore]

Hi All,

The attached patches build on the work for generic distro config, as well as
Stephen Warrens implementation for tegra. They depend on Toms Patches to move
ti to using DEFAULT_LINUX_BOOT_ENV on TI systems.

There is a README file to describe how to convert a system. I have added a
header to be included that will allow all boards to boot in the same way and
I have ported over three boards to use it.

Dennis

[U-Boot] [PATCH 1/6] add README.distro file

[Dennis Gilmore]

Add documentation on how to setup a system to use the generic distro
configs and boot commands. This spells out what is needed to make a
system conformant, but does not limit the board to only the defaults.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 doc/README.distro | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 doc/README.distro

diff --git a/doc/README.distro b/doc/README.distro
new file mode 100644
index 0000000..435c578
--- /dev/null
+++ b/doc/README.distro
@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2014 Red Hat Inc.
+ *
+ * SPDX-License-Identifier:     GPL-2.0+
+ */
+
+Generic distro configuration
+----------------------------
+
+configuring
+-----------
+To configure a board to run the generic distro setup and enable generic distros
+to easily support your board.
+
+you will need to include a pair of headers to enable the boot environment and
+configuration options needed. It is best to only include when not doing an
+SPL build.
+
+#ifndef CONFIG_SPL_BUILD
+#include <config_distro_defaults.h>
+#include <config_distro_bootcmd.h>
+#endif
+
+There is some memory addresses you will need to define in
+CONFIG_EXTRA_ENV_SETTINGS
+fdt_addr:
+Optional, If specified a dtb to boot the system must be available at the given
+address.
+
+fdt_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,
+using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
+config file. The location can be anywhere in ram it just needs to not overlap
+with anything, allowing 1 megabyte seems to be a safe option.
+
+ramdisk_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the
+initramfs to, using the initrd option in the pxe/extlinux config file, the
+location of the initramfs does not matter, there needs to be enough room to be
+able to store any image. Making the image the last item stored should allow for
+any initramfs to fit and not overwrite anything else.
+
+kernel_addr_r:
+Mandatory, This is the location where the sysboot/pxeboot with load the kernel
+to,using the kernel option in the pxe/extlinux config file, the location of the
+kernel needs to 
+
+pxe_addr_r:
+Mandatory, used by the PXE code to hold the pxelinux config file. The location
+can be anywhere in ram it just needs to not overlap with anything, allowing 1 
+megabyte seems to be a safe option.
+
+scriptaddr:
+Mandatory, used to load boot.scr to The location can be anywhere in ram it just
+needs to not overlap with anything, allowing 1 megabyte seems to be a safe
+option.
+
+suggested mapping:
+For suggestions on memory locations for arm systems  you must follow the
+guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
+For other architectures you must follow the guidelines for the architecture.
+
+make sure you also include BOOTCMDS_COMMON in CONFIG_EXTRA_ENV_SETTINGS
+
+You should not set initrd_high and fdt_high to 0xffffffff as the user should
+not need to edit the memory locations having the initramfs and dtb being
+relocatable is best to ensure the system will boot in all situations. 
+
+booting your system
+-------------------
+in the most simplest form CONFIG_BOOTCOMMAND just needs one line
+
+"for target in ${boot_targets}; do run bootcmd_${target}; done "
+
+you can run any setup before going through the targets for example run a
+command to set "fdtfile" variable for the dtb for your board.
-- 
1.9.0

[U-Boot] [PATCH 1/6] add README.distro file

[Tom Rini]

On Thu, Mar 20, 2014 at 05:12:56PM -0500, Dennis Gilmore wrote:

> Add documentation on how to setup a system to use the generic distro
> configs and boot commands. This spells out what is needed to make a
> system conformant, but does not limit the board to only the defaults.
> 
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>

[snip]
> +suggested mapping:
> +For suggestions on memory locations for arm systems  you must follow the
> +guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
> +For other architectures you must follow the guidelines for the architecture.

Can you add something about what this means?  ie below base+128MB for
kernel, because of this if possible base+128MB for fdt, fdt+512KB for
ramdisk. And mention bootm_size to limit the relocation pool as well.  

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/e8ee6215/attachment.pgp>

[U-Boot] [PATCH 1/6] add README.distro file

[Stephen Warren]

On 03/21/2014 12:48 PM, Tom Rini wrote:
> On Thu, Mar 20, 2014 at 05:12:56PM -0500, Dennis Gilmore wrote:
> 
>> Add documentation on how to setup a system to use the generic distro
>> configs and boot commands. This spells out what is needed to make a
>> system conformant, but does not limit the board to only the defaults.
>>
>> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> 
> [snip]
>> +suggested mapping:
>> +For suggestions on memory locations for arm systems  you must follow the
>> +guidelines specified in Documentation/arm/Booting in the Linux kernel tree.
>> +For other architectures you must follow the guidelines for the architecture.
> 
> Can you add something about what this means?  ie below base+128MB for
> kernel, because of this if possible base+128MB for fdt, fdt+512KB for
> ramdisk. And mention bootm_size to limit the relocation pool as well.  

I'm biased, but I like the explanations in
include/configs/tegraNN-common.h:-)

[U-Boot] [PATCH 1/6] add README.distro file

[Stephen Warren]

On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> Add documentation on how to setup a system to use the generic distro
> configs and boot commands. This spells out what is needed to make a
> system conformant, but does not limit the board to only the defaults.

> diff --git a/doc/README.distro b/doc/README.distro

> +There is some memory addresses you will need to define in
> +CONFIG_EXTRA_ENV_SETTINGS
> +fdt_addr:
> +Optional, If specified a dtb to boot the system must be available at the given
> +address.

Perhaps add "when the kernel is booted"? To avoid someone putting it
somewhere that will get over-written between when U-Boot starts and the
kernel is booted.

> +fdt_addr_r:
> +Mandatory, This is the location where the sysboot/pxeboot with load the dtb to,

s/with/will/ Both here and other place(s).

> +using the fdtdir/devicetreedir or fdt/devicetree options in the pxe/extlinux
> +config file. The location can be anywhere in ram it just needs to not overlap
> +with anything, allowing 1 megabyte seems to be a safe option.

Related to Tom's comments, I think saying that the location doesn't
matter isn't quite true. For example, an ARM zImage assumes it's located
with the first 128M of RAM, and will decompress the image to the start
of RAM. If the DTB was located in the decompression target region, it
would at least need to be moved by the decompressor (wasted effort) or
perhaps just get blindly over-written (boot fails).

> +ramdisk_addr_r:
> +Mandatory, This is the location where the sysboot/pxeboot with load the
> +initramfs to, using the initrd option in the pxe/extlinux config file, the
> +location of the initramfs does not matter, there needs to be enough room to be
> +able to store any image. Making the image the last item stored should allow for
> +any initramfs to fit and not overwrite anything else.

"last item" could refer to time not space. Perhaps s/Making the image
the last item stored/Placing the image higher in RAM than any other image/

> +kernel_addr_r:
> +Mandatory, This is the location where the sysboot/pxeboot with load the kernel
> +to,using the kernel option in the pxe/extlinux config file, the location of the
> +kernel needs to 

That sentence isn't complete.

> +You should not set initrd_high and fdt_high to 0xffffffff as the user should
> +not need to edit the memory locations having the initramfs and dtb being
> +relocatable is best to ensure the system will boot in all situations. 

Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
might be useful when writing this part of the document.

> +booting your system
> +-------------------
> +in the most simplest form CONFIG_BOOTCOMMAND just needs one line
> +
> +"for target in ${boot_targets}; do run bootcmd_${target}; done "
> +
> +you can run any setup before going through the targets for example run a
> +command to set "fdtfile" variable for the dtb for your board.

Isn't this automatic based on using config_distro_defaults.h? It seems
like it should be, and it is were, you wouldn't need this section of
this document at all; it's happen automatically.

[U-Boot] [PATCH 1/6] add README.distro file

[Tom Rini]

On Tue, Mar 25, 2014 at 02:24:14PM -0600, Stephen Warren wrote:
> On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
[snip]
> > +You should not set initrd_high and fdt_high to 0xffffffff as the user should
> > +not need to edit the memory locations having the initramfs and dtb being
> > +relocatable is best to ensure the system will boot in all situations. 
> 
> Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
> description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
> might be useful when writing this part of the document.

I would swear (and I just dug up the notes from the last time I was
looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because
it doesn't cover the ramdisk case, which is important for generic
distro, unless you also add in initrd_high=top-of-lowmem-value or know
it'll be in an always-good spot and set it to 0xffffffff.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140328/d3d54d38/attachment.pgp>

[U-Boot] [PATCH 1/6] add README.distro file

[Stephen Warren]

On 03/28/2014 09:42 AM, Tom Rini wrote:
> On Tue, Mar 25, 2014 at 02:24:14PM -0600, Stephen Warren wrote:
>> On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> [snip]
>>> +You should not set initrd_high and fdt_high to 0xffffffff as the user should
>>> +not need to edit the memory locations having the initramfs and dtb being
>>> +relocatable is best to ensure the system will boot in all situations. 
>>
>> Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
>> description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
>> might be useful when writing this part of the document.
> 
> I would swear (and I just dug up the notes from the last time I was
> looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because
> it doesn't cover the ramdisk case, which is important for generic
> distro, unless you also add in initrd_high=top-of-lowmem-value or know
> it'll be in an always-good spot and set it to 0xffffffff.

Isn't that a bug? In other words, shouldn't CONFIG_SYS_BOOTMAPSZ affect
a ramdisk too?

[U-Boot] [PATCH 1/6] add README.distro file

[Tom Rini]

On Fri, Mar 28, 2014 at 10:11:20AM -0600, Stephen Warren wrote:
> On 03/28/2014 09:42 AM, Tom Rini wrote:
> > On Tue, Mar 25, 2014 at 02:24:14PM -0600, Stephen Warren wrote:
> >> On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> > [snip]
> >>> +You should not set initrd_high and fdt_high to 0xffffffff as the user should
> >>> +not need to edit the memory locations having the initramfs and dtb being
> >>> +relocatable is best to ensure the system will boot in all situations. 
> >>
> >> Perhaps CONFIG_SYS_BOOTMAPSZ is worth a mention too. The commit
> >> description for 7f1b767aea94 "ARM: tegra: define CONFIG_SYS_BOOTMAPSZ"
> >> might be useful when writing this part of the document.
> > 
> > I would swear (and I just dug up the notes from the last time I was
> > looking at this) that no, CONFIG_SYS_BOOTMAPSZ is not sufficient because
> > it doesn't cover the ramdisk case, which is important for generic
> > distro, unless you also add in initrd_high=top-of-lowmem-value or know
> > it'll be in an always-good spot and set it to 0xffffffff.
> 
> Isn't that a bug? In other words, shouldn't CONFIG_SYS_BOOTMAPSZ affect
> a ramdisk too?

No, because it's a per-arch thing on if you can have a ramdisk in high
memory or not (and then the kernel deals with it), iirc.  I _think_ this
is one of those cases where ARM is much more strict about things than
other architectures, but I lack the easy access to other platforms that
I used to have.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140328/90355d83/attachment.pgp>

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Dennis Gilmore]

As the next step in a generic config we are introducing a set of generic boot
paramaters. Depending on the hardwares configuration, booting from supported
hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.

There is nothing to stop this being extended to support nand and any other
type of storage that comes along. An ideal future enhancement will be to
allow the user to dynamically reorder the boot devices, and allow one off
boots. for example simply be able to pxe boot to reinstall

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 include/config_distro_bootcmd.h | 208 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 208 insertions(+)
 create mode 100644 include/config_distro_bootcmd.h

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
new file mode 100644
index 0000000..0fe94be
--- /dev/null
+++ b/include/config_distro_bootcmd.h
@@ -0,0 +1,208 @@
+/*
+ * (C) Copyright 2014
+ * NVIDIA Corporation <www.nvidia.com>
+ *  
+ * Copyright 2014 Red Hat, Inc.
+ *
+ * SPDX-License-Identifier:     GPL-2.0+
+ */
+
+#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
+#define _CONFIG_CMD_DISTRO_BOOTCMD_H
+
+
+#ifdef CONFIG_CMD_MMC
+#define BOOTCMDS_MMC \
+	"mmc_boot=" \
+		"setenv devtype mmc; " \
+		"if mmc dev ${devnum}; then " \
+			"run scan_boot; " \
+		"fi\0" \
+	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
+	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
+#define BOOT_TARGETS_MMC "mmc1 mmc0"
+#else
+#define BOOTCMDS_MMC ""
+#define BOOT_TARGETS_MMC ""
+#endif
+
+#ifdef CONFIG_CMD_USB
+#define BOOTCMD_INIT_USB "run usb_init; "
+#define BOOTCMDS_USB \
+	"usb_init=" \
+		"if ${usb_need_init}; then " \
+			"set usb_need_init false; " \
+			"usb start 0; " \
+		"fi\0" \
+	\
+	"usb_boot=" \
+		"setenv devtype usb; " \
+		BOOTCMD_INIT_USB \
+		"if usb dev ${devnum}; then " \
+			"run scan_boot; " \
+		"fi\0" \
+	\
+	"bootcmd_usb0=setenv devnum 0; run usb_boot;\0" \
+	"bootcmd_usb1=setenv devnum 1; run usb_boot;\0"
+#define BOOT_TARGETS_USB "usb0 usb1"
+#else
+#define BOOTCMD_INIT_USB ""
+#define BOOTCMDS_USB ""
+#define BOOT_TARGETS_USB ""
+#endif
+
+#ifdef CONFIG_CMD_SATA
+#define BOOTCMDS_SATA \
+	"sata_boot=" \
+		"setenv devtype sata; " \
+		"if sata dev ${devnum}; then " \
+			"run scan_boot; " \
+		"fi\0" \
+	\
+	"bootcmd_sata0=setenv devnum 0; run sata_boot;\0" \
+	"bootcmd_sata1=setenv devnum 1; run sata_boot;\0"
+#define BOOT_TARGETS_SATA "sata0 sata1"
+#else
+#define BOOTCMDS_SATA ""
+#define BOOT_TARGETS_SATA ""
+#endif
+
+#ifdef CONFIG_CMD_SCSI
+#define BOOTCMDS_SCSI \
+        "scsi_boot=" \
+                "setenv devtype scsi; " \
+                "if scsi dev ${devnum}; then " \
+                        "run scan_boot; " \
+                "fi\0" \
+        \
+        "bootcmd_scsi0=setenv devnum 0; run scsi_boot;\0" \
+        "bootcmd_scsi1=setenv devnum 1; run scsi_boot;\0"
+#define BOOT_TARGETS_SCSI "scsi0 scsi1"
+#else
+#define BOOTCMDS_SCSI ""
+#define BOOT_TARGETS_SCSI ""
+#endif
+
+#ifdef CONFIG_CMD_IDE
+#define BOOTCMDS_IDE \
+        "ide_boot=" \
+                "setenv devtype ide; " \
+                "if ide dev ${devnum}; then " \
+                        "run scan_boot; " \
+                "fi\0" \
+        \
+        "bootcmd_ide0=setenv devnum 0; run ide_boot;\0" \
+        "bootcmd_ide1=setenv devnum 1; run ide_boot;\0"
+#define BOOT_TARGETS_IDE "ide0 ide1"
+#else
+#define BOOTCMDS_IDE ""
+#define BOOT_TARGETS_IDE ""
+#endif
+
+#ifdef CONFIG_CMD_DHCP
+#define BOOTCMDS_DHCP \
+	"bootcmd_dhcp=" \
+		BOOTCMD_INIT_USB \
+		"if dhcp ${scriptaddr} boot.scr.uimg; then "\
+			"source ${scriptaddr}; " \
+		"fi\0"
+#define BOOT_TARGETS_DHCP "dhcp"
+#else
+#define BOOTCMDS_DHCP ""
+#define BOOT_TARGETS_DHCP ""
+#endif
+
+#if defined(CONFIG_CMD_DHCP) && defined(CONFIG_CMD_PXE)
+#define BOOTCMDS_PXE \
+	"bootcmd_pxe=" \
+		BOOTCMD_INIT_USB \
+		"dhcp; " \
+		"if pxe get; then " \
+			"pxe boot; " \
+		"fi\0"
+#define BOOT_TARGETS_PXE "pxe"
+#else
+#define BOOTCMDS_PXE ""
+#define BOOT_TARGETS_PXE ""
+#endif
+
+#define BOOTCMDS_COMMON \
+	"rootpart=1\0" \
+	\
+	"do_envimport="                                                   \
+		"load ${devtype} ${devnum}:${rootpart} ${loadaddr} "      \
+			"${environment}\0"                                \
+		"env import -t ${loadaddr} $filesize\0"                   \
+	\
+	"envimport="                                                      \
+		"for environment in ${boot_envs}; do "                    \
+			"if test -e ${devtype} ${devnum}:${rootpart} "    \
+					"${prefix}${environment}; then "  \
+				"echo Found U-Boot environment "          \
+					"${prefix}${environment}; "       \
+				"run do_envimport;"                       \
+				"echo Import FAILED; continuing...; "     \
+			"fi; "                                            \
+		"done\0"                                                  \
+	\
+	"do_script_boot="                                                 \
+		"load ${devtype} ${devnum}:${rootpart} "                  \
+			"${scriptaddr} ${prefix}${script}; "              \
+		"source ${scriptaddr}\0"                                  \
+	\
+	"script_boot="                                                    \
+		"for script in ${boot_scripts}; do "                      \
+			"if test -e ${devtype} ${devnum}:${rootpart} "    \
+					"${prefix}${script}; then "       \
+				"echo Found U-Boot script "               \
+					"${prefix}${script}; "            \
+				"run do_script_boot;"                     \
+				"echo SCRIPT FAILED; continuing...; "     \
+			"fi; "                                            \
+		"done\0"                                                  \
+	\
+	"do_sysboot_boot="                                                \
+		"sysboot ${devtype} ${devnum}:${rootpart} any "           \
+			"${scriptaddr} ${prefix}extlinux/extlinux.conf\0" \
+	\
+	"sysboot_boot="                                                   \
+		"if test -e ${devtype} ${devnum}:${rootpart} "            \
+				"${prefix}extlinux/extlinux.conf; then "  \
+			"echo Found extlinux config "                     \
+				"${prefix}extlinux/extlinux.conf; "       \
+			"run do_sysboot_boot;"                            \
+			"echo SYSBOOT FAILED; continuing...; "            \
+		"fi\0"                                                    \
+	\
+	"scan_boot="                                                      \
+		"echo Scanning ${devtype} ${devnum}...; "                 \
+		"for prefix in ${boot_prefixes}; do "                     \
+			"run sysboot_boot; "                              \
+			"run script_boot; "                               \
+		"done\0"                                                  \
+	\
+	"boot_targets=" \
+		BOOT_TARGETS_MMC " "  \
+		BOOT_TARGETS_USB " "  \
+		BOOT_TARGETS_SATA " " \
+		BOOT_TARGETS_SCSI " " \
+		BOOT_TARGETS_IDE " "  \
+		BOOT_TARGETS_PXE " "  \
+		BOOT_TARGETS_DHCP " " \
+		"\0" \
+	\
+	"boot_prefixes=/ /boot/\0" \
+	\
+	"boot_scripts=boot.scr.uimg boot.scr\0" \
+	\
+	"boot_envs=uEnv.txt\0" \
+	\
+	BOOTCMDS_MMC \
+	BOOTCMDS_USB \
+	BOOTCMDS_SATA \
+	BOOTCMDS_SCSI \
+	BOOTCMDS_IDE \
+	BOOTCMDS_DHCP \
+	BOOTCMDS_PXE
+
+#endif  /* _CONFIG_CMD_DISTRO_BOOTCMD_H */
-- 
1.9.0

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Marek Vasut]

On Thursday, March 20, 2014 at 11:12:57 PM, Dennis Gilmore wrote:
> As the next step in a generic config we are introducing a set of generic
> boot paramaters. Depending on the hardwares configuration, booting from
> supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and
> dhcp.
> 
> There is nothing to stop this being extended to support nand and any other
> type of storage that comes along. An ideal future enhancement will be to
> allow the user to dynamically reorder the boot devices, and allow one off
> boots. for example simply be able to pxe boot to reinstall
> 
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
>  include/config_distro_bootcmd.h | 208
> ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+)
>  create mode 100644 include/config_distro_bootcmd.h
> 
> diff --git a/include/config_distro_bootcmd.h
> b/include/config_distro_bootcmd.h new file mode 100644
> index 0000000..0fe94be
> --- /dev/null
> +++ b/include/config_distro_bootcmd.h
> @@ -0,0 +1,208 @@
> +/*
> + * (C) Copyright 2014
> + * NVIDIA Corporation <www.nvidia.com>
> + *
> + * Copyright 2014 Red Hat, Inc.
> + *
> + * SPDX-License-Identifier:     GPL-2.0+
> + */
> +
> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> +
> +
> +#ifdef CONFIG_CMD_MMC
> +#define BOOTCMDS_MMC \
> +	"mmc_boot=" \
> +		"setenv devtype mmc; " \

Please use 'env set ...'

> +		"if mmc dev ${devnum}; then " \
> +			"run scan_boot; " \
> +		"fi\0" \
> +	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
> +	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
> +#define BOOT_TARGETS_MMC "mmc1 mmc0"

This will not work on a boot with three MMC cards ... this does not scale and 
needs re-thinking.

> +#else
> +#define BOOTCMDS_MMC ""
> +#define BOOT_TARGETS_MMC ""

You need to #undef those after you assembled the env, otherwise you will 
propagate those throughout the rest of the U-Boot at build time, which is not 
nice.
[...]

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Tom Rini]

On Fri, Mar 21, 2014 at 07:37:52PM +0100, Marek Vasut wrote:
> On Thursday, March 20, 2014 at 11:12:57 PM, Dennis Gilmore wrote:
> > As the next step in a generic config we are introducing a set of generic
> > boot paramaters. Depending on the hardwares configuration, booting from
> > supported hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and
> > dhcp.
> > 
> > There is nothing to stop this being extended to support nand and any other
> > type of storage that comes along. An ideal future enhancement will be to
> > allow the user to dynamically reorder the boot devices, and allow one off
> > boots. for example simply be able to pxe boot to reinstall
> > 
> > Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> > ---
> >  include/config_distro_bootcmd.h | 208
> > ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+)
> >  create mode 100644 include/config_distro_bootcmd.h
> > 
> > diff --git a/include/config_distro_bootcmd.h
> > b/include/config_distro_bootcmd.h new file mode 100644
> > index 0000000..0fe94be
> > --- /dev/null
> > +++ b/include/config_distro_bootcmd.h
> > @@ -0,0 +1,208 @@
> > +/*
> > + * (C) Copyright 2014
> > + * NVIDIA Corporation <www.nvidia.com>
> > + *
> > + * Copyright 2014 Red Hat, Inc.
> > + *
> > + * SPDX-License-Identifier:     GPL-2.0+
> > + */
> > +
> > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> > +
> > +
> > +#ifdef CONFIG_CMD_MMC
> > +#define BOOTCMDS_MMC \
> > +	"mmc_boot=" \
> > +		"setenv devtype mmc; " \
> 
> Please use 'env set ...'

Why?  Almost nothing uses that syntax..

> > +		"if mmc dev ${devnum}; then " \
> > +			"run scan_boot; " \
> > +		"fi\0" \
> > +	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
> > +	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
> > +#define BOOT_TARGETS_MMC "mmc1 mmc0"
> 
> This will not work on a boot with three MMC cards ... this does not scale and 
> needs re-thinking.

Maybe once we have device model and can see how many MMCs have been
probed?  I'm not worried about a 3 mmc card system (those are
"expensive" to add, I'd be surprised about a system with some
combination of 3 or more setup for SD/eMMC, rather than saying #3+ is for
SDIO type things and more on-board SD slots being via USB where that's
cheap).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/cf093058/attachment.pgp>

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Marek Vasut]

On Friday, March 21, 2014 at 07:53:58 PM, Tom Rini wrote:
> On Fri, Mar 21, 2014 at 07:37:52PM +0100, Marek Vasut wrote:
> > On Thursday, March 20, 2014 at 11:12:57 PM, Dennis Gilmore wrote:
> > > As the next step in a generic config we are introducing a set of
> > > generic boot paramaters. Depending on the hardwares configuration,
> > > booting from supported hardware will be enabled, mmc, usb, sata, scsi,
> > > ide, pxe and dhcp.
> > > 
> > > There is nothing to stop this being extended to support nand and any
> > > other type of storage that comes along. An ideal future enhancement
> > > will be to allow the user to dynamically reorder the boot devices, and
> > > allow one off boots. for example simply be able to pxe boot to
> > > reinstall
> > > 
> > > Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> > > ---
> > > 
> > >  include/config_distro_bootcmd.h | 208
> > > 
> > > ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208
> > > insertions(+)
> > > 
> > >  create mode 100644 include/config_distro_bootcmd.h
> > > 
> > > diff --git a/include/config_distro_bootcmd.h
> > > b/include/config_distro_bootcmd.h new file mode 100644
> > > index 0000000..0fe94be
> > > --- /dev/null
> > > +++ b/include/config_distro_bootcmd.h
> > > @@ -0,0 +1,208 @@
> > > +/*
> > > + * (C) Copyright 2014
> > > + * NVIDIA Corporation <www.nvidia.com>
> > > + *
> > > + * Copyright 2014 Red Hat, Inc.
> > > + *
> > > + * SPDX-License-Identifier:     GPL-2.0+
> > > + */
> > > +
> > > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> > > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> > > +
> > > +
> > > +#ifdef CONFIG_CMD_MMC
> > > +#define BOOTCMDS_MMC \
> > > +	"mmc_boot=" \
> > > +		"setenv devtype mmc; " \
> > 
> > Please use 'env set ...'
> 
> Why?  Almost nothing uses that syntax..

Because we want to weed out the old/legacy syntax and use the new one . The 
'env' command is also more powerful and setenv/saveenv/... should just go away.

> > > +		"if mmc dev ${devnum}; then " \
> > > +			"run scan_boot; " \
> > > +		"fi\0" \
> > > +	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
> > > +	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
> > > +#define BOOT_TARGETS_MMC "mmc1 mmc0"
> > 
> > This will not work on a boot with three MMC cards ... this does not scale
> > and needs re-thinking.
> 
> Maybe once we have device model and can see how many MMCs have been
> probed?  I'm not worried about a 3 mmc card system (those are
> "expensive" to add, I'd be surprised about a system with some
> combination of 3 or more setup for SD/eMMC

I have one on my table right now right here. I also have a mutilated M28EVK with 
three SD cards , so these systems do exist. Oh, but hey, we can of course say 
"systems with three SD cards are not supported", I saw "someone" from RH take 
that kind of attitude already ...

> , rather than saying #3+ is for
> SDIO type things and more on-board SD slots being via USB where that's
> cheap).

Best regards,
Marek Vasut

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Tom Rini]

On Thu, Mar 20, 2014 at 05:12:57PM -0500, Dennis Gilmore wrote:

> As the next step in a generic config we are introducing a set of generic boot
> paramaters. Depending on the hardwares configuration, booting from supported
> hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
> 
> There is nothing to stop this being extended to support nand and any other
> type of storage that comes along. An ideal future enhancement will be to
> allow the user to dynamically reorder the boot devices, and allow one off
> boots. for example simply be able to pxe boot to reinstall
[snip]
> +	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
> +	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
> +#define BOOT_TARGETS_MMC "mmc1 mmc0"

This is because we want to prefer eMMC to SD card?  Or is mmc1=SD,
mmc0=eMMC on Tegra?  That's opposite of TI parts so we might need to
#ifndef/define/endif that combo at least.

Otherwise:

Reviewed-by: Tom Rini <trini@ti.com>

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/ddd66923/attachment.pgp>

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Stephen Warren]

On 03/21/2014 12:48 PM, Tom Rini wrote:
> On Thu, Mar 20, 2014 at 05:12:57PM -0500, Dennis Gilmore wrote:
> 
>> As the next step in a generic config we are introducing a set of generic boot
>> paramaters. Depending on the hardwares configuration, booting from supported
>> hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
>>
>> There is nothing to stop this being extended to support nand and any other
>> type of storage that comes along. An ideal future enhancement will be to
>> allow the user to dynamically reorder the boot devices, and allow one off
>> boots. for example simply be able to pxe boot to reinstall
> [snip]
>> +	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
>> +	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
>> +#define BOOT_TARGETS_MMC "mmc1 mmc0"
> 
> This is because we want to prefer eMMC to SD card?  Or is mmc1=SD,
> mmc0=eMMC on Tegra?  That's opposite of TI parts so we might need to
> #ifndef/define/endif that combo at least.

On most (all?) Tegra devices, mmc1 is SD and mmc0 is eMMC. We prefer to
try to boot from SD first so that the user can just plug in an SD card
to boot from it if they want, but otherwise boot from eMMC (just like
floppy vs HDD on a PC) without having to muck with boot order manually.

Well, that and I almost exclusively boot from SD, so it's marginally
faster and less noisy:-)

[U-Boot] [PATCH 2/6] add header with a generic set of boot commands defined.

[Stephen Warren]

On 03/20/2014 04:12 PM, Dennis Gilmore wrote:
> As the next step in a generic config we are introducing a set of generic boot
> paramaters. Depending on the hardwares configuration, booting from supported
> hardware will be enabled, mmc, usb, sata, scsi, ide, pxe and dhcp.
> 
> There is nothing to stop this being extended to support nand and any other
> type of storage that comes along. An ideal future enhancement will be to
> allow the user to dynamically reorder the boot devices, and allow one off
> boots. for example simply be able to pxe boot to reinstall

One-off boots can already be performed: "run bootcmd_mmc1" or "run
bootcmd_dhcp" work for me.

> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h

> +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> +
> +

Nit: double blank line there.

> +#ifdef CONFIG_CMD_MMC
> +#define BOOTCMDS_MMC \
> +	"mmc_boot=" \
> +		"setenv devtype mmc; " \
> +		"if mmc dev ${devnum}; then " \
> +			"run scan_boot; " \
> +		"fi\0" \
> +	"bootcmd_mmc0=setenv devnum 0; run mmc_boot;\0" \
> +	"bootcmd_mmc1=setenv devnum 1; run mmc_boot;\0"
> +#define BOOT_TARGETS_MMC "mmc1 mmc0"

It would be nice if this required the file that includes this file to
define how many MMC devices there are (some only have 1...) and the best
default boot order.

Still, that's probably challenging using the C pre-processor. Perhaps a
Python script to auto-generate these command could be more flexible.
Probably a job for a follow-on patch though.

> +#define BOOTCMDS_COMMON \
> +	"rootpart=1\0" \
> +	\
> +	"do_envimport="                                                   \
> +		"load ${devtype} ${devnum}:${rootpart} ${loadaddr} "      \
> +			"${environment}\0"                                \
> +		"env import -t ${loadaddr} $filesize\0"                   \

I think that should be:

if load ....; then
    env import ...;
fi

So the script doesn't accidentally import something stale at $loadaddr
that wasn't actually loaded.

> +	\
> +	"envimport="                                                      \
> +		"for environment in ${boot_envs}; do "                    \
> +			"if test -e ${devtype} ${devnum}:${rootpart} "    \
> +					"${prefix}${environment}; then "  \
> +				"echo Found U-Boot environment "          \
> +					"${prefix}${environment}; "       \
> +				"run do_envimport;"                       \
> +				"echo Import FAILED; continuing...; "     \
> +			"fi; "                                            \
> +		"done\0"                                                  \
> +	\

envimport doesn't actually seem to be used anywhere at least in this
patch. Is it really needed? It shouldn't be needed for generic distro
support, but more for boards without any non-filesystem-based
environment storage, and in those cases, shouldn't they use
CONFIG_PREBOOT like rpi_b.h does, so it's well-defined where the
environment comes from, before ${boot_targets} is evaluated?

> +	"do_script_boot="                                                 \
> +		"load ${devtype} ${devnum}:${rootpart} "                  \
> +			"${scriptaddr} ${prefix}${script}; "              \
> +		"source ${scriptaddr}\0"                                  \

That should be "if load ; ...; fi" too. Sorry, the Tegra/RPI scripts
give bad examples for this.

[U-Boot] [PATCH 3/6] move wandboard over to use the generic distro configuation and environment

[Dennis Gilmore]

port wandboard to use the generic distro configuation.
remove duplicated config options, clean up the environment, include new
environment.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 include/configs/wandboard.h | 92 +++++++--------------------------------------
 1 file changed, 14 insertions(+), 78 deletions(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 6c74c72..386fe78 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -49,8 +49,6 @@
 #define CONFIG_CMD_BMODE
 #define CONFIG_CMD_SETEXPR
 
-#define CONFIG_BOOTDELAY		5
-
 #define CONFIG_SYS_MEMTEST_START	0x10000000
 #define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START + 500 * SZ_1M)
 #define CONFIG_LOADADDR			0x12000000
@@ -66,15 +64,8 @@
 #define CONFIG_CMD_MMC
 #define CONFIG_GENERIC_MMC
 #define CONFIG_BOUNCE_BUFFER
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_FAT
-#define CONFIG_DOS_PARTITION
 
 /* Ethernet Configuration */
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_MII
-#define CONFIG_CMD_NET
 #define CONFIG_FEC_MXC
 #define CONFIG_MII
 #define IMX_FEC_BASE			ENET_BASE_ADDR
@@ -100,6 +91,11 @@
 #define CONFIG_IPUV3_CLK 260000000
 #define CONFIG_IMX_HDMI
 
+#ifndef CONFIG_SPL_BUILD
+#include <config_distro_defaults.h>
+#include <config_distro_bootcmd.h>
+#endif
+
 #if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
 #define CONFIG_DEFAULT_FDT_FILE		"imx6dl-wandboard.dtb"
 #elif defined(CONFIG_MX6Q)
@@ -111,11 +107,14 @@
 	"image=zImage\0" \
 	"console=ttymxc0\0" \
 	"splashpos=m,m\0" \
-	"fdt_high=0xffffffff\0" \
-	"initrd_high=0xffffffff\0" \
-	"fdt_file=" CONFIG_DEFAULT_FDT_FILE "\0" \
-	"fdt_addr=0x18000000\0" \
+	"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
+	"fdt_addr_r=0x18000000\0" \
 	"boot_fdt=try\0" \
+	"pxefile_addr_r=0x17f00000\0" \
+	"scriptaddr=0x17e00000\0" \
+	"kernel_addr_r=0x11000000\0" \
+	"ramdisk_addr_r=0x18100000\0" \
+	"bootm_size=0x20000000\0" \
 	"ip_dyn=yes\0" \
 	"mmcdev=" __stringify(CONFIG_SYS_MMC_ENV_DEV) "\0" \
 	"mmcpart=1\0" \
@@ -134,70 +133,12 @@
 				"mmc write ${loadaddr} 0x2 ${fw_sz}; " \
 			"fi; "	\
 		"fi\0" \
-	"mmcargs=setenv bootargs console=${console},${baudrate} " \
-		"root=${mmcroot}\0" \
-	"loadbootscript=" \
-		"fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-	"bootscript=echo Running bootscript from mmc ...; " \
-		"source\0" \
-	"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-	"loadfdt=fatload 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 " \
-			"if run loadfdt; then " \
-				"bootz ${loadaddr} - ${fdt_addr}; " \
-			"else " \
-				"if test ${boot_fdt} = try; then " \
-					"bootz; " \
-				"else " \
-					"echo WARN: Cannot load the DT; " \
-				"fi; " \
-			"fi; " \
-		"else " \
-			"bootz; " \
-		"fi;\0" \
-	"netargs=setenv bootargs console=${console},${baudrate} " \
-		"root=/dev/nfs " \
-	"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-		"netboot=echo Booting from net ...; " \
-		"run netargs; " \
-		"if test ${ip_dyn} = yes; then " \
-			"setenv get_cmd dhcp; " \
-		"else " \
-			"setenv get_cmd tftp; " \
-		"fi; " \
-		"${get_cmd} ${image}; " \
-		"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-			"if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
-				"bootz ${loadaddr} - ${fdt_addr}; " \
-			"else " \
-				"if test ${boot_fdt} = try; then " \
-					"bootz; " \
-				"else " \
-					"echo WARN: Cannot load the DT; " \
-				"fi; " \
-			"fi; " \
-		"else " \
-			"bootz; " \
-		"fi;\0"
+	BOOTCMDS_COMMON
 
 #define CONFIG_BOOTCOMMAND \
-	   "mmc dev ${mmcdev}; if mmc rescan; then " \
-		   "if run loadbootscript; then " \
-			   "run bootscript; " \
-		   "else " \
-			   "if run loadimage; then " \
-				   "run mmcboot; " \
-			   "else run netboot; " \
-			   "fi; " \
-		   "fi; " \
-	   "else run netboot; fi"
+	"for target in ${boot_targets}; do run bootcmd_${target}; done"
 
 /* Miscellaneous configurable options */
-#define CONFIG_SYS_LONGHELP
-#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_AUTO_COMPLETE
 #define CONFIG_SYS_CBSIZE		256
 
 /* Print Buffer Size */
@@ -207,8 +148,6 @@
 
 #define CONFIG_SYS_LOAD_ADDR		CONFIG_LOADADDR
 
-#define CONFIG_CMDLINE_EDITING
-
 /* Physical Memory Map */
 #define CONFIG_NR_DRAM_BANKS		1
 #define PHYS_SDRAM			MMDC0_ARB_BASE_ADDR
@@ -231,9 +170,6 @@
 #define CONFIG_ENV_OFFSET		(6 * 64 * 1024)
 #define CONFIG_SYS_MMC_ENV_DEV		0
 
-#define CONFIG_OF_LIBFDT
-#define CONFIG_CMD_BOOTZ
-
 #ifndef CONFIG_SYS_DCACHE_OFF
 #define CONFIG_CMD_CACHE
 #endif
-- 
1.9.0

[U-Boot] [PATCH 4/6] move beagleboard over to use the generic distro configuation and environment

[Dennis Gilmore]

port beagleboard to use the generic distro configuation.
remove duplicated config options, clean up the environment, include new
environment.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 include/configs/am335x_evm.h      | 62 +++++++++------------------------------
 include/configs/ti_armv7_common.h | 32 ++++++--------------
 2 files changed, 23 insertions(+), 71 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 11088b3..1dd4486 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -50,9 +50,9 @@
 	"nandrootfstype=ubifs rootwait=1\0" \
 	"nandboot=echo Booting from nand ...; " \
 		"run nandargs; " \
-		"nand read ${fdtaddr} u-boot-spl-os; " \
-		"nand read ${loadaddr} kernel; " \
-		"bootz ${loadaddr} - ${fdtaddr}\0"
+		"nand read ${fdt_addr_r} u-boot-spl-os; " \
+		"nand read ${kernel_addr_r} kernel; " \
+		"bootz ${kernel_addr_r} - ${fdt_addr_r}\0"
 #else
 #define NANDARGS ""
 #endif
@@ -100,60 +100,28 @@
 		"nfsroot=${serverip}:${rootpath},${nfsopts} rw " \
 		"ip=dhcp\0" \
 	"bootenv=uEnv.txt\0" \
-	"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
+	"loadbootenv=load mmc ${mmcdev} ${kernel_addr_r} ${bootenv}\0" \
 	"importbootenv=echo Importing environment from mmc ...; " \
-		"env import -t $loadaddr $filesize\0" \
+		"env import -t $kernel_addr_r $filesize\0" \
 	"ramargs=setenv bootargs console=${console} " \
 		"${optargs} " \
 		"root=${ramroot} " \
 		"rootfstype=${ramrootfstype}\0" \
-	"loadramdisk=load mmc ${mmcdev} ${rdaddr} ramdisk.gz\0" \
-	"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
-	"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
-	"mmcloados=run mmcargs; " \
-		"if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-			"if run loadfdt; then " \
-				"bootz ${loadaddr} - ${fdtaddr}; " \
-			"else " \
-				"if test ${boot_fdt} = try; then " \
-					"bootz; " \
-				"else " \
-					"echo WARN: Cannot load the DT; " \
-				"fi; " \
-			"fi; " \
-		"else " \
-			"bootz; " \
-		"fi;\0" \
-	"mmcboot=mmc dev ${mmcdev}; " \
-		"if mmc rescan; then " \
-			"echo SD/MMC found on device ${mmcdev};" \
-			"if run loadbootenv; then " \
-				"echo Loaded environment from ${bootenv};" \
-				"run importbootenv;" \
-			"fi;" \
-			"if test -n $uenvcmd; then " \
-				"echo Running uenvcmd ...;" \
-				"run uenvcmd;" \
-			"fi;" \
-			"if run loadimage; then " \
-				"run mmcloados;" \
-			"fi;" \
-		"fi;\0" \
 	"spiboot=echo Booting from spi ...; " \
 		"run spiargs; " \
 		"sf probe ${spibusno}:0; " \
-		"sf read ${loadaddr} ${spisrcaddr} ${spiimgsize}; " \
-		"bootz ${loadaddr}\0" \
+		"sf read ${kernel_addr_r} ${spisrcaddr} ${spiimgsize}; " \
+		"bootz ${kernel_addr_r}\0" \
 	"netboot=echo Booting from network ...; " \
 		"setenv autoload no; " \
 		"dhcp; " \
-		"tftp ${loadaddr} ${bootfile}; " \
-		"tftp ${fdtaddr} ${fdtfile}; " \
+		"tftp ${kernel_addr_r} ${bootfile}; " \
+		"tftp ${fdt_addr_r} ${fdtfile}; " \
 		"run netargs; " \
-		"bootz ${loadaddr} - ${fdtaddr}\0" \
+		"bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 	"ramboot=echo Booting from ramdisk ...; " \
 		"run ramargs; " \
-		"bootz ${loadaddr} ${rdaddr} ${fdtaddr}\0" \
+		"bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}\0" \
 	"findfdt="\
 		"if test $board_name = A335BONE; then " \
 			"setenv fdtfile am335x-bone.dtb; fi; " \
@@ -166,15 +134,13 @@
 		"if test $fdtfile = undefined; then " \
 			"echo WARNING: Could not determine device tree to use; fi; \0" \
 	NANDARGS \
-	DFUARGS
+	DFUARGS \
+	BOOTCMDS_COMMON
 #endif
 
 #define CONFIG_BOOTCOMMAND \
 	"run findfdt; " \
-	"run mmcboot;" \
-	"setenv mmcdev 1; " \
-	"setenv bootpart 1:2; " \
-	"run mmcboot;" \
+	"for target in ${boot_targets}; do run bootcmd_${target}; done " \
 	"run nandboot;"
 
 /* NS16550 Configuration */
diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
index fda99fb..96c6bd0 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -28,7 +28,6 @@
 #define CONFIG_SYS_NO_FLASH
 
 /* Support both device trees and ATAGs. */
-#define CONFIG_OF_LIBFDT
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
@@ -53,6 +52,8 @@
 #define DEFAULT_LINUX_BOOT_ENV \
 	"loadaddr=0x82000000\0" \
 	"kernel_addr_r=0x82000000\0" \
+	"pxe_addr_r=0x87F00000\0" \
+	"scriptaddr=0x87E00000\0" \
 	"fdtaddr=0x88000000\0" \
 	"fdt_addr_r=0x88000000\0" \
 	"rdaddr=0x88080000\0" \
@@ -60,11 +61,6 @@
 	"bootm_size=0x20000000\0"
 
 /*
- * Default to a quick boot delay.
- */
-#define CONFIG_BOOTDELAY		1
-
-/*
  * DDR information.  If the CONFIG_NR_DRAM_BANKS is not defined,
  * we say (for simplicity) that we have 1 bank, always, even when
  * we have more.  We always start at 0x80000000, and we place the
@@ -125,19 +121,12 @@
  * console baudrate of 115200 and use the default baud rate table.
  */
 #define CONFIG_SYS_MALLOC_LEN		(1024 << 10)
-#define CONFIG_SYS_HUSH_PARSER
 #define CONFIG_SYS_PROMPT		"U-Boot# "
 #define CONFIG_SYS_CONSOLE_INFO_QUIET
 #define CONFIG_BAUDRATE			115200
 #define CONFIG_ENV_VARS_UBOOT_CONFIG	/* Strongly encouraged */
 #define CONFIG_ENV_OVERWRITE		/* Overwrite ethaddr / serial# */
 
-/* As stated above, the following choices are optional. */
-#define CONFIG_SYS_LONGHELP
-#define CONFIG_AUTO_COMPLETE
-#define CONFIG_CMDLINE_EDITING
-#define CONFIG_VERSION_VARIABLE
-
 /* We set the max number of command args high to avoid HUSH bugs. */
 #define CONFIG_SYS_MAXARGS		64
 
@@ -170,21 +159,18 @@
 #include <config_cmd_default.h>
 #define CONFIG_CMD_ASKENV
 #define CONFIG_CMD_ECHO
-#define CONFIG_CMD_BOOTZ
 
 /*
- * Common filesystems support.  When we have removable storage we
- * enabled a number of useful commands and support.
+ * Include the generic config options and boot environment when not
+ * building our SPL
  */
-#if defined(CONFIG_MMC) || defined(CONFIG_USB_STORAGE)
-#define CONFIG_DOS_PARTITION
-#define CONFIG_CMD_FAT
-#define CONFIG_FAT_WRITE
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_EXT4
-#define CONFIG_CMD_FS_GENERIC
+#ifndef CONFIG_SPL_BUILD
+#include <config_distro_defaults.h>
+#include <config_distro_bootcmd.h>
 #endif
 
+#define CONFIG_CMD_FAT
+
 /*
  * Our platforms make use of SPL to initalize the hardware (primarily
  * memory) enough for full U-Boot to be loaded.  We also support Falcon
-- 
1.9.0

[U-Boot] [PATCH 4/6] move beagleboard over to use the generic distro configuation and environment

[Tom Rini]

On Thu, Mar 20, 2014 at 05:12:59PM -0500, Dennis Gilmore wrote:

> port beagleboard to use the generic distro configuation.
> remove duplicated config options, clean up the environment, include new
> environment.
> 
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
>  include/configs/am335x_evm.h      | 62 +++++++++------------------------------
>  include/configs/ti_armv7_common.h | 32 ++++++--------------

Changing ti_armv7_common.h changes a ton of other boards which may not
want to opt-in here yet / ever.  So we need to:

>  2 files changed, 23 insertions(+), 71 deletions(-)
> 
> diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
> index 11088b3..1dd4486 100644
> --- a/include/configs/am335x_evm.h
> +++ b/include/configs/am335x_evm.h

Add the generic distro includes here.

> diff --git a/include/configs/ti_armv7_common.h b/include/configs/ti_armv7_common.h
> index fda99fb..96c6bd0 100644
> --- a/include/configs/ti_armv7_common.h
> +++ b/include/configs/ti_armv7_common.h
[snip]
> @@ -60,11 +61,6 @@
>  	"bootm_size=0x20000000\0"
>  
>  /*
> - * Default to a quick boot delay.
> - */
> -#define CONFIG_BOOTDELAY		1

Change this to 2, and leave the rest of the duplicated enables alone.

>  /*
> - * Common filesystems support.  When we have removable storage we
> - * enabled a number of useful commands and support.
> + * Include the generic config options and boot environment when not
> + * building our SPL
>   */
> -#if defined(CONFIG_MMC) || defined(CONFIG_USB_STORAGE)
> -#define CONFIG_DOS_PARTITION
> -#define CONFIG_CMD_FAT
> -#define CONFIG_FAT_WRITE
> -#define CONFIG_CMD_EXT2
> -#define CONFIG_CMD_EXT4
> -#define CONFIG_CMD_FS_GENERIC
> +#ifndef CONFIG_SPL_BUILD
> +#include <config_distro_defaults.h>
> +#include <config_distro_bootcmd.h>
>  #endif
>  
> +#define CONFIG_CMD_FAT

And leave this part out as well.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/951d0705/attachment.pgp>

[U-Boot] [PATCH 5/6] move pandaboard over to use the generic distro configuation and environment

[Dennis Gilmore]

port pandaboard to use the generic distro configuation.
remove duplicated config options, clean up the environment, include new
environment.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 include/configs/omap4_panda.h     |  2 --
 include/configs/ti_omap4_common.h | 37 +++++++++++--------------------------
 2 files changed, 11 insertions(+), 28 deletions(-)

diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index 7378acd..1b81a24 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -33,8 +33,6 @@
 
 #define CONFIG_UBOOT_ENABLE_PADS_ALL
 
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_DHCP
 
 #include <configs/ti_omap4_common.h>
 #define CONFIG_CMD_NET
diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h
index 387f570..f9baa50 100644
--- a/include/configs/ti_omap4_common.h
+++ b/include/configs/ti_omap4_common.h
@@ -86,6 +86,7 @@
 /*
  * Environment setup
  */
+#ifndef CONFIG_SPL_BUILD
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	DEFAULT_LINUX_BOOT_ENV \
 	"console=ttyO2,115200n8\0" \
@@ -102,16 +103,16 @@
 		"vram=${vram} " \
 		"root=${mmcroot} " \
 		"rootfstype=${mmcrootfstype}\0" \
-	"loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \
+	"loadbootscript=load mmc ${mmcdev} ${kernel_addr_r} boot.scr\0" \
 	"bootscript=echo Running bootscript from mmc${mmcdev} ...; " \
-		"source ${loadaddr}\0" \
-	"loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \
+		"source ${kernel_addr_r}\0" \
+	"loadbootenv=load mmc ${mmcdev} ${kernel_addr_r} uEnv.txt\0" \
 	"importbootenv=echo Importing environment from mmc${mmcdev} ...; " \
-		"env import -t ${loadaddr} ${filesize}\0" \
-	"loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0" \
+		"env import -t ${kernel_addr_r} ${filesize}\0" \
+	"loadimage=load mmc ${bootpart} ${kernel_addr_r} ${bootdir}/${bootfile}\0" \
 	"mmcboot=echo Booting from mmc${mmcdev} ...; " \
 		"run mmcargs; " \
-		"bootz ${loadaddr} - ${fdtaddr}\0" \
+		"bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 	"findfdt="\
 		"if test $board_name = sdp4430; then " \
 			"setenv fdtfile omap4-sdp.dtb; fi; " \
@@ -123,29 +124,13 @@
 			"setenv fdtfile omap4-panda-es.dtb; fi;" \
 		"if test $fdtfile = undefined; then " \
 			"echo WARNING: Could not determine device tree to use; fi; \0" \
-	"loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0" \
+	"loadfdt=load mmc ${bootpart} ${fdt_addr_r} ${bootdir}/${fdtfile}\0" \
+	BOOTCMDS_COMMON
+#endif
 
 #define CONFIG_BOOTCOMMAND \
 	"run findfdt; " \
-	"mmc dev ${mmcdev}; if mmc rescan; then " \
-		"echo SD/MMC found on device ${mmcdev};" \
-		"if run loadbootscript; then " \
-			"run bootscript; " \
-		"else " \
-			"if run loadbootenv; then " \
-				"run importbootenv; " \
-			"fi;" \
-			"if test -n ${uenvcmd}; then " \
-				"echo Running uenvcmd ...;" \
-				"run uenvcmd;" \
-			"fi;" \
-		"fi;" \
-		"if run loadimage; then " \
-			"run loadfdt;" \
-			"run mmcboot; " \
-		"fi; " \
-	"fi"
-
+	"for target in ${boot_targets}; do run bootcmd_${target}; done "
 /*
  * Defines for SPL
  * It is known that this will break HS devices. Since the current size of
-- 
1.9.0

[U-Boot] [PATCH 5/6] move pandaboard over to use the generic distro configuation and environment

[Tom Rini]

On Thu, Mar 20, 2014 at 05:13:00PM -0500, Dennis Gilmore wrote:

> port pandaboard to use the generic distro configuation.
> remove duplicated config options, clean up the environment, include new
> environment.
[snip]
> diff --git a/include/configs/ti_omap4_common.h b/include/configs/ti_omap4_common.h
> index 387f570..f9baa50 100644
> --- a/include/configs/ti_omap4_common.h
> +++ b/include/configs/ti_omap4_common.h

With what I said in 3/6, I'm OK with opting all of omap4 in.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/bcd18456/attachment.pgp>

[U-Boot] [PATCH 6/6] pxe: additionaly check for fdt_file env variable

[Dennis Gilmore]

some boards have used fdt_file while others have used fdtfile to
define the name of the fdt file. If we do notget a fdtfile environment
variable, additionally check for fdt_file.

Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
 common/cmd_pxe.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
index 3483328..c58e471 100644
--- a/common/cmd_pxe.c
+++ b/common/cmd_pxe.c
@@ -712,6 +712,13 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label)
 			char *f1, *f2, *f3, *f4, *slash;
 
 			f1 = getenv("fdtfile");
+			/*
+			 * some boards have used fdt_file as the environment variable for
+			 * defining the device tree file so lets check for fdt_file also.
+			 */
+			if (!f1) {
+				f1 = getenv("fdt_file");
+			}
 			if (f1) {
 				f2 = "";
 				f3 = "";
-- 
1.9.0

[U-Boot] [PATCH 6/6] pxe: additionaly check for fdt_file env variable

[Tom Rini]

On Thu, Mar 20, 2014 at 05:13:01PM -0500, Dennis Gilmore wrote:

> some boards have used fdt_file while others have used fdtfile to
> define the name of the fdt file. If we do notget a fdtfile environment
> variable, additionally check for fdt_file.
> 
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
>  common/cmd_pxe.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
> index 3483328..c58e471 100644
> --- a/common/cmd_pxe.c
> +++ b/common/cmd_pxe.c
> @@ -712,6 +712,13 @@ static int label_boot(cmd_tbl_t *cmdtp, struct pxe_label *label)
>  			char *f1, *f2, *f3, *f4, *slash;
>  
>  			f1 = getenv("fdtfile");
> +			/*
> +			 * some boards have used fdt_file as the environment variable for
> +			 * defining the device tree file so lets check for fdt_file also.
> +			 */

Correctly wrap this please, thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140321/17808eb4/attachment.pgp>

[U-Boot] [PATCH 6/6] pxe: additionaly check for fdt_file env variable

[Stephen Warren]

On 03/20/2014 04:13 PM, Dennis Gilmore wrote:
> some boards have used fdt_file while others have used fdtfile to
> define the name of the fdt file. If we do notget a fdtfile environment
> variable, additionally check for fdt_file.

Is this variable typically set by the user or by the default
environment? If the default environment, perhaps the variable name could
simply be changed?

Still, this change is fine by me,
Acked-by: Stephen Warren <swarren@nvidia.com

> diff --git a/common/cmd_pxe.c b/common/cmd_pxe.c
> +			if (!f1) {
> +				f1 = getenv("fdt_file");
> +			}

Doesn't checkpatch say to remove the {} there?