All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Heiko Schocher <hs@denx.de>
Cc: linuxppc-dev@ozlabs.org, Wolfgang Denk <wd@denx.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash, size
Date: Fri, 15 May 2009 10:36:19 -0500	[thread overview]
Message-ID: <20090515153619.GA24872@b07421-ec1.am.freescale.net> (raw)
In-Reply-To: <4A0D03AB.2040602@denx.de>

On Fri, May 15, 2009 at 07:54:51AM +0200, Heiko Schocher wrote:
> Scott Wood wrote:
> > We should proabbly leave out the ranges altogether, and have u-boot
> > populate it from the mappings it establishes.
> 
> No, I vote for manipulating just the entries, which u-boot dynamically
> detect, and let the other entries untouched. It is possible that
> there is a device which u-boot didn;t use/know, and there is in the DTS
> an ranges entry for it (Maybe not on the MPC8727ADS, but we should
> define a rule, how a bootloader has to manipulate entries). So if
> u-boot build the complete ranges entry, it maybe miss something.

If u-boot doesn't know about it, then it didn't create the mapping, and
thus it's not accessible (if something later on creates a mapping, it can
update ranges itself).  The devices themselves would still be described,
just not the non-existent mapping.

The benefit is that you would have just one place that reads out the
localbus config into the device tree, with no error-prone duplication of
data, or separate hacks for each board that has something that is
variable.

We could leave ranges in the dts for cuImage, and have u-boot just
overwrite the entire thing rather than patch up individual entries.

> > I don't see how current u-boot would accomodate more than 8MiB flash on
> > this board (there's some detection in board/freescale/mpc8260ads/flash.c,
> 
> Didn;t this board uses the CFI driver? :-(

Not yet, unfortunately.  This is pretty old code.

-Scott

  reply	other threads:[~2009-05-15 15:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.7754.1242158509.26545.linuxppc-dev@ozlabs.org>
2009-05-13  6:27 ` [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash, size Heiko Schocher
2009-05-13  6:27   ` Heiko Schocher
2009-05-14 21:48   ` Scott Wood
2009-05-14 21:48     ` Scott Wood
2009-05-15  5:54     ` Heiko Schocher
2009-05-15  5:54       ` Heiko Schocher
2009-05-15 15:36       ` Scott Wood [this message]
2009-05-12 19:06 [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size Wolfgang Denk
2009-05-12 19:06 ` Wolfgang Denk
2009-05-13 10:28 ` Li Yang
2009-05-13 10:28   ` Li Yang
2009-05-13 19:42   ` Wolfgang Denk
2009-05-13 19:42     ` Wolfgang Denk
2009-05-20 13:29     ` Kumar Gala
2009-05-20 13:29       ` Kumar Gala
2009-05-20 14:47       ` Scott Wood
2009-05-20 14:47         ` Scott Wood
2009-06-11  1:51 ` Kumar Gala
2009-06-11  1:51   ` Kumar Gala

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=20090515153619.GA24872@b07421-ec1.am.freescale.net \
    --to=scottwood@freescale.com \
    --cc=hs@denx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=wd@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.