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

[Tom Rini <trini@ti.com>]

On Fri, Dec 06, 2013 at 09:37:59PM +0100, Wolfgang Denk wrote:
> 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.

Right.  So the rule is "fdt_addr means the [shipped] DT in NOR, if
present.  fdt_addr_r means the [shipped] DT in system RAM."

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

Well, "fdt_addr" still means the shipped DT and "fdt_addr_r" still means
a DT loaded into system RAM.  The only change is that fdt_addr may also
be a system RAM address.

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

"fdtaddr" comes from somewhere along the line someone not going "Hey,
you forgot a _ in your env" since it means what fdt_addr_r means or
fdt_addr means when you lack NOR/similar flash for a DT.

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

"system provided" or "shipped" or what have you for the vendor provided
DT, which previously would have been in NOR, for fdt_addr when you also
have fdt_addr_r.  And I believe the answer to the second question is
that yes, the shipped or system provided DTB would end up in fdt_addr,
so long as whatever "grab the provided default DT" puts it there.

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

Well, lets see if we can't convince you around.  Or get some better
names to use for these use cases.

-- 
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/20131206/3fcd675d/attachment.pgp>