[U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs

[Wolfgang Denk]

Dear Dennis,

In message <20131206180955.32ba9f0b at adria.ausil.us> you wrote:
> 
> > Yes, it appears some vendors favoured this name.  I'm temptted to add
> > that these very vendors often tend to define thier own ways without
> > caring what the community has been using before ;-)
> > 
> > That doesn't make it any better, though...
>
> Not saying that it does, just pointing out the inconsistency in the
> tree today. something we likely should fix.

Agreed, it would be nice, but it might turn out to be difficult.  I
think a large number of such systems is alreay out in the field, and
introducing such chnges to the user interface is often just impossible
or inacceptable.

We should keep in mind that - until not so long ago - no attempts have
been made to try to standardize these things, so we have now the
results of uncontrolled growth over 13 years or so.  Even though there
are a number of configuratios some of us would recommend as archetypes,
but again there are several "schools" of these, each with their own
approaches and names.

> > Even if you feel differntly, I do appreciate your efforts.  But I'd
> > also like to see things done in a consistent way.  And the whole idea
> > of using the "_r" names was to show clearly which of the addresses are
> > supposed to be in system RAM (with "_r"), and which are not (without).
...
> which makes some sense in the code, but the  config is defining the
> interface to kernel/userland and needs to be consistent regardless of
> what is underneath 

This is no contradiction, right?

> > > The only references i found was in README.falcon README.pxe and
> > > README.commands.spl based on your description it would mean falcon
> > > mode could not be implemented on any system not having nand.
> > 
> > I lost you here.  What makes you think so?
> Usage:
>
> spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
>
> which to me based on what you said means everything needs to be in nand

No.  First, SPL booting is not restricted to NAND.  We use this also
(at least on some systems) to boot from SDCard, and even to boot from
NOR flash.

Second, the "spl export" step is a pretty specific thing, that does not
really reflect the normal steps of booting a system - it makes
preparations to do so, but this is a different task.

> > > cmd_pxe.c clearly specifies what it thinks the addresses are for
> > 
> > Yes, it does.  But this is confused or incorrect, misusing existing
> > names for other purposes.  This should be fixed.
>
> I actually think it is spot on and is how it should be.

I continue to disagree.  The use of "fdt_addr" and "fdt_addr_r" in the
same context should stick with exising practice, and as I explained
before, "fdt_addr_r" then refers to an address in ROM (usually NOR
flash).

> > Stop.  There has never been any such notion like "system provided" or
> > "user provided" before.  You cannot just put new meanings over
> > existing terms.  Actually, to me such terms don't even make much
> > sense.
>
> from u-boot itself there is not this notion. But from a Distro
> perspective its always there and is a really big thing. It really is
> important. in 99% of cases we want to have u-boot use a provided dtb
> without the need to say so and to have it work. 

When introducing new terms into a new environment, you should make
sure to actually define the meaning of these terms, so everybody
speaks the same language.  Actually you would  pprobably have to start
with defining "system" (I feel you might actually mean "distro"
instead?) and "user".  There is a number of situations, which may (or
may not) result in differing usage modes.  In addition to "user" and
"distro" terms like "vendor" (or "manufacturer") or "developer" might
play a role here - each will probably result in specific expectations
and experiences about "good practices".

So please, define your terms, and as exact as possibvle, so we avoid
confusion when discussing them.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mistakes are often the stepping stones to utter failure.