From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: powerpc_flash_init(), wtf!?
Date: Sat, 05 May 2007 21:36:36 +0400 [thread overview]
Message-ID: <463CC0A4.5040407@ru.mvista.com> (raw)
In-Reply-To: <20070503235620.GB28599@localhost.localdomain>
Hello.
David Gibson wrote:
>>>> Yeah, you're right here, and I've probably misunderstood what
>>>>"memory" node was. In fact, the flash in my system resides on the
>>>>same local bus as RAM, so the proper place would be behind the "lbc"
>>>>(or whatever -- it doesn't exist as yet) node on the "soc" bus. Do
>>>>you think I need to go and document it as well for such cause? :-]
>>> No, that probably won't do. MPC85xx SoC bus has ranges = <e0000000
>>>00100000> and the NOR flash is mapped at 0xff000000, so it seems that
>>>it can't be located under the "soc" bus (unless that latter has
>>>"ranges" prop extended?).
>>If the RAM and/or ROM sit on the SoC bus, the "ranges"
>>property in the SoC node should be able to translate
>>their addresses, yes. You could opt for having the
>>memory controller a separate device node, as a sibling
>>of the "soc" node, if that agrees better with your
>>SoC architecture. "It all depends".
> But if the flash really is on an external bus controlled by a bus
> controller on the SoC, it sounds like it should go under that bus
> bridge. In which case the SoC would need another range in its ranges
> property.
Erm, how multiple memory ranges are supposed to work? Aren't the addresses
in the "reg" property of subnodes relative to the "ranges" property?
WBR, Sergei
next prev parent reply other threads:[~2007-05-05 17:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-01 5:18 powerpc_flash_init(), wtf!? David Gibson
2007-05-03 6:35 ` Vitaly Bordug
2007-05-03 7:03 ` David Gibson
2007-05-03 12:02 ` Sergei Shtylyov
2007-05-03 12:22 ` David Gibson
2007-05-03 13:28 ` Sergei Shtylyov
2007-05-03 16:21 ` Segher Boessenkool
2007-05-03 16:59 ` Sergei Shtylyov
2007-05-03 17:25 ` Segher Boessenkool
2007-05-03 21:37 ` Benjamin Herrenschmidt
2007-05-03 23:49 ` David Gibson
2007-05-03 12:29 ` Benjamin Herrenschmidt
2007-05-04 0:30 ` Vitaly Bordug
2007-05-04 1:28 ` David Gibson
2007-05-03 11:47 ` Sergei Shtylyov
2007-05-03 12:30 ` David Gibson
2007-05-03 13:04 ` Sergei Shtylyov
2007-05-03 16:20 ` Segher Boessenkool
2007-05-03 17:17 ` Sergei Shtylyov
2007-05-03 17:35 ` Segher Boessenkool
2007-05-03 18:19 ` Sergei Shtylyov
2007-05-03 21:44 ` Benjamin Herrenschmidt
2007-05-03 17:53 ` Sergei Shtylyov
2007-05-03 18:07 ` Segher Boessenkool
2007-05-03 23:56 ` David Gibson
2007-05-04 12:14 ` Segher Boessenkool
2007-05-05 17:36 ` Sergei Shtylyov [this message]
2007-05-05 20:19 ` Segher Boessenkool
-- strict thread matches above, loose matches on Subject: below --
2007-05-23 21:57 Mark A. Greer
2007-05-24 0:56 ` David Gibson
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=463CC0A4.5040407@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
/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.