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

[Dennis Gilmore]

On Tue, 06 Aug 2013 13:37:51 +0200
Wolfgang Denk <wd at denx.de> wrote:

> Dear Rob Herring,
> 
> In message
> <CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q at mail.gmail.com>
> you wrote:
> >
> > > Why would you ever want to compile this into U-Boot at all?  Then
> > > any changes you need to make mean compiling and installing a new
> > > U-Boot, which is something you normally don't want to do.
> > 
> > You may want to have factory default and "user" settings. Building
> > in the factory settings would be one way to accomplish that.
> 
> No. Handling these independently, outside of the compiled U-Boot image
> is as easy, and much more flexible.
How exactly should it be handled outside of the compiled u-boot image.
with my distro hat on, I honesty do not want to deal with u-boot at
all. The limit of my dealing with u-boot will be to run a script that
installs the u-boot binary onto disk for those systems that don't have
it in nand/nor/spi etc flash storage. 

In my mind you are talking about some file I need to write to disk that
gets loaded at boot time. the problem with this is its not flexible nor
portable. I honestly think one of the worst thing hardware vendors ever
did was to ship hardware that doesn't have anywhere built into it to
load and run u-boot from.

My issue with this is, we produce a unified image, it could be an
installer image or a installed disk image. it has a unified kernel in
it and can run on any number of soc's but we also need to provide
tooling that will setup the u-boot image so that it can be loaded by
different boards. be it copying files into place or dding the binary
into some offset. it kills the portability. i can't pull a sdcard from
one board with one type of soc and plug it into another and have it
just boot.

> > > U-Boot is perfectly able to import such settings from text files
> > > (or text blobs stored somewhere, even attached to the U-Boot
> > > image, if you want), so just use the text files separately,
> > > instead of hard compiling them into the code.
> > 
> > In my case, I don't want to compile the environment into u-boot. But
> > some people do as I copied my scripts from Tegra which has them
> > built-in. Since built-in is C and standalone is text file, sharing
> > is impossible. That is the main thing I'd like to see changed.
> > Whether we support merging builtin and standalone envs is secondary.
> 
> Who says "impossible" here?  When using a file system with write
> support, you can use "env export -t" to create a text representation
> and write it out to the file system (or store it in some reserved area
> on some storage device).
Exactly what i want to avoid. I really do want it compiled into the
binary. because then I only have to put one file into place. on those
systems needing it.

another solution for me would be a unified u-boot that runs on all
soc's and all boards. Everytime we have to do something different for a
board or soc family is a step away from having something truly
universal and portable.

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

Dennis