[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Stephen Warren]

On 02/22/2014 01:20 AM, Dennis Gilmore wrote:
> On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 02/17/2014 10:56 AM, Dennis Gilmore wrote:

>>> diff --git a/include/config_distro_bootcmd.h

>>> +#define BOOTCMDS_COMMON \
>>> +	"rootpart=1\0" \
>>
>> We should really stop hard-coding that. I meant to (but evidently
>> never got around to) re-write the commands so that they could
>> automatically determine which partition to use, based on the MBR
>> bootable flag or GPT partition flags.
>>
>> Still, we can probably make that enhancement separately later.
> 
> I fully agree, we should be able to work it out later. I also renamed
> it to bootpart since it is where we will boot from, which may or may
> not be the root filesystem

Just as some history, when I first wrote these boot scripts for Tegra, I
was actually using that variable both inside the environment scripts to
find/load boot.scr, and within boot.scr to set the kernel root=
command-line option. More recently, I've moved to using root=PARTUUID=
or root=UUID= on the kernel command-line, so rootpart has become less
relevant, and indeed renaming it bootpart does make a lot more sense, as
you say.

>>> +	"scan_boot="
>>> \
>>> +		"echo Scanning ${devtype} ${devnum}...;
>>> "                 \
>>> +		"for prefix in ${boot_prefixes}; do
>>> "                     \
>>> +			"run sysboot_boot;
>>> "                              \
>>> +			"run envimport;
>>> "                                 \
>>> +			"run script_boot;
>>> "                               \
>>
>> This isn't quite right for the Raspberry Pi at least.
>>
>> What I wanted was for uEnv.txt to *always* be loaded from SD card
>> before any other boot activity. The SD card is known to exist on this
>> platform, since it's the only place the SoC's boot ROM can load the
>> initial binary firmware from.
> 
> I know some distros use commands in uEnv.txt to boot, or at the least
> they set variables and load a boot.scr I was trying to make sure we
> cover those people. The definition of what uEnv.txt is and how it
> should be used is pretty murky to me. I have seen it used in a few
> different ways. I know some people really want them. So probably best
> to work out a better way to support it.
> http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript
> for instance specifies all the boot commands in uEnv.txt really I would
> rather people just use a extlinux.conf file, I just do not want to take
> away the option to use something people see as valuable.

I'd suggest not touching uEnv.txt in config_distro_bootcmd.h, since it's
really not a part of the new standard we want to create. Instead, have
each board define CONFIG_PREBOOT to load it if they want it. I assume
that a very small number of boards will need uEnv.txt once we've
switched to this new scheme; just those that have nowhere to store a
persistent environment.