On Thu, Aug 01, 2013 at 12:19:13PM -0500, Rob Herring wrote: > On 08/01/2013 03:53 AM, Stefano Babic wrote: > > Hi Dennis, > > > > On 01/08/2013 01:27, Robert Nelson wrote: [snip] > >> #define CONFIG_BOOTCOMMAND \ > >> "mmc dev ${mmcdev};" \ > >> "if mmc rescan; then " \ > >> "echo SD/MMC found on device ${mmcdev};" \ > >> "if run loadbootenv; then " \ > >> "run importbootenv;" \ > >> "fi;" \ > >> "if test -n $uenvcmd; then " \ > >> "echo Running uenvcmd ...;" \ > >> "run uenvcmd;" \ > >> "fi;" \ > >> "if run loadsomefailsafedefault; then " \ > >> "run mmcboot;" \ > >> "fi;" \ > >> "fi;" > >> #endif > > That really works great on boards that don't have SD...
Don't lose the forest for the trees. A "try and import stuff from easy/prominent storage" is true for most boards, be it SD or SATA or NAND or ... > > >> > > > > Right - the meaning of CONFIG_EXTRA_ENV_SETTINGS is to have a minimal > > default environment, allowing the user to extend it to a full blown > > adding whatever he wants. However, in the last times I see that the > > meaning is moving to *the environment*. There is something wrong, also > > because, as Robert says, each small change require to patch u-boot. But > > then, why do you need the environment at all ? > > > > And the setup is then suitable for a strict range of applications, but > > not all. > > You both are missing the point. This patch doesn't address the problem, > but does highlight it. The distros want to get out of having to know the > u-boot environment details for every single board and need some level of > standardization across platforms. The distros should only have to > specify "boot the kernel at path/name X on device Y." They should not > need to know what address to load the kernel to, but only that > $kernel_addr_r is already setup. Variables are the first step. The > second step is standardizing the boot commands. At the high level, right. But I think we need to know what the distros need / what, and come up with an opt-in setup that works for both parts (if a board follows the rules, it should easily work with whatever distros provide feedback, if it doesn't then it might not, and boards that care can opt-in and those that won't, can stay out). -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot