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

[Tom Rini]

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.

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

-- 
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/20130807/3d8348dc/attachment.pgp>