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

Tom Rini trini at ti.com
Thu Aug 8 17:26:37 CEST 2013


On Wed, Aug 07, 2013 at 06:04:23PM -0500, Dennis Gilmore wrote:
> On Wed, 7 Aug 2013 09:19:21 -0400
> Tom Rini <trini at ti.com> wrote:
> 
> > On Tue, Aug 06, 2013 at 06:11:25PM -0500, Dennis Gilmore wrote:
> > > On Tue, 6 Aug 2013 17:42:31 -0400
> > > Tom Rini <trini at ti.com> wrote:
> > > 
> > > > On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
> > > > > kernel_addr_r
> > > > > ramdisk_addr_r
> > > > > pxefile_addr_r
> > > > > scr_addr_r
> > > > > uenv_addr_r
> > > > > 
> > > > > this should allow for for people to use boot.scr uEnv.txt or
> > > > > pxe/extlinux 
> > > > 
> > > > This is what I think we need to work towards.  A board opting into
> > > > this standard must set CONFIG_CMD_A/B/C (or maybe we add a
> > > > CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the
> > > > fallback files, whatever) and provide the following variables
> > > > PLUS a, and this needs some thinking I think, auto-boot tries to
> > > > load said file from ... ?
> > > > 
> > > > We cannot provide a built-in environment that works for every
> > > > distro and case, we want the distro to tell us things it knows,
> > > > and we'll tell it what it can't easily know.
> > > 
> > > we absolutely can, I would like for u-boot to load a dtb before
> > > doing anything. u-boot should know what devices can be booted from
> > > and likely an order of preference. i.e. removable media through to
> > > fixed, and finally pxe. 
> > 
> > Looking at a couple of device trees, no, we can't.  I don't see any
> > useful information like "this is an SD controller" for example (and
> > all of the mmc bindings that might provide a reliable clue are
> > optional ones).  So, at the high level, if U-Boot relied on DTs in
> > every driver, we might be able to do what you're talking about.  But
> > we don't do that today, and probably won't for a long time, if ever.
> > 
> > But we will know what devices are likely to exist and be bootable, at
> > build time.  What we can do is try and load a file from everywhere we
> > expect might be someplace with this file in it.  We could even set
> > some standard variables based on having found and loaded this file,
> > so it can assume that everything else exists in this same place (or
> > the file we have loaded knows better).
> 
> I was thinking more along the lines of us knowing what is likely to be
> there than pulling it from the DT and basically doing something like
> you mentioned here.

Right.  For clarity, the problem is that DTs aren't useful like that.
They describe the hardware, but in non-generic terms.

> > > i would like for u-boot to first try to
> > > load /boot/extlinux/extlinux.conf then /extlinux/extlinux.conf 
> > > failing that try to load a /boot/uEnv.txt then /uEnv.txt and import
> > > that running with what is in it, then falling back to
> > > a /boot/boot.scr then /boot.scr then finally running dhcp, pxe get,
> > > and pxe boot.
> > 
> > I'd like to see most of that logic held in the file we load (so that
> > when something replaces extlinux.conf as the preferred method, it just
> > works still, or whatever) and run a command from.  And fall back to
> > dhcp+pxe for the install case.
> 
> where should the file we load come from? i would think when something
> comes along to replace extlinux.conf its likely going to need an
> updated u-boot to add some new functionality

I'd like to see the file come from the distro.  And given that another
option here is 'go'ing to a copy of GRUB, I think we've got at least a
good chance of future expansion being handled OK with this method.  We
try and load something from the distro that is generic, and make the
hand-off there.  (In the GRUB example, we just need to make sure we have
a standard name for the standalone app load address).

-- 
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/20130808/a15aa50b/attachment.pgp>


More information about the U-Boot mailing list