From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Murphy Date: Wed, 19 Feb 2014 14:03:00 -0600 Subject: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work. In-Reply-To: <53050837.3050102@wwwdotorg.org> References: <1392659798-1665-1-git-send-email-dennis@ausil.us> <1392659798-1665-2-git-send-email-dennis@ausil.us> <5304FB87.3020208@ti.com> <5304FC99.8070009@wwwdotorg.org> <5304FD57.3040508@ti.com> <5304FE7E.2060805@wwwdotorg.org> <5304FEF9.1030104@ti.com> <5305002C.8050905@wwwdotorg.org> <530506B5.20505@ti.com> <53050837.3050102@wwwdotorg.org> Message-ID: <53050DF4.3060706@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. >> >> >> 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