Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hello, On Sat, Oct 26, 2013 at 3:01 AM, Simon Glass s...@chromium.org 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 a board/vendor/env directory called board.env (or common.env if you want the same environment for all boards). The environment variables should be of the form var=value. Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. Comments are not permitted in the environment with this commit. Signed-off-by: Simon Glass s...@chromium.org I think people (or myself) are misunderstanding what this patch does. My understand is: - it allow moving environment setting to a .env file - it needs to include the environment at /build/ time This does improve a lot the current status (and I really appreciate it); one missing thing (or I missed it completely) is a way to: - build u-boot (binary) - generate a binary version of the environment - glue both together in a way the new environment /replaces/ the default environment originally written inside u-boot (binary) Am I missing something? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hi Wolfgang,
On Sat, Oct 26, 2013 at 2:26 PM, Wolfgang Denk w...@denx.de wrote:
Dear Simon,
In message 1382763695-2849-4-git-send-email-...@chromium.org you wrote:
+For example, for snapper9260 you would create a text file called
+board/bluewater/env/snapper9260.env containing the environment text.
+
+
+bootcmd=
+ if [ -z ${tftpserverip} ]; then
+ echo Use 'setenv tftpserverip a.b.c.d' to set IP address.
+ fi
+
+ usb start; setenv autoload n; bootp;
+ tftpboot ${tftpserverip}:
+ bootm
+failed=
+ echo boot failed - please check your image
+
+
+The resulting environment can be exported and importing using the
+'env export/import -t' commands.
I think this statement is misleading. It reads as if thois text coul
actually be imported using env import -t, which is not correct. And
the result of an env export -t of equivalent command settings will
look pretty much different, too.
The point here is that it is possible to export the default
environment that has been created at build time. Agreed this should be
worded better.
I can see why you like such a beautified text format, but I don;t
think you are doing anybody a favour here. Can we not rather use
_exactly_ the same text format as U-Boot uses with it's import /
export commands?
That would be nice, but how to we handle newlines? Some scripts are
quite long. Do we need to put \ at the end of every line? That feels a
bit painful to me.
Also how do we handle #define? Without it I don't think this feature
is useful, since the existing build system often sticks CONFIG
variables into the environment.
This would make it _much_ easier to experiment on a system and modify
the environment until it fits all the requirements and passes all
tests, and then export it as a text file and use this directly
(without editing) for the input needed here?
I believe that is already possible - you should be able to take the
output of 'env export -t' and put it in the .env file. I have not
tried it though.
...
--- /dev/null
+++ b/tools/scripts/env2string.awk
@@ -0,0 +1,48 @@
+#
+# (C) Copyright 2013 Google, Inc
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Sed script to parse a text file containing an environment and convert it
+# to a C string which can be compiled into U-Boot.
That doesn't look like sed to me, looks more like awk :-)
Hmm, yes I gave up on sed after a while. Will fix.
+ # Is this the start of a new environment variable?
+ if (match($0, ^([^ =][^ =]*)=(.*), arr)) {
I think this is a bit naive...
Example (using notation as exported by U-Boot using env export -t):
foo=setenv xxx\
one=1;setenv yyy\
two=2;setenv zzz\
three=3
+ # Print out all the variables
+ for (var in vars) {
+ print var = vars[var] \\0;
+ }
I think it should not be difficult to find examples that would result
incorrect output.
I will take a look at this - here it is the \ at the end of line which
needs to be handled.
I guess this needs more work - but then - why define a new format at
all? Why not use what U-Boot uses itself?
See above, would be good to resolve this issue before going any further.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hi Otavio, On Mon, Oct 28, 2013 at 7:34 AM, Otavio Salvador ota...@ossystems.com.br wrote: Hello, On Sat, Oct 26, 2013 at 3:01 AM, Simon Glass s...@chromium.org 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 a board/vendor/env directory called board.env (or common.env if you want the same environment for all boards). The environment variables should be of the form var=value. Values can extend to multiple lines. See the README under 'Environment Variables:' for more information and an example. Comments are not permitted in the environment with this commit. Signed-off-by: Simon Glass s...@chromium.org I think people (or myself) are misunderstanding what this patch does. Possibly, I'm not sure. My understand is: - it allow moving environment setting to a .env file - it needs to include the environment at /build/ time Yes This does improve a lot the current status (and I really appreciate it); one missing thing (or I missed it completely) is a way to: - build u-boot (binary) - generate a binary version of the environment - glue both together in a way the new environment /replaces/ the default environment originally written inside u-boot (binary) Am I missing something? This is something that Wolfgang would like to see (as would I), but I think it is a separate feature. This feature is just trying to simplify creation of the build-time default environment. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Dear Simon,
In message CAPnjgZ0+35Zd6_o=G0=g-yl_mr-gitw+meyqk7bsxu_nvkv...@mail.gmail.com
you wrote:
I can see why you like such a beautified text format, but I don;t
think you are doing anybody a favour here. Can we not rather use
_exactly_ the same text format as U-Boot uses with it's import /
export commands?
That would be nice, but how to we handle newlines? Some scripts are
quite long. Do we need to put \ at the end of every line? That feels a
bit painful to me.
Agreed. But that's what env export -t creates anyway (and I cannot
think of a much better presentation of multiline variable content if
you don't want to run in ambiguities).
Also how do we handle #define? Without it I don't think this feature
is useful, since the existing build system often sticks CONFIG
variables into the environment.
I don't understand this question here. I agree that we should be able
to run the file through the preprocessor such that it can resolve such
macro definitions. But this should be independent of the actual text
format, or am I missing something?
I believe that is already possible - you should be able to take the
output of 'env export -t' and put it in the .env file. I have not
tried it though.
Hm... I really think we should agree on a common format her e- one
that is easy to work with on both sides.
Example (using notation as exported by U-Boot using env export -t):
foo=setenv xxx\
one=1;setenv yyy\
two=2;setenv zzz\
three=3
+ # Print out all the variables
+ for (var in vars) {
+ print var = vars[var] \\0;
+ }
I think it should not be difficult to find examples that would result
incorrect output.
I will take a look at this - here it is the \ at the end of line which
needs to be handled.
Well, I can't see how you avoid such ambiguities in your proposed
format. You need a clear termination for the value of a variable.
If it is spread across multiple lines, you have to find a way to mark
continuation lines. The accepted standard way to do so is by using
a backslash at the end of the line. It appears you want to use
indentation instead - this prevents users from using a free text
format, and quickly becomes messy. And it is incompatible to
(current) U-Boot code.
I guess this needs more work - but then - why define a new format at
all? Why not use what U-Boot uses itself?
See above, would be good to resolve this issue before going any further.
Above I cannot see any explanation why you define a new format
except for the fact that the backslash as marker for continuation
lines is painful. I'm open on discussing a new format for text
representation (which then also should be used by env print and env
export -t ?). But I'd like to see a description of that format
first (and not just a few examples I can guess from).
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: w...@denx.de
Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former. -- Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Hi Wolfgang,
On Mon, Oct 28, 2013 at 3:16 PM, Wolfgang Denk w...@denx.de wrote:
Dear Simon,
In message CAPnjgZ0+35Zd6_o=G0=
g-yl_mr-gitw+meyqk7bsxu_nvkv...@mail.gmail.com you wrote:
I can see why you like such a beautified text format, but I don;t
think you are doing anybody a favour here. Can we not rather use
_exactly_ the same text format as U-Boot uses with it's import /
export commands?
That would be nice, but how to we handle newlines? Some scripts are
quite long. Do we need to put \ at the end of every line? That feels a
bit painful to me.
Agreed. But that's what env export -t creates anyway (and I cannot
think of a much better presentation of multiline variable content if
you don't want to run in ambiguities).
I believe the ambiguities are pretty rare. And people tend to indent
multi-line scripts anyway, right?
Also how do we handle #define? Without it I don't think this feature
is useful, since the existing build system often sticks CONFIG
variables into the environment.
I don't understand this question here. I agree that we should be able
to run the file through the preprocessor such that it can resolve such
macro definitions. But this should be independent of the actual text
format, or am I missing something?
Yes we can, agreed. I was thinking you would not want the preprocessor
since 'env export -t' doesn't understand it.
I believe that is already possible - you should be able to take the
output of 'env export -t' and put it in the .env file. I have not
tried it though.
Hm... I really think we should agree on a common format her e- one
that is easy to work with on both sides.
Agreed.
Example (using notation as exported by U-Boot using env export -t):
foo=setenv xxx\
one=1;setenv yyy\
two=2;setenv zzz\
three=3
+ # Print out all the variables
+ for (var in vars) {
+ print var = vars[var] \\0;
+ }
I think it should not be difficult to find examples that would result
incorrect output.
I will take a look at this - here it is the \ at the end of line which
needs to be handled.
Well, I can't see how you avoid such ambiguities in your proposed
format. You need a clear termination for the value of a variable.
If it is spread across multiple lines, you have to find a way to mark
continuation lines. The accepted standard way to do so is by using
a backslash at the end of the line. It appears you want to use
indentation instead - this prevents users from using a free text
format, and quickly becomes messy. And it is incompatible to
(current) U-Boot code.
Indentation is pretty normal in code, so I don't feel embarrassed about
asking for it. I think the primary problem with my feature is that it is
different from 'env export -t', and thus potentially introduces another
format. My argument against that interpretation is that I am in fact
replacing a C header file definition with a text file, so perhaps I'm not
really increasing the number of formats?
I guess this needs more work - but then - why define a new format at
all? Why not use what U-Boot uses itself?
See above, would be good to resolve this issue before going any further.
Above I cannot see any explanation why you define a new format
except for the fact that the backslash as marker for continuation
lines is painful. I'm open on discussing a new format for text
representation (which then also should be used by env print and env
export -t ?). But I'd like to see a description of that format
first (and not just a few examples I can guess from).
From my commit message:
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.
Well yes I could adjust 'env export -t' to use the same format - is that a
good idea, or not? I can see down-sides. We can of course convert existing
files brought in by 'env import -t' (by making the import flexible) but I
worry that there might be external tools that users have which expect the
format to be a certain way.
I agree creating a new format is not ideal - it's just that the existing C
header format is so painful...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Dear Simon, In message capnjgz3tgwrk2ytm59ekumaipd5kaq39mu9bityl0y6d0h2...@mail.gmail.com you wrote: Agreed. But that's what env export -t creates anyway (and I cannot think of a much better presentation of multiline variable content if you don't want to run in ambiguities). I believe the ambiguities are pretty rare. And people tend to indent multi-line scripts anyway, right? Do they? In the current include/config/*.h files, there is basically zero structuring of the environment as nobody has been using multi-line variables yet. Yes, there is indentation in the header files, but this is not visible at all in the environment variables. I don't understand this question here. I agree that we should be able to run the file through the preprocessor such that it can resolve such macro definitions. But this should be independent of the actual text format, or am I missing something? Yes we can, agreed. I was thinking you would not want the preprocessor since 'env export -t' doesn't understand it. Well, of course it deosn't, as it cannot invert the operation of the C preprocessor... But we can still use the prepro to create output that is digestable to env import -t, right? Well, I can't see how you avoid such ambiguities in your proposed format. You need a clear termination for the value of a variable. If it is spread across multiple lines, you have to find a way to mark continuation lines. The accepted standard way to do so is by using a backslash at the end of the line. It appears you want to use indentation instead - this prevents users from using a free text format, and quickly becomes messy. And it is incompatible to (current) U-Boot code. Indentation is pretty normal in code, so I don't feel embarrassed about asking for it. I think the primary problem with my feature is that it is different from 'env export -t', and thus potentially introduces another format. My argument against that interpretation is that I am in fact replacing a C header file definition with a text file, so perhaps I'm not really increasing the number of formats? Well, I'm afraid you have not yet formally defined the syntax of your format, so I may just misunderstand what you mean. Well yes I could adjust 'env export -t' to use the same format - is that a good idea, or not? I can see down-sides. We can of course convert existing files brought in by 'env import -t' (by making the import flexible) but I worry that there might be external tools that users have which expect the format to be a certain way. Are there any such tools? Anybodyu who is using such please speak up now and here! ;-) I agree creating a new format is not ideal - it's just that the existing C header format is so painful... Yes, I agree on that, and I'm more than willing to get rid of it. But it has to be something that is actually working, and that is easy to work with. --485b3970d160c06fb304e9d48797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable div dir=3DltrHi Wolfgang,brbrOn Mon, Oct 28, 2013 at 3:16 PM, Wolfg= ang Denk lt;a href=3Dmailto:w...@denx.de;w...@denx.de/agt; wrote:brgt= ... Argh... can you please turn this off? 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: w...@denx.de I have never understood the female capacity to avoid a direct answer to any question. -- Spock, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] Allow U-Boot scripts to be placed in a .env file
Dear Simon,
In message 1382763695-2849-4-git-send-email-...@chromium.org you wrote:
+For example, for snapper9260 you would create a text file called
+board/bluewater/env/snapper9260.env containing the environment text.
+
+
+bootcmd=
+ if [ -z ${tftpserverip} ]; then
+ echo Use 'setenv tftpserverip a.b.c.d' to set IP address.
+ fi
+
+ usb start; setenv autoload n; bootp;
+ tftpboot ${tftpserverip}:
+ bootm
+failed=
+ echo boot failed - please check your image
+
+
+The resulting environment can be exported and importing using the
+'env export/import -t' commands.
I think this statement is misleading. It reads as if thois text coul
actually be imported using env import -t, which is not correct. And
the result of an env export -t of equivalent command settings will
look pretty much different, too.
I can see why you like such a beautified text format, but I don;t
think you are doing anybody a favour here. Can we not rather use
_exactly_ the same text format as U-Boot uses with it's import /
export commands?
This would make it _much_ easier to experiment on a system and modify
the environment until it fits all the requirements and passes all
tests, and then export it as a text file and use this directly
(without editing) for the input needed here?
...
--- /dev/null
+++ b/tools/scripts/env2string.awk
@@ -0,0 +1,48 @@
+#
+# (C) Copyright 2013 Google, Inc
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Sed script to parse a text file containing an environment and convert it
+# to a C string which can be compiled into U-Boot.
That doesn't look like sed to me, looks more like awk :-)
+ # Is this the start of a new environment variable?
+ if (match($0, ^([^ =][^ =]*)=(.*), arr)) {
I think this is a bit naive...
Example (using notation as exported by U-Boot using env export -t):
foo=setenv xxx\
one=1;setenv yyy\
two=2;setenv zzz\
three=3
+ # Print out all the variables
+ for (var in vars) {
+ print var = vars[var] \\0;
+ }
I think it should not be difficult to find examples that would result
incorrect output.
I guess this needs more work - but then - why define a new format at
all? Why not use what U-Boot uses itself?
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: w...@denx.de
One essential to success is that you desire be an all-obsessing one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
