On 06/24/2013 02:46 PM, Simon Glass 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).
I'm not entirely sure how useful common.env is.
Consider that many different Tegra boards, from different vendors, all share the same environment. For example boards/compulab/trimslice shares the core environment with boards/nvidia/*. IIUC, common.env wouldn't work in this case, since the vendor is different. To solve that, we could easily symlink board/compulab/env/trimslice.env -> board/nvidia/env/something.env. But in that case, why not always rely on creating symlinks, instead of having the common.env fallback work too? Also consider that compulab makes a ton of boards only some of which use Tegra, so even a common.env in board/compulab/env wouldn't be that useful.
diff --git a/Makefile b/Makefile
+$(obj)include/generated/environment.inc: $(obj)include/generated/environment.in
- @$(XECHO) Generating $@ ; \
- set -e ; \
- : Process the environment file ; \
- echo -n "CONFIG_EXTRA_ENV_TEXT=" >$@ ; \
- echo -n "#define CONFIG_EXTRA_ENV_TEXT " >$(ENV_HEADER) ; \
- awk -f tools/scripts/env2string.awk $< | \
tee -a $(ENV_HEADER) >>$@ ; \
That generates two different files. Doesn't this confuse make a bit, since if make needs to create $(ENV_HEADER) (which isn't $@ for that rule) it won't know how to? I've certainly seen problems due to similar make setups in the past. Perhaps even though it's a bit extra build-time work, the two files should be generated separately? Or, is there some reason here that there won't be a problem?
diff --git a/README b/README
+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
+<<<
Presumably the parser looks for something like /^[A-Z]=/i to know when to "switch" to a new environment variable. Is some form of escaping useful if you want to include that form of text in your environment variable's value? If the parser is somehow smarter than that, it might be worth explaining the syntax structure a little more above.
diff --git a/tools/scripts/env2string.awk b/tools/scripts/env2string.awk
+# We begin and end with "
I'm not sure what the " means at the end of that line.