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

[Dennis Gilmore]

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]
> > > > The only way I could see having us write a file to disk with the
> > > > environment working is if all boards implement standard
> > > > variable to define the memory locations and that is compiled
> > > > into the u-boot binary.
> > > > 
> > > > some variables that would need to be compiled in 
> > > > 
> > > > fdt_addr
> > > > fdt_addr_r
> > > 
> > > Why two?
> > from cmd_pxe.c
> [snip]
> > u-boot by default would load a dtb to fdt_addr but a user could at
> > least in the pxe/extlinux case load their own dtb if the want/need
> > to.
> > 
> > the only way a dtb would be optional is if fdtfile is not set 
> 
> OK, so fdt_addr is for a memory-mapped location of the DT existing
> somewhere already, basically.

right, how that gets there would be up to the vendor. but distros
should put dtbs in a known place so that they can pulled from there.

> > > > 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.

> > 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

Dennis