On 08/14/2014 12:41 PM, Robert Nelson wrote:
On Thu, Aug 14, 2014 at 10:49 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 08/14/2014 02:25 AM, Alexander Holler wrote:
Am 31.07.2014 21:57, schrieb Stephen Warren:
Huh, I do see that now. I must have been looking at the content of common/cmd_nvedit.c from the wrong branch, which didn't include that patch. I could have sworn I checked git history too, but evidently not. It is indeed clearly there right before the patches which use it. Sorry for the noise.
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.
The check for if uenvcmd is set then run uenvcmd syntax, should really be pushed into the distro default stuff. As that syntax is used by default for a lot of different targets in u-boot. Most users who deal with u-boot (even if they don't want to) seem to understand it.
I don't think this is anything to do with distro defaults.
Distro defaults are intended to provide a single common interface between the bootloader and Linux/... distro. As such, locating and loading extlinux.conf fits the bill there. The whole idea is that distros/OSs wouldn't have to know anything about the bootloader at all; command script formats, etc.
uenv.txt is the opposite; it's very U-Boot specific, and more about internal implementation details of U-Boot. In particular, I only see a use-case for uenv.txt on systems that have nowhere to store the U-Boot environment other than in some filesystem. That's the reason the RPi port loads uenv.txt, so the environment can be modified somehow. Perhaps there's an ENV_IS_IN_FAT that could be used instead on the Pi? For example, none of the Tegra boards use uEnv.txt since "saveenv" to flash works there.
So, perhaps I could see providing include/common_bootenv.h to make the definition you wrote above common between boards, but I certainly would not expect that opting in to distro defaults automatically added support for uEnv.txt.