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

[Dan Murphy <dmurphy@ti.com>]

On 02/19/2014 01:38 PM, Stephen Warren wrote:
> On 02/19/2014 12:32 PM, Dan Murphy wrote:
>> On 02/19/2014 01:04 PM, Stephen Warren wrote:
>>> On 02/19/2014 11:59 AM, Dan Murphy wrote:
>>>> On 02/19/2014 12:57 PM, Stephen Warren wrote:
>>>>> On 02/19/2014 11:52 AM, Dan Murphy wrote:
> ...
>>>>>> If no config file exists should we not try to default to a known good default tested case?
>>>>> I believe always loading a script/config-file is the simplest and most
>>>>> flexible approach, for a *distro* *oriented* boot process.
>>>>>
>>>>> Now, specific U-Boot board configs can always add extra stuff on the end
>>>>> (or start?) of bootcmd in order to do some custom fallbacks or
>>>>> backwards-compatibility if they want, but I'm certainly not planning on
>>>>> doing anything like that for Tegra or Raspberry Pi, for example.
>>>> Yeah I am not seeing how the board config can do that if there is no provisions in the common file.
>>> Presumably all it needs is an extra hook/variable that is added to the
>>> start/end of bootcmd. Should be pretty easy to add in a future patch
>>> rev, or followon patch.
>> <snip>
>>
>> I am not sure it is that simple.  Once you are in the BOOTCMD macro's if you end up back at the board file macros
>> you kinda have to repeat the load steps again just to get the args or specifics set.
>>
>> When the loading of the ENV file fails but the loading of the other images succeeds maybe something as simple as
>>
>> "run board_cfg"  Which can be a fall back to a board file specific configuration macro for whatever you want.
>>
>> If you don't need it then it is NULL
> If the value of bootcmd was customizable, then you could easily add e.g.
> "nand_custom" as the last entry in it, and that could do whatever was
> appropriate (it would translate to run bootcmd_nand_custom, which the
> board would define). That'd work very consistently with all the other
> options.

Well is this not what the BB patch does is calls upon the common boot_cmd and if that
fails then comes back to the board config to run nand_boot?

This does not really solve any of my issue of not having (or realizing I need) a script for boot on the boot partition.
No default case here to rely on as an in tree solution.

Dan

> Eventually, I'd love to have a BIOS-like (runtime) config menu, where
> any variable named bootcmd_* would show up in the list, and provide an
> interactive way to re-order and enable/disable all the options, i.e. an
> interactive menu-driven editor for the value of $bootcmd. If custom
> options get implemented the same way as the standard options, then the
> custom options would integrate very well into that scheme.


-- 
------------------
Dan Murphy