[U-Boot] [PATCH 1/4] Add option -r to env import to allow import of text files with CRLF as line endings

Stephen Warren swarren at wwwdotorg.org
Thu Aug 14 22:08:16 CEST 2014


On 08/14/2014 01:59 PM, Alexander Holler wrote:
> Am 14.08.2014 21:51, schrieb Stephen Warren:
>> On 08/14/2014 01:38 PM, Alexander Holler wrote:
>>> Am 14.08.2014 17:49, schrieb Stephen Warren:
>>>> On 08/14/2014 02:25 AM, Alexander Holler wrote:
>>>
>>>>> As I've just remembered where I did see your name before, the config
>>>>> for
>>>>> the rpi (as found in 2004.04) misses the uenvcmd. That's necessary to
>>>>> execute commands when using uEnv.txt.
>>>>>
>>>>> It's easily done with something like the following:
>>>>>
>>>>>                                 "env import -t -r $loadaddr
>>>>> $filesize;" \
>>>>>                                 "if test -n \"$uenvcmd\"; then " \
>>>>>                                         "echo \"Running uenvcmd
>>>>> ...\";" \
>>>>>                                         "run uenvcmd;" \
>>>>>                                 "fi;" \
>>>>
>>>> My intention was that uEnv.txt be used to set up environment variables,
>>>> not to allow its use for custom scripts.
>>>>
>>>
>>> Sure. In most cases changing the predefined available variables is
>>> enough. But it's a very hand option if someone wants or needs to do
>>> stuff which can't be done by just changing some environment variables
>>> (one never knows what ideas people will have).
>>
>> For such presumably non-standard things, why can't the user simply edit
>> $bootcmd, and pre-pend whatever they want?
>
> Depends on when the bootcmd will be constructed. Usually that is done
> after having read uEnv.txt to include variables defined in uEnv.txt in
> bootcmd. So whatever bootcmd one sets in uEnv.txt, it just will be
> overwritten.

What would over-write bootcmd? None of the boards I've looked at 
auto-generates bootcmd. bootargs perhaps (which is a string passed to 
the kernel) but not bootargs (which is a U-Boot command sequence that 
U-Boot executes automatically at boot).

If some board does auto-generate bootcmd, I'd suggest that it not. The 
static bootcmd could execute some kind of user-(or uenv-)set variable 
and/or the auto-generation of bootcmd could happen before uenv.txt was 
pulled in, so that whatever was in uenv.txt would have ultimate "power".


More information about the U-Boot mailing list