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. 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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
