All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs
Date: Fri, 6 Dec 2013 11:28:54 -0500	[thread overview]
Message-ID: <20131206162854.GX420@bill-the-cat> (raw)
In-Reply-To: <20131206152651.BD940380BFA@gemini.denx.de>

On Fri, Dec 06, 2013 at 04:26:51PM +0100, Wolfgang Denk wrote:
> Dear Dennis Gilmore,
> 
> In message <20131206084854.0e0da0cd@adria.ausil.us> you wrote:
> >
> > Wolfgang Denk <wd@denx.de> escribi=F3:
> > > Dear Dennis Gilmore,
> > >=20
> > > In message <1386296295-28658-3-git-send-email-dennis@ausil.us> you
> > > wrote:
> > > >
> > > > -	"fdt_addr=0x11000000\0" \
> > > > +	"fdt_addr=0x11100000\0" \
> > > > +	"fdt_addr_r=0x11200000\0" \
> > > 
> > > Why would you need fdt_addr and fdt_addr_r ?  This makes no sense.
> > > Two different values would only be needed if there was NOR flash
> > > available where we could read the FDT from without loading it to RAM
> > > first.  AFAIK ther ewill never be variants of the Wandboard with NOR
> > > flash, so you will always have to load the FDT to RAM first - thus the
> > > destinction makes no sense.
> >
> > please go and read the cmd_pxe.c file it specifies the use of the two
> > variables. one is for a system provided dtb and the other is for a user
> > provided dtb
> 
> 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.

> Arbitariry redefining this meaning is counterproductive and confusing.
> 
> If cmd_pxe.c uses incorrect names, then please fix the bug there.

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.

If we want to set some new rules on these variables we're going to live
with for a long while and really document and enforce (see above about
fdt_addr/fdt_addr_r/fdtaddr current usage), OK, sure.

-- 
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/55eae480/attachment.pgp>

  reply	other threads:[~2013-12-06 16:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06  2:18 [U-Boot] [RFC] implementation of generic distro configs Dennis Gilmore
2013-12-06  2:18 ` [U-Boot] [PATCH 1/5] add a generic set of configs to enable Distros to more easier support u-boot based systems Dennis Gilmore
2013-12-06 10:53   ` Wolfgang Denk
2013-12-06  2:18 ` [U-Boot] [PATCH 2/5] port wandboards to use the generic distro configs Dennis Gilmore
2013-12-06  3:47   ` Robert Nelson
2013-12-06  5:01     ` Dennis Gilmore
2013-12-06  5:06       ` Dennis Gilmore
2013-12-06  5:13         ` Robert Nelson
2013-12-06  5:07       ` Robert Nelson
2013-12-06 10:59   ` Wolfgang Denk
2013-12-06 14:48     ` Dennis Gilmore
2013-12-06 15:26       ` Wolfgang Denk
2013-12-06 16:28         ` Tom Rini [this message]
2013-12-06 20:37           ` Wolfgang Denk
2013-12-06 22:13             ` Tom Rini
2013-12-06 22:59               ` Wolfgang Denk
2013-12-06 22:44             ` Dennis Gilmore
2013-12-06 23:16               ` Wolfgang Denk
2013-12-07  0:09                 ` Dennis Gilmore
2013-12-07 12:20                   ` Wolfgang Denk
2013-12-06  2:18 ` [U-Boot] [PATCH 3/5] port omap4 based devices to use " Dennis Gilmore
2013-12-06  2:18 ` [U-Boot] [PATCH 4/5] port beagleboard " Dennis Gilmore
2013-12-06  2:18 ` [U-Boot] [PATCH 5/5] port beaglebones " Dennis Gilmore
2013-12-06  3:31   ` Dennis Gilmore
2013-12-06 17:14 ` [U-Boot] [RFC] implementation of " Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131206162854.GX420@bill-the-cat \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.