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

[Simon Glass]

Hi Stephen,

On Wed, Jun 26, 2013 at 1:56 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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).

[well perhaps it is time to get back to this]

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

I find symlinks a pain in the source tree. I think they should be the
exception rather than the rule. This feature hear mirrors the current
board/<vendor>/common directory which is fairly widely used.

$ ls board/*/common -d |wc -l
21

I feel that Compulab can do their own common file if they want it. A
file common to all Tegra perhaps belongs in arch/arm/.. somewhere?

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

Yes I will separate it. I agree it's a bit icky in that if someone
manually deletes one file they may not get the other. The speed-up is
small.

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

The match string is a little more basic than that since there are few
restrictions on environment variable names as far as I know:

"^([^ =][^ =]*)=(.*)"

I'll add some more details to the commit message - but the idea is to
indent your environment to avoid problems.

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

I'll improve that comment.

Regards,
Simon