[U-Boot] [PATCH] wandboard: add pxe support, set default boot command like highbank

[Tom Rini <trini@ti.com>]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130804/210ecd44/attachment.pgp>