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

[Wolfgang Denk <wd@denx.de>]

Dear Tom,

In message <20131206162854.GX420@bill-the-cat> you wrote:
> 
> > But this is crap. The meaning of these variables has been wel-defined
> > for a long, long time.  "fdt_addr" is the FDT address in NOR flash (or
> > similar memory except system RAM); "fdt_addr_r" is the FDT address
> > when loaded to system RAM (hence the "_r" in the variable name).
> 
> It's a well defined and widely ignored in ARM convention then.  We've
> got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both
> ARM and PowerPC 'fdtaddr' being presumably RAM.

I think it's actually OK to omit the "_r" in NOR-less systems.  The
number of devices with actual NOT flash is decreasing, and if you can
be sure that there is no such memory device available, then it is
just overhead to always carry the "_r" suffice around, knowing all
the time that there will never be any other option than RAM to store
that data.

I do not complain if such systems use a simplified setup without the
"_r".

What I don't like to see is to have "fdt_addr_r" and "fdt_addr" used
with a new, totally different meaning.


I don't know where the spelling "fdtaddr" is coming from; I would
consider it one of the many "non-standard" variants (assuming we agree
that there is actually something like a "standard").  Note that there
is no "fdtaddr_r" anywhere.

> I would say that 'fdt_addr' being the system provided DT, even when not
> found on memory-mapped flash and 'fdt_addr_r' being the user provided
> one is a logical extension.

Um... you enter completely new terms here - "system provided" and
"user provided". I cannot see how a "user provided" DTB in NOR flash
would fit in such a concept, nor how this would work on systems with
NOR if a "system provided" DTB gets loaded into RAM from a DHCP
server.

I understand that you are trying to give the old names a new
definition that would magically cover the suggested use, but this is
extremely thin ice.  I recommend not to try that.


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
The important thing about being a leader is not being right or wrong,
but being *certain*.                    - Terry Pratchett, _Truckers_