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

[Tom Rini]

On Mon, Aug 05, 2013 at 12:11:47AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20130804214743.GJ5164 at bill-the-cat> you wrote:
> > 
> > > I am not that pessimistic.  The tools are all available and in place.
> > > "env import" (and other capabilities of the "env" command) allow to
> > > import any set of environment from any storage location U-Boot can
> > > handle.  This allows to implement all kind of fancy features, like
> > > "user profiles", "reset to factory defaults", etc. etc.  Of course it
> > > also allows to implement settings needed to support booting of a
> > > standard distribution.
> > 
> > How far back do we have an env import command available to all, is one
> > the questions. ...
> 
> The support for this was added with commit ea882ba "New implementation
> for internal handling of environment variables." on Sun Jun 20, 2010,
> i. e. more than 2 years ago.
> 
> That's a long time, actually.

But not long enough in some cases.  But a good point for a general
solution going forward.

> >            ...  I hadn't thought about saying part of the solution is
> > that distros should provide an environment file to import (and if
> > applicable, saveenv'ing after).  But what I mean is that we have a half
> > dozen (it feels like) semi-flexible environments different boards/socs
> > compile in, and it's not easy to share those.  One of the requests is a
> > "sane" default boot command, and we do have a number of boards out there
> > without a savable environment.
> 
> Requests for a "sane" environment are comprehensible.  However, it
> will be difficult to reach an agreement what exactly "sane" means
> here.  For example, I have never been able to get accustomed to all
> the uEnv.txt, user.txt etc. scripts used with a number of boards; for
> me, all this seems way too complicated and inflexible, and I always
> try to get rid of this stuff.  I'm aware that other people like the
> approach.  OK - I see no problems with that: TIMTOWTDI.
> 
> I would only have a problem (and a serious one) if such an approach
> became standard, or even mandatory.  Not to mention a large number of
> projects I know of.

Right.  This would be an agreement between us and the generic Linux
distros that want in about what "sane" means, in terms of enabling users
to get up and running.  We want the advanced users to be able to drop in
and do what they want to do in U-Boot but let the new users get to their
comfort ground (generic linux distro) without going crazy either.

> > > You mean, as an external tool, to translate extlinux.conf into a set
> > > of U-Boot commands?
> > 
> > No, I mean as a run-time command in u-boot to, given a pointer to
> > extlinux.conf in memory, translate to a set of boot commands.  The use
> > case here is that user installs (via package manager) a new kernel and
> > just like on your desktop you can chose to boot it, easily enough.
> 
> Can we not rather do the translation on the host side, so we don;t
> have to add both the code and the runtime overhead for each boot
> process?

It's debatable, yes.  As part of this, I'd like to leave the door open
so that for example the default experience is that whatever kernel the
user chose as the main kernel gets booted via falcon mode (so quick
boot) and on pressing c (or whatever) they get full U-Boot that would
(in this case of a generic linux distro, find all that is required to)
show up a menu for them to pick from (as they didn't interrupt the
autoboot command that would do all of this).

> > > Define "reference platform"?   Do you think, for example, systems in
> > > the class of TI's AM1808 or Freescale's i.MX28 are adequate targets to
> > > run Fedora?  Does Fedora actually support any targets below ARMv7 ?
> > 
> > Fedora (and Ubuntu) don't officialy support sub-v7 platforms but that
> > hasn't deterred the RPi community from making it happen all the same.
> > But yes, AM1808 and i.MX28 and anything else with community support, IOs
> > and upstream support is quite useful for maker folks (again, see RPi).
> > Debian, iirc, still supports ARMv5 out of the box, and I'm sure anything
> > that makes "Just Working" out of the box would be welcome in
> > OpenEmbedded/Yocto-land.
> 
> Well, OE and Yocto allow to build fine-tuned target environments; they
> really don't have any new requirements as "standard" distros like
> Fedroa do.

Yeah, and it's also true that less per machine hacking you have to do
with each new board, the easier it is (and the better the out of box
experience it is on their side).  We just synced up the environment on
wandboard with how OE likes to see it.  If it was instead they just had
to provide an environment text file in the machine overlay or even just
generate a default one (since the image is only going to have one kernel
most likely), it'd be a win on that side.

-- 
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/20130805/056dad9b/attachment.pgp>