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

[Tom Rini]

On Sat, Aug 10, 2013 at 03:50:45PM -0500, Dennis Gilmore wrote:
> 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.

Don't think of them as environment files then.  Think of them like the
glue you need to spit out on x86 to get your stuff loaded, like with any
other loader.  And yes, I agree, we'll provide consistent variables that
you can rely on, well, like we do today for the whole PXE menu thing to
work.  But you're putting more of a constraint on U-Boot than you do on
x86 (unless you're going to make everyone boot directly from uefi
shells, rather than gummiboot moving forward :)) so you'll need to
provide a bit more, to future-proof things.

-- 
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/20130812/5abd9e58/attachment.pgp>