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

[Dennis Gilmore]

On Thu, 8 Aug 2013 11:26:37 -0400
Tom Rini <trini at ti.com> wrote:

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

I really don't want to ship environment files. If we need to we need
one of a few things. either u-boot needs to ship them and they are in
a directory with a name matching the dtb, or we need to have a bunch of
variables provided that enable us to load everything supported by the
u-boot binaries.

We as distros have no business needing to deal with memory locations.
it really is one of the biggest pain points with u-boot.

Dennis