[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Simon Glass]

At present U-Boot environment variables, and thus scripts, are defined
by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
to this file and dealing with quoting and newlines is harder than it
should be. It would be better if we could just type the script into a
text file and have it included by U-Boot.

Add a feature that brings in a .env file associated with the board
config, if present. To use it, create a file in include/configs
with the same name as you could board config file, except with a
.env extension instead of a .h extension. The variables should be
separated by \0. Comments are permitted, using # as the first character
in a line.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 Makefile                     | 25 ++++++++++++++++++++++++-
 README                       | 28 ++++++++++++++++++++++++++++
 include/env_default.h        |  2 ++
 mkconfig                     |  4 ++++
 tools/scripts/env2string.sed |  7 +++++++
 5 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 tools/scripts/env2string.sed

diff --git a/Makefile b/Makefile
index 252fc6c..f400d21 100644
--- a/Makefile
+++ b/Makefile
@@ -680,7 +680,7 @@ $(obj)include/autoconf.mk.dep: $(obj)include/config.h include/common.h
 	$(CC) -x c -DDO_DEPS_ONLY -M $(CFLAGS) $(CPPFLAGS) \
 		-MQ $(obj)include/autoconf.mk include/common.h > $@
 
-$(obj)include/autoconf.mk: $(obj)include/config.h
+$(obj)include/generated/autoconf.mk.base: $(obj)include/config.h
 	@$(XECHO) Generating $@ ; \
 	set -e ; \
 	: Extract the config macros ; \
@@ -688,6 +688,29 @@ $(obj)include/autoconf.mk: $(obj)include/config.h
 		sed -n -f tools/scripts/define2mk.sed > $@.tmp && \
 	mv $@.tmp $@
 
+ENV_HEADER = $(obj)include/generated/environment.h
+
+$(obj)include/generated/environment.inc: $(obj)include/generated/autoconf.mk.base
+	@$(XECHO) Generating $@ ; \
+	set -e ; \
+	: Process the environment file ; \
+	envf=$$(sed -n -e '/CONFIG_EXTRA_ENV_SCRIPT/ { s/CONFIG_EXTRA_ENV_SCRIPT=\"\(.*\)\"/\1/;  p }' \
+		$<) ; \
+	echo -n "CONFIG_EXTRA_ENV_TEXT=\"" >$@ ; \
+	echo -n "#define CONFIG_EXTRA_ENV_TEXT \"" >$(ENV_HEADER) ; \
+	if [ -f "$(src)include/configs/$${envf}" ]; then \
+		: Change newline to \n, and quote quotes ; \
+		sed -e 's/^\#.*//' "$(src)include/configs/$${envf}" | \
+			sed -f tools/scripts/env2string.sed | \
+			sed -e 's/"/\\"/g' | \
+			tr -d '\n' | tee -a $(ENV_HEADER) >>$@ ; \
+	fi ; \
+	echo "\"" >>$@
+	echo "\"" >>$(ENV_HEADER)
+
+$(obj)include/autoconf.mk: $(obj)include/generated/environment.inc
+	cat $(obj)include/generated/autoconf.mk.base $< >$@
+
 $(obj)include/generated/generic-asm-offsets.h:	$(obj)include/autoconf.mk.dep \
 	$(obj)lib/asm-offsets.s
 	@$(XECHO) Generating $@
diff --git a/README b/README
index 0bc0af5..6076c90 100644
--- a/README
+++ b/README
@@ -4245,6 +4245,34 @@ environment. As long as you don't save the environment you are
 working with an in-memory copy. In case the Flash area containing the
 environment is erased by accident, a default environment is provided.
 
+The default environment is created in include/env_default.h, and can be
+augmented by various CONFIG defines. See that file for details. In
+particular you can define CONFIG_EXTRA_ENV_SETTINGS in your board file
+to add environment variables (see 'CONFIG_EXTRA_ENV_SETTINGS' above
+for details).
+
+It is also possible to create a .env file in include/configs for your
+board. For example, for snapper9260 you would create a text file called
+include/configs/snapper9260.env containing the environment text. This
+file can include comments (lines starting with #) and blank lines. As
+with CONFIG_EXTRA_ENV_SETTINGS you must add a \0 at the end of each
+variable (except the last). For example:
+
+bootcmd=
+# U-Boot script for booting
+
+if [ -z ${tftpserverip} ]; then
+	echo "Use 'setenv tftpserverip a.b.c.d' to set your machine IP address."
+fi
+
+usb start; setenv autoload n; bootp;
+tftpboot ${tftpserverip}:;
+bootm
+\0failed=
+# Print a message when boot fails
+echo "Boot failed - please check your image"
+
+
 Some configuration options can be set using Environment Variables.
 
 List of environment variables (most likely not complete):
diff --git a/include/env_default.h b/include/env_default.h
index 39c5b7c..a394df5 100644
--- a/include/env_default.h
+++ b/include/env_default.h
@@ -137,6 +137,8 @@ const uchar default_environment[] = {
 #ifdef	CONFIG_EXTRA_ENV_SETTINGS
 	CONFIG_EXTRA_ENV_SETTINGS
 #endif
+	/* This is created in the Makefile */
+	CONFIG_EXTRA_ENV_TEXT
 	"\0"
 #ifdef DEFAULT_ENV_INSTANCE_EMBEDDED
 	}
diff --git a/mkconfig b/mkconfig
index 73f852e..c54b730 100755
--- a/mkconfig
+++ b/mkconfig
@@ -171,10 +171,14 @@ echo "#define CONFIG_SYS_BOARD \"${board}\"" >> config.h
 
 cat << EOF >> config.h
 #define CONFIG_BOARDDIR board/$BOARDDIR
+#define CONFIG_EXTRA_ENV_SCRIPT ${CONFIG_NAME}.env
 #include <config_cmd_defaults.h>
 #include <config_defaults.h>
 #include <configs/${CONFIG_NAME}.h>
 #include <asm/config.h>
+#if !defined(DO_DEPS_ONLY) && !defined(__ASSEMBLY__)
+#include <generated/environment.h>
+#endif
 #include <config_fallbacks.h>
 #include <config_uncmd_spl.h>
 EOF
diff --git a/tools/scripts/env2string.sed b/tools/scripts/env2string.sed
new file mode 100644
index 0000000..0ffc0e7
--- /dev/null
+++ b/tools/scripts/env2string.sed
@@ -0,0 +1,7 @@
+#
+# Sed script to parse a text file containing an environment and convert it
+# to a C string
+#
+
+# Change newlines to \n
+{ :q;N;s/\n/\\n/g; t q}
-- 
1.8.1.3

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Wolfgang Denk]

Dear Simon Glass,

In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
> At present U-Boot environment variables, and thus scripts, are defined
> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> to this file and dealing with quoting and newlines is harder than it
> should be. It would be better if we could just type the script into a
> text file and have it included by U-Boot.
> 
> Add a feature that brings in a .env file associated with the board
> config, if present. To use it, create a file in include/configs
> with the same name as you could board config file, except with a
> .env extension instead of a .h extension. The variables should be
> separated by \0. Comments are permitted, using # as the first character
> in a line.

Please do not litter the include/configs/ directory with such stuff.
It's more than big enough already.  Please put such files into the
respective board directories.

And if you do something like this, then please go the way to the end.
Forget about the \0 termination, make it a plain text file instead,
something that can be used with "env import -t" as well (or created
with "env export -t").

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Many companies that have made themselves dependent on [the  equipment
of  a  certain  major  manufacturer] (and in doing so have sold their
soul to the devil) will collapse under the sheer weight  of  the  un-
mastered complexity of their data processing systems.
          -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Otavio Salvador]

On Wed, Apr 17, 2013 at 2:44 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> At present U-Boot environment variables, and thus scripts, are defined
>> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> to this file and dealing with quoting and newlines is harder than it
>> should be. It would be better if we could just type the script into a
>> text file and have it included by U-Boot.
>>
>> Add a feature that brings in a .env file associated with the board
>> config, if present. To use it, create a file in include/configs
>> with the same name as you could board config file, except with a
>> .env extension instead of a .h extension. The variables should be
>> separated by \0. Comments are permitted, using # as the first character
>> in a line.
>
> Please do not litter the include/configs/ directory with such stuff.
> It's more than big enough already.  Please put such files into the
> respective board directories.
>
> And if you do something like this, then please go the way to the end.
> Forget about the \0 termination, make it a plain text file instead,
> something that can be used with "env import -t" as well (or created
> with "env export -t").

It'd be nice if we could use #include or something there which might
allow reuse of env settings among several boards.

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Simon Glass]

Hi Wolfgang,

On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> At present U-Boot environment variables, and thus scripts, are defined
>> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> to this file and dealing with quoting and newlines is harder than it
>> should be. It would be better if we could just type the script into a
>> text file and have it included by U-Boot.
>>
>> Add a feature that brings in a .env file associated with the board
>> config, if present. To use it, create a file in include/configs
>> with the same name as you could board config file, except with a
>> .env extension instead of a .h extension. The variables should be
>> separated by \0. Comments are permitted, using # as the first character
>> in a line.
>
> Please do not litter the include/configs/ directory with such stuff.
> It's more than big enough already.  Please put such files into the
> respective board directories.

OK.

>
> And if you do something like this, then please go the way to the end.
> Forget about the \0 termination, make it a plain text file instead,
> something that can be used with "env import -t" as well (or created
> with "env export -t").

I'm not sure how to do this. Doesn't this mean that we cannot add
multi-line scripts to the environment? That was part of my aim. But if
I put a 0x0a in the script then it will think we are starting a new
variable.

Perhaps we should automatically convert newline into semicolon? I
suspect that might work for most cases. But then exporting the text
file will not get the same thing as was imported.

I suppose I could use 0x0d as the line separator - it should be easy
enough to transparently convert this to and from 0x0a in 'env export
-t'.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Many companies that have made themselves dependent on [the  equipment
> of  a  certain  major  manufacturer] (and in doing so have sold their
> soul to the devil) will collapse under the sheer weight  of  the  un-
> mastered complexity of their data processing systems.
>           -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Tom Rini]

On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
> Hi Wolfgang,
> 
> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Simon Glass,
> >
> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
> >> At present U-Boot environment variables, and thus scripts, are defined
> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
> >> to this file and dealing with quoting and newlines is harder than it
> >> should be. It would be better if we could just type the script into a
> >> text file and have it included by U-Boot.
> >>
> >> Add a feature that brings in a .env file associated with the board
> >> config, if present. To use it, create a file in include/configs
> >> with the same name as you could board config file, except with a
> >> .env extension instead of a .h extension. The variables should be
> >> separated by \0. Comments are permitted, using # as the first character
> >> in a line.
> >
> > Please do not litter the include/configs/ directory with such stuff.
> > It's more than big enough already.  Please put such files into the
> > respective board directories.
> 
> OK.
> 
> >
> > And if you do something like this, then please go the way to the end.
> > Forget about the \0 termination, make it a plain text file instead,
> > something that can be used with "env import -t" as well (or created
> > with "env export -t").
> 
> I'm not sure how to do this. Doesn't this mean that we cannot add
> multi-line scripts to the environment? That was part of my aim. But if
> I put a 0x0a in the script then it will think we are starting a new
> variable.

The first thing that pops to mind is:
1) embedded the text file into a linker-known spot
2) Make part of the default env setup process be to env import -t that
location in memory.

-- 
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/20130423/f1de9dc1/attachment.pgp>

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Simon Glass]

Hi Tom,

On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>> Hi Wolfgang,
>>
>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>> > Dear Simon Glass,
>> >
>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> >> At present U-Boot environment variables, and thus scripts, are defined
>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> >> to this file and dealing with quoting and newlines is harder than it
>> >> should be. It would be better if we could just type the script into a
>> >> text file and have it included by U-Boot.
>> >>
>> >> Add a feature that brings in a .env file associated with the board
>> >> config, if present. To use it, create a file in include/configs
>> >> with the same name as you could board config file, except with a
>> >> .env extension instead of a .h extension. The variables should be
>> >> separated by \0. Comments are permitted, using # as the first character
>> >> in a line.
>> >
>> > Please do not litter the include/configs/ directory with such stuff.
>> > It's more than big enough already.  Please put such files into the
>> > respective board directories.
>>
>> OK.
>>
>> >
>> > And if you do something like this, then please go the way to the end.
>> > Forget about the \0 termination, make it a plain text file instead,
>> > something that can be used with "env import -t" as well (or created
>> > with "env export -t").
>>
>> I'm not sure how to do this. Doesn't this mean that we cannot add
>> multi-line scripts to the environment? That was part of my aim. But if
>> I put a 0x0a in the script then it will think we are starting a new
>> variable.
>
> The first thing that pops to mind is:
> 1) embedded the text file into a linker-known spot
> 2) Make part of the default env setup process be to env import -t that
> location in memory.

Well I have a working implementation - my concern was more about how
to deal with newlines. I would like to be able to handle a script just
written out over multiple lines in a text file. This is really nice
because we can have proper indenting, comments, etc. As soon as we
have to use 0x0a as the separator between each environment variable
that is no longer possible.

My current scheme requires the .env file to have \0 separating
environment variables which is obviously not ideal. I am hoping we can
find another way which is more textfile-friendly without losing the
benefits.

Regards,
Simon

>
> --
> Tom

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Otavio Salvador]

On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>> Hi Wolfgang,
>>>
>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>> > Dear Simon Glass,
>>> >
>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>> >> to this file and dealing with quoting and newlines is harder than it
>>> >> should be. It would be better if we could just type the script into a
>>> >> text file and have it included by U-Boot.
>>> >>
>>> >> Add a feature that brings in a .env file associated with the board
>>> >> config, if present. To use it, create a file in include/configs
>>> >> with the same name as you could board config file, except with a
>>> >> .env extension instead of a .h extension. The variables should be
>>> >> separated by \0. Comments are permitted, using # as the first character
>>> >> in a line.
>>> >
>>> > Please do not litter the include/configs/ directory with such stuff.
>>> > It's more than big enough already.  Please put such files into the
>>> > respective board directories.
>>>
>>> OK.
>>>
>>> >
>>> > And if you do something like this, then please go the way to the end.
>>> > Forget about the \0 termination, make it a plain text file instead,
>>> > something that can be used with "env import -t" as well (or created
>>> > with "env export -t").
>>>
>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>> multi-line scripts to the environment? That was part of my aim. But if
>>> I put a 0x0a in the script then it will think we are starting a new
>>> variable.
>>
>> The first thing that pops to mind is:
>> 1) embedded the text file into a linker-known spot
>> 2) Make part of the default env setup process be to env import -t that
>> location in memory.
>
> Well I have a working implementation - my concern was more about how
> to deal with newlines. I would like to be able to handle a script just
> written out over multiple lines in a text file. This is really nice
> because we can have proper indenting, comments, etc. As soon as we
> have to use 0x0a as the separator between each environment variable
> that is no longer possible.
>
> My current scheme requires the .env file to have \0 separating
> environment variables which is obviously not ideal. I am hoping we can
> find another way which is more textfile-friendly without losing the
> benefits.

What about using \ as continuous line indicator and otherwise finish
the line, when parsing, wiht \0?

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Simon Glass]

Hi Otavio,

On Tue, Apr 23, 2013 at 7:14 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Tom,
>>
>> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>>> Hi Wolfgang,
>>>>
>>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>>> > Dear Simon Glass,
>>>> >
>>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>>> >> to this file and dealing with quoting and newlines is harder than it
>>>> >> should be. It would be better if we could just type the script into a
>>>> >> text file and have it included by U-Boot.
>>>> >>
>>>> >> Add a feature that brings in a .env file associated with the board
>>>> >> config, if present. To use it, create a file in include/configs
>>>> >> with the same name as you could board config file, except with a
>>>> >> .env extension instead of a .h extension. The variables should be
>>>> >> separated by \0. Comments are permitted, using # as the first character
>>>> >> in a line.
>>>> >
>>>> > Please do not litter the include/configs/ directory with such stuff.
>>>> > It's more than big enough already.  Please put such files into the
>>>> > respective board directories.
>>>>
>>>> OK.
>>>>
>>>> >
>>>> > And if you do something like this, then please go the way to the end.
>>>> > Forget about the \0 termination, make it a plain text file instead,
>>>> > something that can be used with "env import -t" as well (or created
>>>> > with "env export -t").
>>>>
>>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>>> multi-line scripts to the environment? That was part of my aim. But if
>>>> I put a 0x0a in the script then it will think we are starting a new
>>>> variable.
>>>
>>> The first thing that pops to mind is:
>>> 1) embedded the text file into a linker-known spot
>>> 2) Make part of the default env setup process be to env import -t that
>>> location in memory.
>>
>> Well I have a working implementation - my concern was more about how
>> to deal with newlines. I would like to be able to handle a script just
>> written out over multiple lines in a text file. This is really nice
>> because we can have proper indenting, comments, etc. As soon as we
>> have to use 0x0a as the separator between each environment variable
>> that is no longer possible.
>>
>> My current scheme requires the .env file to have \0 separating
>> environment variables which is obviously not ideal. I am hoping we can
>> find another way which is more textfile-friendly without losing the
>> benefits.
>
> What about using \ as continuous line indicator and otherwise finish
> the line, when parsing, wiht \0?

Thanks for the suggestion. But that, along with the need for quotes,
is one of the reasons I would like to provide a way to enter scripts
naturally.

Adding \ at the end of each line is error-prone and gets in the way.
Python and C don't have this requirement - so why should U-Boot
scripts?

I wonder if we could define that 'xxx=' at the start of a line
delineates a new variable?

Regards,
Simon

>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Otavio Salvador]

On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Otavio,
>
> On Tue, Apr 23, 2013 at 7:14 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Tom,
>>>
>>> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>>>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>>>> Hi Wolfgang,
>>>>>
>>>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>>>> > Dear Simon Glass,
>>>>> >
>>>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>>>> >> to this file and dealing with quoting and newlines is harder than it
>>>>> >> should be. It would be better if we could just type the script into a
>>>>> >> text file and have it included by U-Boot.
>>>>> >>
>>>>> >> Add a feature that brings in a .env file associated with the board
>>>>> >> config, if present. To use it, create a file in include/configs
>>>>> >> with the same name as you could board config file, except with a
>>>>> >> .env extension instead of a .h extension. The variables should be
>>>>> >> separated by \0. Comments are permitted, using # as the first character
>>>>> >> in a line.
>>>>> >
>>>>> > Please do not litter the include/configs/ directory with such stuff.
>>>>> > It's more than big enough already.  Please put such files into the
>>>>> > respective board directories.
>>>>>
>>>>> OK.
>>>>>
>>>>> >
>>>>> > And if you do something like this, then please go the way to the end.
>>>>> > Forget about the \0 termination, make it a plain text file instead,
>>>>> > something that can be used with "env import -t" as well (or created
>>>>> > with "env export -t").
>>>>>
>>>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>>>> multi-line scripts to the environment? That was part of my aim. But if
>>>>> I put a 0x0a in the script then it will think we are starting a new
>>>>> variable.
>>>>
>>>> The first thing that pops to mind is:
>>>> 1) embedded the text file into a linker-known spot
>>>> 2) Make part of the default env setup process be to env import -t that
>>>> location in memory.
>>>
>>> Well I have a working implementation - my concern was more about how
>>> to deal with newlines. I would like to be able to handle a script just
>>> written out over multiple lines in a text file. This is really nice
>>> because we can have proper indenting, comments, etc. As soon as we
>>> have to use 0x0a as the separator between each environment variable
>>> that is no longer possible.
>>>
>>> My current scheme requires the .env file to have \0 separating
>>> environment variables which is obviously not ideal. I am hoping we can
>>> find another way which is more textfile-friendly without losing the
>>> benefits.
>>
>> What about using \ as continuous line indicator and otherwise finish
>> the line, when parsing, wiht \0?
>
> Thanks for the suggestion. But that, along with the need for quotes,
> is one of the reasons I would like to provide a way to enter scripts
> naturally.
>
> Adding \ at the end of each line is error-prone and gets in the way.
> Python and C don't have this requirement - so why should U-Boot
> scripts?
>
> I wonder if we could define that 'xxx=' at the start of a line
> delineates a new variable?

The problem with this kind of thing is we might end doing a full
parser and doing a semantic interpret of the text. It seems to be way
too complex ...

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Simon Glass]

Hi Otavio,

On Tue, Apr 23, 2013 at 7:44 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Otavio,
>>
>> On Tue, Apr 23, 2013 at 7:14 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Tue, Apr 23, 2013 at 9:29 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Tom,
>>>>
>>>> On Tue, Apr 23, 2013 at 4:33 PM, Tom Rini <trini@ti.com> wrote:
>>>>> On Tue, Apr 23, 2013 at 02:32:00PM -0700, Simon Glass wrote:
>>>>>> Hi Wolfgang,
>>>>>>
>>>>>> On Tue, Apr 16, 2013 at 10:44 PM, Wolfgang Denk <wd@denx.de> wrote:
>>>>>> > Dear Simon Glass,
>>>>>> >
>>>>>> > In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>>>>>> >> At present U-Boot environment variables, and thus scripts, are defined
>>>>>> >> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>>>>>> >> to this file and dealing with quoting and newlines is harder than it
>>>>>> >> should be. It would be better if we could just type the script into a
>>>>>> >> text file and have it included by U-Boot.
>>>>>> >>
>>>>>> >> Add a feature that brings in a .env file associated with the board
>>>>>> >> config, if present. To use it, create a file in include/configs
>>>>>> >> with the same name as you could board config file, except with a
>>>>>> >> .env extension instead of a .h extension. The variables should be
>>>>>> >> separated by \0. Comments are permitted, using # as the first character
>>>>>> >> in a line.
>>>>>> >
>>>>>> > Please do not litter the include/configs/ directory with such stuff.
>>>>>> > It's more than big enough already.  Please put such files into the
>>>>>> > respective board directories.
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>> >
>>>>>> > And if you do something like this, then please go the way to the end.
>>>>>> > Forget about the \0 termination, make it a plain text file instead,
>>>>>> > something that can be used with "env import -t" as well (or created
>>>>>> > with "env export -t").
>>>>>>
>>>>>> I'm not sure how to do this. Doesn't this mean that we cannot add
>>>>>> multi-line scripts to the environment? That was part of my aim. But if
>>>>>> I put a 0x0a in the script then it will think we are starting a new
>>>>>> variable.
>>>>>
>>>>> The first thing that pops to mind is:
>>>>> 1) embedded the text file into a linker-known spot
>>>>> 2) Make part of the default env setup process be to env import -t that
>>>>> location in memory.
>>>>
>>>> Well I have a working implementation - my concern was more about how
>>>> to deal with newlines. I would like to be able to handle a script just
>>>> written out over multiple lines in a text file. This is really nice
>>>> because we can have proper indenting, comments, etc. As soon as we
>>>> have to use 0x0a as the separator between each environment variable
>>>> that is no longer possible.
>>>>
>>>> My current scheme requires the .env file to have \0 separating
>>>> environment variables which is obviously not ideal. I am hoping we can
>>>> find another way which is more textfile-friendly without losing the
>>>> benefits.
>>>
>>> What about using \ as continuous line indicator and otherwise finish
>>> the line, when parsing, wiht \0?
>>
>> Thanks for the suggestion. But that, along with the need for quotes,
>> is one of the reasons I would like to provide a way to enter scripts
>> naturally.
>>
>> Adding \ at the end of each line is error-prone and gets in the way.
>> Python and C don't have this requirement - so why should U-Boot
>> scripts?
>>
>> I wonder if we could define that 'xxx=' at the start of a line
>> delineates a new variable?
>
> The problem with this kind of thing is we might end doing a full
> parser and doing a semantic interpret of the text. It seems to be way
> too complex ...

I can do the above with a simple sed script.

Do you mean we might create a new type of parser? If so, then we could
perhaps use a .scr extension or similar. My idea here is specifically
for environment.

Regards,
Simon

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Otavio Salvador]

On Wed, Apr 24, 2013 at 12:05 AM, Simon Glass <sjg@chromium.org> wrote:
> On Tue, Apr 23, 2013 at 7:44 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Thanks for the suggestion. But that, along with the need for quotes,
>>> is one of the reasons I would like to provide a way to enter scripts
>>> naturally.
>>>
>>> Adding \ at the end of each line is error-prone and gets in the way.
>>> Python and C don't have this requirement - so why should U-Boot
>>> scripts?
>>>
>>> I wonder if we could define that 'xxx=' at the start of a line
>>> delineates a new variable?
>>
>> The problem with this kind of thing is we might end doing a full
>> parser and doing a semantic interpret of the text. It seems to be way
>> too complex ...
>
> I can do the above with a simple sed script.
>
> Do you mean we might create a new type of parser? If so, then we could
> perhaps use a .scr extension or similar. My idea here is specifically
> for environment.

I fully agree that the environment file should be as easy as possible
to be written. However I also think it should be parsed by CPP or
something which would allow us to 'include' other environment files
and enable/disable parts of it depending on board config. My ultimate
goal with it would be to allow sharing of environment setup across
different boards (for example the Freescale boards).

--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Simon Glass]

Hi Otavio,

On Tue, Apr 23, 2013 at 8:20 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Wed, Apr 24, 2013 at 12:05 AM, Simon Glass <sjg@chromium.org> wrote:
>> On Tue, Apr 23, 2013 at 7:44 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Tue, Apr 23, 2013 at 11:36 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Thanks for the suggestion. But that, along with the need for quotes,
>>>> is one of the reasons I would like to provide a way to enter scripts
>>>> naturally.
>>>>
>>>> Adding \ at the end of each line is error-prone and gets in the way.
>>>> Python and C don't have this requirement - so why should U-Boot
>>>> scripts?
>>>>
>>>> I wonder if we could define that 'xxx=' at the start of a line
>>>> delineates a new variable?
>>>
>>> The problem with this kind of thing is we might end doing a full
>>> parser and doing a semantic interpret of the text. It seems to be way
>>> too complex ...
>>
>> I can do the above with a simple sed script.
>>
>> Do you mean we might create a new type of parser? If so, then we could
>> perhaps use a .scr extension or similar. My idea here is specifically
>> for environment.
>
> I fully agree that the environment file should be as easy as possible
> to be written. However I also think it should be parsed by CPP or
> something which would allow us to 'include' other environment files
> and enable/disable parts of it depending on board config. My ultimate
> goal with it would be to allow sharing of environment setup across
> different boards (for example the Freescale boards).

Your wish may be granted, I think this is easy enough, and we can
support #defines, etc. as well.

Regards,
Simon

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Wolfgang Denk]

Dear Otavio Salvador,

In message <CAP9ODKpX_dFZ6K+frU6oamkQ3vKiYp9XYjaKX5Jn5PTq=0iyJQ@mail.gmail.com> you wrote:
>
> I fully agree that the environment file should be as easy as possible
> to be written. However I also think it should be parsed by CPP or
> something which would allow us to 'include' other environment files
> and enable/disable parts of it depending on board config. My ultimate
> goal with it would be to allow sharing of environment setup across
> different boards (for example the Freescale boards).

Don't overdesign this.  Keep it simple.  If you want, you can split up
the settings into several functional blocks (variable groups; this
could even be mapped into the actual U-Boot env, too).  Then simply
concatenate the right selection of parts.

See my previous message to Simon - keep the format compatible with
"env import/export -t".

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Today is the yesterday you worried about tomorrow.

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Smithlife]

Dies ist, was ich interessiert bin in.Welcome mich contace.



___________________________________________________
Diablo 3 Gold <http://www.mmobf.com/>  ; Aion Kinah
<http://www.mmobf.com/aion-kinah-566/>  ; Diablo 3 Gold Kaufen
<http://www.mmobf.com/>  ; GW2 Gold <http://www.mmobf.com/Guild-Wars-2/>  




--
View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-Allow-U-Boot-scripts-to-be-placed-in-a-env-file-tp152605p153394.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ0qqHab7md81XhQeY68EaJHa4VGPdVhz-Q=qPVZ99KCRw@mail.gmail.com> you wrote:
> 
> Do you mean we might create a new type of parser? If so, then we could
> perhaps use a .scr extension or similar. My idea here is specifically
> for environment.

Please do not invent yet another format, and yet another set of tools
around it.  I suggested this before:  Please use the very same simple
text format that is being used by "env import -t" and "env export -t".

Among other things, this provides an easy and elegant way both to
create the file (by using "env export" in a running system where you
could interactively develop and test your settings, and to verify the
settings using "env import" before actually compiling the code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Rob Herring]

On 04/17/2013 12:44 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
> 
> In message <1366155414-6525-1-git-send-email-sjg@chromium.org> you wrote:
>> At present U-Boot environment variables, and thus scripts, are defined
>> by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add large amounts of text
>> to this file and dealing with quoting and newlines is harder than it
>> should be. It would be better if we could just type the script into a
>> text file and have it included by U-Boot.
>>
>> Add a feature that brings in a .env file associated with the board
>> config, if present. To use it, create a file in include/configs
>> with the same name as you could board config file, except with a
>> .env extension instead of a .h extension. The variables should be
>> separated by \0. Comments are permitted, using # as the first character
>> in a line.
> 
> Please do not litter the include/configs/ directory with such stuff.
> It's more than big enough already.  Please put such files into the
> respective board directories.
> 
> And if you do something like this, then please go the way to the end.
> Forget about the \0 termination, make it a plain text file instead,
> something that can be used with "env import -t" as well (or created
> with "env export -t").

What about allowing a binary created with mkenvimage to be built-in.
This would give us a standard build rule to build a separate env binary
as well.

Rob

[U-Boot] [PATCH] Allow U-Boot scripts to be placed in a .env file

[Tom Rini]

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

On 05/06/2013 09:02 AM, Rob Herring wrote:
> On 04/17/2013 12:44 AM, Wolfgang Denk wrote:
>> Dear Simon Glass,
>> 
>> In message <1366155414-6525-1-git-send-email-sjg@chromium.org>
>> you wrote:
>>> At present U-Boot environment variables, and thus scripts, are
>>> defined by CONFIG_EXTRA_ENV_SETTINGS. It is painful to add
>>> large amounts of text to this file and dealing with quoting and
>>> newlines is harder than it should be. It would be better if we
>>> could just type the script into a text file and have it
>>> included by U-Boot.
>>> 
>>> Add a feature that brings in a .env file associated with the
>>> board config, if present. To use it, create a file in
>>> include/configs with the same name as you could board config
>>> file, except with a .env extension instead of a .h extension.
>>> The variables should be separated by \0. Comments are
>>> permitted, using # as the first character in a line.
>> 
>> Please do not litter the include/configs/ directory with such
>> stuff. It's more than big enough already.  Please put such files
>> into the respective board directories.
>> 
>> And if you do something like this, then please go the way to the
>> end. Forget about the \0 termination, make it a plain text file
>> instead, something that can be used with "env import -t" as well
>> (or created with "env export -t").
> 
> What about allowing a binary created with mkenvimage to be
> built-in. This would give us a standard build rule to build a
> separate env binary as well.

With CONFIG_ENV_IS_EMBEDDED you should be able to do this today since
it has to be at a certain spot within the binary, yes?

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRh6zKAAoJENk4IS6UOR1WOT0P/2B1UX74nij7Z+8NJtiA/Ak5
QZlQw/tk7afZCOYPOxLnun6OCH6irWEPykBvtHGa3ww3f2L/lt8Kk3VTZprhhvTz
+s8YzDgFRAzPPbVfA5KSI2PUS0exNjVbQ8/mA+h8tPZ6G3XBsJCrvNyf6zGRUQK9
kr+RrZFUor0Z5xMyTOmba0rkTIKPmGLu+YhUQmFqCM0+5sjP0D+zpN68s89FwVah
Vxuf2Li7QmDp3PLNJphUFb67Vw/+JUCP+TZ/yLnAZlBScxTfNXPBspOlU3CkK4Dl
NgmfwAnd1wp8QCERWQD/jXFhjGY21QbogIvxs4tQWJ0TUxQnrFnCaX6iCwSe+kBE
Aesn/g+NhgQaj3GPJi5SvOwF5gXZPxXzvtywtoIMKeAoNC46JSk1y0wde7xzh4VP
0zrXRqE3SXW1wPKsKEBBUbE5F/tHiE1PxK2SRo5zq0s2gsPFLo2HT4G1sxE1XxVR
nft0TJ8EGaZ9h5B/sg1HFoT6ezMcoKjy/X7zVyBgUChIta9eJAUIwqAK3XNqSwhK
m5aWCqXDe03zufZ9M1dn9yWoKu4esyPdPQzUHcRZnbpVtKNpNN9obkF3s/LBqYme
9qyIf6DNTxBSV4NHB6PAT7ltrO6jau5mqkINtElSII6mf7A1OLUNZ/jLdkee2M07
tvi2uk6coQPwGTKr06aS
=Bk9E
-----END PGP SIGNATURE-----