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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to